Open
Bug 634074
Opened 14 years ago
Updated 2 years ago
Cannot validate valid certificate chain when looping/cross-signed certs are involved
Categories
(NSS :: Libraries, defect, P5)
NSS
Libraries
Tracking
(firefox14 wontfix, firefox15+ fixed, firefox16+ fixed, firefox17+ fixed, blocking2.0 .x+)
People
(Reporter: briansmith, Unassigned)
References
Details
Attachments
(4 files)
I can use https://secure.eff.org without errors or warnings in other browsers (IE9, Opera). On one system, Minefield and Firefox can navigate the site without errors or warnings. On another one, Firefox will show the page at https://secure.eff.org and then pop up a modal dialog (multiple times) saying that the certificate is not trusted, ever time the site is accessed. Clicking on links will take us to the untrusted certificate error page. Inspecting the certificate in Firefox's certificate viewer on the bad system shows a very strange and long certificate chain that is much different than what is shown in other browsers and/or the good system, and different from what the server actually sent (as seen in Wireshark). Screenshot attached.
Reporter | ||
Comment 1•14 years ago
|
||
This seems to be due to some kind of profile corruption. I will investigate the cause of the corruption and why the corruption isn't detected by the cert chain validation code.
Updated•14 years ago
|
Assignee: nobody → bsmith
OS: Windows 7 → Windows XP
Summary: Untrusted certificate errors on https://secure.eff.org → Profile corruption causes bizarre cert chain when trying to connect to https://secure.eff.org
Reporter | ||
Comment 2•14 years ago
|
||
I have run into this same problem now on Amazon.com, with similar symptoms to bug 613977.
Severity: normal → critical
OS: Windows XP → Windows 7
Priority: -- → P1
Reporter | ||
Updated•14 years ago
|
Reporter | ||
Comment 5•14 years ago
|
||
This seems less likely to be an exploitable security vulnerability than I suspected, but I am still investigating. I suspect there is something wrong with the cert database entries for "AddTrust External CA Root" and/or "UTN - DataCorp SGC". The EFF has a certificate for secure.eff.org and another wildcard certificate for *.eff.org. The favicon for https://secure.eff.org is https://robin.eff.org/favicon.ico and the trouble seems to occur there. robin.eff.org sends four certs in its cert chain as shown at the bottom of the attached image. The cert chain building code in NSS does not stop building the cert chain after adding AddTrust External CA Root. Instead, it keeps building a cert chain alternating between the last cert provided (UTN - DataCorp SGC) and the root CA (AddTrust External CA Root) until it hits its maximum of 20 certs in a chain. I am investigating why this happens. I have observed exactly the same behavior with the same certs (AddTrust External CA and UTN - DataCorp SGC) on amazon.com, but only on one occasion.
Severity: critical → major
Summary: Profile corruption causes bizarre cert chain when trying to connect to https://secure.eff.org → Wrong cert chain parsing for robin.eff.org
Reporter | ||
Comment 6•14 years ago
|
||
It seems like in a previous release the Addtrust cert was subordinate to the UTI - DataCorp SGC cert, and in current releases the UTI - DataCorp SGC cert is subordinate to the Addtrust cert. It also seems like it is possible for the user to get his profile into a state where the self-issued Addtrust cert and the UTI-DataCorp-issued Addtrust cert are both available. This state confuses NSS. In my profile, I have these CA certs, where "SKI" is "Subject Key Identifier" and "AKI" is "Certificate Authority Key Identifier": AddTrust External CA Root in Built-in Token Object Issued by: AddTrust External CA Root SKI: adbd987a34b426f7fac42654ef03bde024cb541a AKI: adbd987a34b426f7fac42654ef03bde024cb541a AddTrust External CA Root in Software Security Device Issued by: UTN - DataCorp SGC SKI: adbd987a34b426f7fac42654ef03bde024cb541a AKI: 5332d1b3cf7ffae0f1a05d854e92d29e451db44f UTN - DataCorp SGC Issued by: UTN - DataCorp SGC SKI: 5332d1b3cf7ffae0f1a05d854e92d29e451db44f AKI: not provided The website provides a different "UTN - DataCorp SGC" certificate in its cert chain: UTN - DataCorp SGC Issued by: AddTrust External CA Root SKI: 5332d1b3cf7ffae0f1a05d854e92d29e451db44f AKI: adbd987a34b426f7fac42654ef03bde024cb541a This fourth server-provided certificate is expecting to get chained to the first AddTrust cert, but instead we chain it to the second cert. The second cert isn't a root and the it is expecting to get chained to the third certificate, but instead we are chaining it to the fourth certificate. The fourth certificate isn't a root so we chain it back to the second certificate. This creates an infinite loop. NSS breaks the loop after 20 certs have been added to the chain and returns an error message since it never reached the end of the chain. I can observe the same trucated infinite cert chain by going to Tools -> Options -> Advanced -> View Certificates, under "The USERTRUST Network" and look at the chain in the Details tab.
Severity: major → blocker
blocking2.0: --- → ?
tracking-fennec: --- → ?
Keywords: regression
Summary: Wrong cert chain parsing for robin.eff.org → Infinite loop in certificate chain for AddTrust External CA and UTN - DataCorp SGC
Reporter | ||
Comment 7•14 years ago
|
||
This should block because it at least affects two very high profile sites: amazon.com and eff.org. On amazon.com, it basically prevents stylesheets and/or images from loading on Amazon's HTTPS site. When the problem occurs, it makes both sites virtually unusable. It may also drive users to the "Add Exception" UI for amazon.com (via the modal dialog) which is bad. Create a new profile and then replace its cert8.db file with the one I am attaching to reproduce the problem. Then navigate to https://robin.eff.org. To reproduce on amazon.com, try signing out and then signing in and do a hard refresh; the styling of the page will be completely jacked.
Reporter | ||
Comment 8•14 years ago
|
||
Because of the way certs are put in a shared (cross-site) cache in NSS, even if the user doesn't have two different AddTrust certs stored on his computer, an website may still be able to (accidentally or maliciously) DoS websites that use these certs: User navigates to a website that supplies a complete cert chain including one pair of certs in the SSL handshake and in another window/tab navigates to another website that supplies the other two certs in the SSL handshake. For example, this could be used as a denial of service attack on Firefox users, preventing them from logging in or ordering from Amazon.com.
Comment 9•14 years ago
|
||
Brian, I suspect that this is a duplicate of bug 479508, for which Nelson wrote an (incomplete) patch nearly 2 years ago. It would be great to see that bug fixed!
Comment 10•14 years ago
|
||
Rob: you are right one. My code inspection last night also ended up in nssCertificateArray_FindBestCertificate. You can duplicate my code inspection by following the NSSCertificate_BuildChain call with the CERT_MAX_CERT_CHAIN argument: http://mxr.mozilla.org/security/ident?i=NSSCertificate_BuildChain To a human being, it's clear that when multiple issuer certs are available, a root cert, or more generally a trust anchor, should be favored. So Nelson's patch in bug 479508 is the right approach. A risk of that approach is that nssCertificateArray_FindBestCertificate is used by not only find_cert_issuer. Some other callers of nssCertificateArray_FindBestCertificate may not favor a trust anchor. Shall we continue the technical discussion in bug 479508, if we can't simply mark this bug as a duplicate?
OS: Windows 7 → All
Updated•14 years ago
|
OS: All → Windows 7
Comment 11•14 years ago
|
||
(In reply to comment #10) > Shall we continue the technical discussion in bug 479508, Wan-Teh: IIUC, Nelson also mentioned another approach to fix/workaround this buggy behaviour: "I suspect the only real solution to this is for PSM to switch to always use libPKIX. Bug 479393 requests just that." I suggest that efforts should be concentrated on whichever of these 2 bugs is likely to be the simplest/quickest to resolve. BTW, does "P1 blocker" mean that Mozilla want this buggy behaviour fixed in time for FF4.0 ?
Comment 12•14 years ago
|
||
Brian: please run a quick experiment to see if libpkix can build this certificate chain successfully. Please set the environment variable NSS_ENABLE_PKIX_VERIFY to 1, and then run Firefox. Does that solve the problem? Rob: in Bugzilla, the severity/importance level 'blocker' does not mean it will block a release. The 'blocker' level is defined as: blocker Blocks development and/or testing work https://bugzilla.mozilla.org/page.cgi?id=fields.html#importance I lowered the severity/importance level to 'major'.
Severity: blocker → major
Comment 13•14 years ago
|
||
Based on the problem description, I don't think we'd hold release for this, but it is something we'd like to see fixed. Marking it .x, but if a safe, reviewed patch comes along in time, please nominate it for approval.
blocking2.0: ? → .x
Comment 14•14 years ago
|
||
This is clearly (IMO) a dup of bug 479508, and (IMO) is not worthy of being security sensitive, just as bug 479508 is not security sensitive. Has anyone here tried setting the environment variable NSS_ENABLE_PKIX_VERIFY to 1, to see what that does?
Comment 15•14 years ago
|
||
Inifinite loops are allowed under pkix. Because of our processing code, CA's have avoided them in the past. PKIX tries more than one path, looking for the patch that works properly, So I join wtc and Nelson in asking what happens if you set NSS_ENABLE_PKIX_VERIFY? It may be time to think about shift PKIX to default in the next set of releases (probably not 4.0:). bob
Comment 16•14 years ago
|
||
fennec can pick this up when the platform gets it.
tracking-fennec: ? → ---
Reporter | ||
Comment 17•14 years ago
|
||
See bug 635384. With NSS_ENABLE_PKIX_VERIFY=1, the behavior is even worse because we execute an infinite loop in pkix_BuildForwardDepthFirstSearch when attempting to access https://robin.eff.org
Reporter | ||
Comment 18•14 years ago
|
||
(In reply to comment #14) > This is clearly (IMO) a dup of bug 479508, and (IMO) is not worthy of being > security sensitive, just as bug 479508 is not security sensitive. I agree, but I cannot clear the sensitive flag. I filed it as sensitive because I initially suspected a different cause.
Reporter | ||
Comment 20•14 years ago
|
||
This is not a regression from 3.6 as it happens in 3.6.12 too. If the cert is an EV cert then Firefox may crash with a stack overflow (not verified yet) because of bug 635384.
Keywords: regression
Reporter | ||
Comment 21•14 years ago
|
||
From Bug 639315: "check https://pki.treas.gov for some certificate bundles to import to see this issue."
Summary: Infinite loop in certificate chain for AddTrust External CA and UTN - DataCorp SGC → Cannot validate valid certificate chain when looping/cross-signed certs are involved
Comment 23•14 years ago
|
||
I confirm that - NSS_ENABLE_PKIX_VERIFY=1 - attached cert8.db - visit https://robin.eff.org/ results in an endless loop. Actually, not just a loop, but an endless recursion. I'll attach a stacktrace with 333 frames.
Comment 24•14 years ago
|
||
Comment 25•14 years ago
|
||
let's make sure we are able to debug this problem, even if the config of server robin.eff.org changes. attaching a zip file that contains 5 certs sent by the server dumped with nss tool vfyserv Subject: C=US/postalCode=94110, ST=California, L=San Francisco/street=454 Shotwell St, O=Electronic Frontier Foundation, OU=Comodo PremiumSSL Wildcard, CN=*.eff.org Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO High Assurance Secure Server CA Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO Certification Authority Subject: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN - DATACorp SGC Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
Reporter | ||
Updated•14 years ago
|
Reporter | ||
Updated•14 years ago
|
Reporter | ||
Comment 27•12 years ago
|
||
With the patch to NSS in bug 764393, this should be fixed without requiring the switch to libpkix. (We need to verify this.) Wan-Teh pushed the beta of NSS with that fix to mozilla-inbound today. Comodo has requested that we fix this bug in the mozilla-beta and mozilla-aurora channels and I agree that we should do so, as the fix is pretty simple and it fixes a serious problem.. But, I recommend that we wait at least a week to make sure Nightly does not experience any regressions.
status-firefox14:
--- → affected
status-firefox15:
--- → affected
status-firefox16:
--- → affected
status-firefox17:
--- → affected
tracking-firefox15:
--- → ?
tracking-firefox16:
--- → ?
tracking-firefox17:
--- → ?
Updated•12 years ago
|
Comment 28•12 years ago
|
||
Do you intend to use this bug for "landing NSS 3.13.6 into mozilla-central and branches"? If yes, the subject should probably mention it for clarity. I understand you want to release NSS 3.13.6 next week.
Reporter | ||
Comment 29•12 years ago
|
||
I filed a new bug for the landing of the NSS release because that's what we usually do, and because the NSS release makes several changes unrelated to this bug. That bug is bug 780009.
Reporter | ||
Comment 31•12 years ago
|
||
Rob/Robin, could you please verify that the latest build of Firefox 15 beta fixes the issue to your satisfaction? We will be shipping the final beta before Firefox 15 release soon. http://www.mozilla.org/en-US/firefox/all-beta.html Thanks for your help!
Comment 32•12 years ago
|
||
(In reply to Brian Smith (:bsmith) from comment #31) > Rob/Robin, could you please verify that the latest build of Firefox 15 beta > fixes the issue to your satisfaction? Verified on Linux and Windows 7. Thanks!
Comment 34•12 years ago
|
||
Is this bug considered to be completely fixed? If yes, can we close this bug?
Comment 35•12 years ago
|
||
(In reply to Kathleen Wilson from comment #34) > Is this bug considered to be completely fixed? It depends on how you interpret this bug. If the bug is meant to fix the special category of loops where a cross signed root is involved, then this bug is believed to be fixed. On the other hand, if this bug rather means "fix all possible loops", then no, the bug isn't fixed. Bob said, a "cross cert to cross cert loop will require full pkix".
Reporter | ||
Updated•11 years ago
|
Reporter | ||
Comment 37•10 years ago
|
||
This is fixed in Firefox 31 in general by the switch to mozilla::pkix (bug 915930). For some cases, it was fixed in NSS by a patch that Wan-Teh wrote long ago. The only remaining work is to write an automated test that proves that we can handle this case.
Assignee: brian → nobody
Target Milestone: mozilla30 → mozilla31
Comment 38•9 years ago
|
||
I noticed this very problem (with a loop in CrossCerts from UTN-DATACorpSGC and AddTrustExternalCARoot) today in the CertifcatePatrol plugin (2.0.14.1-signed) in Firefox 38.0.1. The looping Cert chain was reported/visualized for the _old_ Certificate in the CertificatePatrol plugin for the site adblockplus.org (for a server certificate that was valid from 09-Apr-2014 to 10-Apr-2015). The current/new server certificate does not have this problem. Is this a problem in the CertificatePatrol plugin, or is the problem not really fixed in the underlying Firefox code?
It could be that the certificate viewer is doing the wrong thing (I suspect GetChain). Would you please file a new bug with the relevant certificates attached? Thanks.
Comment 40•9 years ago
|
||
I've found out this bug has much more critical consequences. With the bad UTN-DATACorpSGC certificate in the cert store, when I try to login to startssl.com using my client certificate, Firefox enters an endless loop and gets completely frozen. Even the multiprocess nightly. Removing this cert stops the freezing from happening.
Comment 41•9 years ago
|
||
(In reply to Martin Pecka from comment #40) > I've found out this bug has much more critical consequences. With the bad > UTN-DATACorpSGC certificate in the cert store, when I try to login to > startssl.com using my client certificate, Firefox enters an endless loop and > gets completely frozen. Even the multiprocess nightly. Removing this cert > stops the freezing from happening. Good to know. We plan to remove that root in Firefox 44 -- Bug #1208461
Comment 42•9 years ago
|
||
(In reply to Martin Pecka from comment #40) > Removing this cert stops the freezing from happening. Martin, which cert did you remove to stop the freezing from happening? Was it the self-signed "UTN - DATACorp SGC" built-in root (that bug #1208461 will be removing soon), or was it one of the "UTN - DATACorp SGC"<--->"AddTrust External CA Root" cross-certificates?
Comment 43•9 years ago
|
||
(In reply to Rob Stradling from comment #42) > Martin, which cert did you remove to stop the freezing from happening? Was > it the self-signed "UTN - DATACorp SGC" built-in root (that bug #1208461 > will be removing soon), or was it one of the "UTN - DATACorp > SGC"<--->"AddTrust External CA Root" cross-certificates? Rob, I removed the UTN certificate signed by Addtrust. The self-signed UTN hasn't been touched.
Comment 44•9 years ago
|
||
Thanks Martin. That's what I thought. Kathleen, I don't think bug #1208461 will actually have any effect on any remaining cross-cert looping bugs.
This is an NSS bug. TLS certificate verification in Firefox won't have this problem because mozilla::pkix knows how to handle looping/cross-signing. (Note that this can still affect Firefox because there are places where the affected NSS functions will still be called (e.g. when libssl builds the client certificate chain if requested by the server and selected by the user)).
Assignee: nobody → nobody
Component: Security: PSM → Libraries
Product: Core → NSS
Target Milestone: mozilla31 → ---
Version: Trunk → trunk
Comment 46•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: major → --
Updated•2 years ago
|
Severity: -- → S4
Priority: P1 → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•