Re: [tor-bugs] #13926 [Tor Browser]: No certificate hierarchy

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13926: No certificate hierarchy
-----------------------------+-------------------------------------
     Reporter:  cypherpunks  |      Owner:  tbb-team
         Type:  defect       |     Status:  reopened
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:  tbb-usability, ff38-esr
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-------------------------------------
Changes (by mcs):

 * keywords:  tbb-usability => tbb-usability, ff38-esr


Comment:

 Kathy and I spent some time in the debugger and reading code to try to
 understand this issue.  Unfortunately, we have not yet found the root
 cause.  Here are some of the things we learned:

 - The bug occurs because the intermediate CA certificate is no longer
 available.  That cert. is present in the temporary (SSL context)
 certificate store while the https connection is open, but when the SSL
 socket is closed, it is deleted (see ssl3_CleanupPeerCerts() inside
 security/nss/lib/ssl/ssl3con.c).

 - It is not clear to us why the security.nocertdb pref. value changes
 things, but for sites like https://blog.torproject.org/, if
 security.nocertdb=false (not the default), then the intermediate CA is
 found in the permanent / built-in certificate store even after it has been
 purged -- and everything works fine.  We suspect in that case the cert.
 may be present because of the cert. pinning feature that was backported to
 Tor Browser.  Maybe security.nocertdb=true (the default setting) makes it
 so that not everything is available to the UI code that is trying to
 construct the certificate chain.

 - For unpinned sites such as https://github.com/, the bug described by
 this ticket occurs in Tor Browser 4.5a5+ even when
 security.nocertdb=false.  But the pinned vs. unpinned theory is not 100%
 proven at this point.

 The NSS code is a maze of twisty little passages, all alike.  If we do not
 solve this issue soon, we should re-test when we have ff38-esr based
 builds and debug it further.

 We have not been able to reproduce this problem with unmodified copies of
 Firefox 31 or 37.0.2.

 ---

 Info. that is helpful for debugging this:

 The call that returns the incomplete list of certificates is
 CERT_CreateSubjectCertList() inside security/nss/lib/certdb/stanpcertdb.c.
 The relevant C++ portion of the call stack is:
 {{{
 CERT_CreateSubjectCertList()
 mozilla::psm::NSSCertDBTrustDomain::FindPotentialIssuers()
 mozilla::pkix::BuildForward()
 mozilla::pkix::BuildCertChain()
 mozilla::psm::BuildCertChainForOneKeyUsage()
 mozilla::psm::CertVerifier::MozillaPKIXVerifyCert()
 mozilla::psm::CertVerifier::VerifyCert()
 nsNSSCertificate::GetChain()
 ...
 }}}

 CERT_CreateSubjectCertList() is in security/nss/lib/certdb/stanpcertdb.c.

 The in-memory / session certificate store is implemented by
 security/nss/lib/pki/pkistore.c.

 The relevant JS code is the call to cert.getChain() within setWindowName()
 within the file security/manager/pki/resources/content/viewCertDetails.js

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13926#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs