Opened 4 years ago

Last modified 20 months ago

#13926 reopened defect

No certificate hierarchy

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability
Cc: mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In the certificate hierarchy there is only one certificate displayed for some sites.

Child Tickets

Change History (9)

comment:1 Changed 4 years ago by gk

Do you have an example which is showing in vanilla Firefox more than one certificate?

comment:2 Changed 4 years ago by cypherpunks

torproject.org

Check it several times. It displays proper certificate hierarchy, but when you close Certificate Viewer, and then open it again several times it will display only one certificate of torproject.org

comment:3 Changed 4 years ago by gk

Resolution: duplicate
Status: newclosed

Turns out this is very likely a duplicate of #13254, too.

comment:4 in reply to:  3 Changed 3 years ago by gk

Cc: mcs brade added
Keywords: tbb-usability added
Resolution: duplicate
Status: closedreopened

Replying to gk:

Turns out this is very likely a duplicate of #13254, too.

No, it is not. #14716 fixes that one but not this bug, reopening. They are probably related, though.

comment:5 Changed 3 years ago by mcs

Keywords: ff38-esr added

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

comment:6 Changed 3 years ago by vynX

As a workaround, if you install Certificate Patrol you should be able to get a view of the hierarchy on the first visit of each website as it is the primary information it gives (everything else in a certificate can be a lie). Or is Certificate Patrol also affected?

comment:7 Changed 3 years ago by bugzilla

Severity: Normal

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

temporary (SSL context) certificate store has been purged (?)

For https://github.com/
TypeError: cert is null in
chrome://pippki/content/viewCertDetails.js : 270:4
asn1Tree.loadASN1Structure(cert.ASN1Structure);
from the beginning.

nocertdb means "not to store certs" by its name. (But who knows what Mozilla thought...)
So, no cert db - is not the resolution.

cert db must be permanent / session, isolated, in-memory, purgable. SSL context - isolated, in-memory.

comment:8 Changed 2 years ago by bugzilla

Keywords: ff38-esr removed

TypeError: cert is null continues to appear in ESR45 if you select Intermediate CA in the hierarchy (https://blog.torproject.org/blog/tor-browser-65a3-released#comment-209108).
EV certs have a special handling, so when TBB seems to forget hierarchy for the site (not for CertViewer), some weird effects occur.

Note: See TracTickets for help on using tickets.