Questions about TLS certificates in Firefox

[Jegan P]

Hello,

I am a researcher from Carleton University and I have a few questions about how Firefox handles TLS certificates, if this is the wrong place to ask please let me know where should I reach out.

1) Firstly, how does Firefox's behavior differ when encountering leaf certificates which fall under the following categories:
1.1) Leaf certificate which is revoked by the issuing authority (Specifically included in a CRL or OSCP response)
1.2) Leaf certificate which chains back to a root that is currently not present within Mozilla's root program (Not included in certdata.txt)
1.3) Leaf certificate which either chains back to a root/intermediary or itself has been explicitly distrusted/blacklisted. (What if Mozilla encountered a fraudulent *google.com certificate issued by Diginotar assuming there is a repeat of that case with another CA with unexpired certs in the wild and that CA being explicitly distrusted)
1.4) Leaf certificate which either chains intermediary present in OneCRL
1.5) Leaf certificate which while not revoked, chains back to a root that has been revoked.
Behavior refers to whether Firefox allows me to bypass certificate warning to visit the webpage and the error message displayed. Are these functionally the same between revoked and blacklisted certificates?

2) In the dev.security.policy discussion over the WoSign CA issues, an option was floated where the WoSign would be allowed for only issue certificates for the .cn domain which is the TLD for China. As such I would like to ask how Mozilla is currently enforcing name and other gTLD/TLD constraints on root certificates? Is this done within the NSS, if so is there some code or file which contains these bits? Similar to the NSS trust objects present in certdata.txt (Mozilla's root certificates). If the name constraints extension within the x509 is being used to enforce these restrictions only a very few (Less than 3 if I remember correctly) even have name constraints on the certificate, does that mean that name/TLD/gTLD constraints are rarely enforced?

3) Taking about root certificate removals/revocations/blacklists, I have some questions about the terminology. My assumptions are as follows:
3.1) Certificates included within certdata.txt that are marked "Explicitly Distrust" are currently blacklisted certificates (Diginotar). As such Mozilla's mechanism to blacklist root certificates is to include partial information about the certificate in certdata.txt and mark it as explicitly distrusted. A question remains if whether are blacklisted certificates included within Mozilla root certificates in the first place?
3.2) Certificates shown in CA/Removed certificates (in the Mozilla wiki site) are certificates previously present within the root store that have been removed for various reasons (WoSign/Startcom certificates)
3.3) If I were to create a list of Mozilla root certificates that have been revoked (Included in some CRL or notified by the CA), I would have to combine the removals list with the blacklisted certificates. Is it fair to assume that removed certificates are revoked?
Are these assumptions accurate?

4) Regarding Mozilla's OneCRL. Are additions to OneCRL only conducted when a CA notifies about an intermediary being revoked. Are there possibilities for OneCRL to have additions even if the CA did not contact Mozilla?

5) If there are functional differences between how Firefox treats revoked and blacklisted certificates (Question 1) Are certificates present in OneCRL considered revoked certificates or blacklisted certificates? To clarify if a CA notified Mozilla about an intermediate certificate but did not add it to a CRL/OCSP response (Due to some delay) would that certificate be treated as a revoked certificate (Considering it was not revoked by the CA) or a blacklisted certificate?


Thank you very much,

Jegan Purushothaman

[Dana Keeler]

Hello,

Responses inline.

On 11/30/20 03:19, Jegan P wrote:
> Hello,
>
> I am a researcher from Carleton University and I have a few questions about how Firefox handles TLS certificates, if this is the wrong place to ask please let me know where should I reach out.
>
> 1) Firstly, how does Firefox's behavior differ when encountering leaf certificates which fall under the following categories:
> 1.1) Leaf certificate which is revoked by the issuing authority (Specifically included in a CRL or OSCP response)

Firefox does not check CRLs. Release Firefox currently checks stapled
OCSP responses, if present, and then fetches OCSP. If an OCSP response
validates correctly and says the certificate is revoked, the user sees a
non-bypassable revocation error page.

Soon release Firefox will prefer CRLite over OCSP, but the result is the
same.
See https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#CRLite

> 1.2) Leaf certificate which chains back to a root that is currently not present within Mozilla's root program (Not included in certdata.txt)

If no trust anchor can be found, Firefox users will see an "unknown
issuer" error page, which is bypassable except for HSTS sites.

> 1.3) Leaf certificate which either chains back to a root/intermediary or itself has been explicitly distrusted/blacklisted. (What if Mozilla encountered a fraudulent *google.com certificate issued by Diginotar assuming there is a repeat of that case with another CA with unexpired certs in the wild and that CA being explicitly distrusted)

Users will see a revocation error - not bypassable.

> 1.4) Leaf certificate which either chains intermediary present in OneCRL

Revocation error - not bypassable.

> 1.5) Leaf certificate which while not revoked, chains back to a root that has been revoked.

Revocation error - not bypassable.

> Behavior refers to whether Firefox allows me to bypass certificate warning to visit the webpage and the error message displayed. Are these functionally the same between revoked and blacklisted certificates?

Revocation by OCSP, CRLite, and our manually curated lists are all
treated the same - the error is not overridable.

> 2) In the dev.security.policy discussion over the WoSign CA issues, an option was floated where the WoSign would be allowed for only issue certificates for the .cn domain which is the TLD for China. As such I would like to ask how Mozilla is currently enforcing name and other gTLD/TLD constraints on root certificates? Is this done within the NSS, if so is there some code or file which contains these bits? Similar to the NSS trust objects present in certdata.txt (Mozilla's root certificates). If the name constraints extension within the x509 is being used to enforce these restrictions only a very few (Less than 3 if I remember correctly) even have name constraints on the certificate, does that mean that name/TLD/gTLD constraints are rarely enforced?

Here are the additional name constraints:
https://hg.mozilla.org/projects/nss/annotate/f52feaa506006947b546dde5b954b59aae1bad98/lib/certdb/genname.c#l1559
Firefox gets that information here:
https://hg.mozilla.org/mozilla-central/annotate/3ba6cafe48d866c33c51fea45927e3b919b8c3ed/security/certverifier/NSSCertDBTrustDomain.cpp#l223
Telemetry indicates errors arising from name constraints violations are
extremely rare.

> 3) Taking about root certificate removals/revocations/blacklists, I have some questions about the terminology. My assumptions are as follows:
> 3.1) Certificates included within certdata.txt that are marked "Explicitly Distrust" are currently blacklisted certificates (Diginotar). As such Mozilla's mechanism to blacklist root certificates is to include partial information about the certificate in certdata.txt and mark it as explicitly distrusted. A question remains if whether are blacklisted certificates included within Mozilla root certificates in the first place?

Storing the certificates themselves in certdata.txt hasn't been
necessary for many years. New explicit distrust records only contain the
data necessary to identify the distrusted certificates.

> 3.2) Certificates shown in CA/Removed certificates (in the Mozilla wiki site) are certificates previously present within the root store that have been removed for various reasons (WoSign/Startcom certificates)

I believe so, yes.

> 3.3) If I were to create a list of Mozilla root certificates that have been revoked (Included in some CRL or notified by the CA), I would have to combine the removals list with the blacklisted certificates. Is it fair to assume that removed certificates are revoked?
> Are these assumptions accurate?

Not necessarily - I believe some roots are simply not in use any longer.

> 4) Regarding Mozilla's OneCRL. Are additions to OneCRL only conducted when a CA notifies about an intermediary being revoked. Are there possibilities for OneCRL to have additions even if the CA did not contact Mozilla?

If we have evidence of a serious compromise or other threat to our
users, it is possible we would act without input from a CA.

> 5) If there are functional differences between how Firefox treats revoked and blacklisted certificates (Question 1) Are certificates present in OneCRL considered revoked certificates or blacklisted certificates? To clarify if a CA notified Mozilla about an intermediate certificate but did not add it to a CRL/OCSP response (Due to some delay) would that certificate be treated as a revoked certificate (Considering it was not revoked by the CA) or a blacklisted certificate?

Revocation by OCSP, CRLite, and our manually curated lists are all
treated the same - the error is not overridable.

> Thank you very much,
>
> Jegan Purushothaman

Cheers,
Dana