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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
