2

I was doing a little reading over at gHacks, and came across this comment attributed to Joey Spinosa regarding certificates in Firefox:

These certificates are installed automatically by the browser. No user confirmation is ever requested. No option to have a user approval is offered. (Firefox does have an option to notify you if a site requests a certificate FROM you, but not the other way around).

Source: http://www.ghacks.net/2016/05/26/opera-software-sale-greenlighted-by-shareholders/#comment-3911315

And then I read this comment attributed to the same Mr. Spinosa:

There is a certificate for EVERY site you visit that uses encryption (HTTPS/SSL). These certificates ARE NOT deleted as part of your browsing history.

Source: http://www.ghacks.net/2016/05/26/opera-software-sale-greenlighted-by-shareholders/#comment-3912716

Mr. Spinosa then goes on to explain that even when a user deletes their Firefox history, it is trivial for us to see what secure sites they visited by viewing the certificates stored in Firefox's profile.

Are all these comments accurate?

  • yes, but there's more. so are cached images, cookies, stored values, form-fill-ins, a/v perms, and cert over-rides. – dandavis Jun 3 '16 at 3:27
  • 4
    The comments are wildly inaccurate, but sometimes come close to the truth. Firefox doesn't save a giant database of certificates, but there is a degree of other information, saved temporarily or permanently. – Matt Nordhoff Jun 3 '16 at 4:19
  • 1
    @dandavis I'm fairly sure cert8.db does not contain website certificates. It just contains intermediates, roots you've installed, client certificates, etc. And cert_override.txt contains hostnames and certificate fingerprints you've added (in)validity exceptions for. – Matt Nordhoff Jun 3 '16 at 4:35
  • 3
    The first comment is not accurate. Certificates are not installed during browsing (although they are cached for efficiency reasons). Installed certificates are the root certificates, which authenticate the certificates you see while browsing. Nothing technically prevents firefox from requesting the certificate for every site visit (or every request for that matter), but I can't comment on whether they actually do this. Also note that some OSs maintain a separate certificate store (installed certs). – Rens van der Heijden Jun 3 '16 at 7:32
  • 1
    Reading this guy's comments genuinely pisses me off. I mean I know people are going to be wrong on the internet, but to see someone spout something so obviously wrong while being so confident about it is just painful. If every TLS handshake installed a new root certificate on your browser, the world would be a very fun place for Eve, indeed. – forest Apr 3 '18 at 12:34
10

You better ignore that commenter entirely. Joey Spinosa is either royally confused or is trolling.

There are many totally inaccurate statements in his comments; mainly from conflating Server Certificate with Certificate Authority Certificate.

Claim 1:

downloading files ... install these certificates of authority.

Browsers never silently install a Certificate Authority when just browsing or downloading files. If you run an installer or executable you got from a download or somewhere else, it's possible for the installer to insert a Certificate Authority into the certificate store. However, mere browsing and downloading never silently installs a Certificate Authority without additional security prompt.

There are no good reason to use a second browser, as suggested by Joey Spinosa, to avoid installing a new Certificate Authority. If you install/execute untrusted programs, the installer/executable could just as easily install the fraudulent Certificate Authority in all browsers in the system, infecting both your primary and download-only browser. If you run an untrusted installer/executable, you could already be screwed in more ways than just fraudulent Certificate Authority.

The list of trusted Certificate Authority is pre-installed in the browser, and this list cannot be modified by mere browsing or downloading. Advanced users may add or remove their own Certificate Authority into their browser's certificate store from the Certificate UI. Some legitimate anti virus are also known to have installed Certificate Authority so it can intercept and scan inside HTTPS connection.

Claim 2:

the name of the certificate and it’s origin bear no resemblance to the name of the web-site.

This is only half truth. The domain name of the website is specified in the CN (Common Name) and/or the SAN (Subject Alternative Name) field of the Certificate. In a DV (domain validated) certificate, that is all the information that the certificate asserts. In OV (Organization Validated) and EV (Extended Validated) certificate, the Certificate additionally have O (Organization), L (Locality), and C (Country) field which will also contain the organization's legal name and jurisdiction. This is the name of the organization as registered in the legal jurisdiction. In some countries, Organizations can have different Legal Name than the name that the general public knows them as. In these cases, the organization may put the name they are generally recognized as the DBA (Doing Business As) name, but there is no requirements for them to do this.

However, what's patently false, and indicates that Joey Spinosa really has no clue of what he's talking about, is the examples he gave:

For example, I like to use Duck-Duck-Go as my preferred search engine. ... The certificate installed in Firefox is titled “DigiCert Global Root CA”. ... ASUS uses a secure site, the title for that certificate is “Baltimore CyberTrust Root”…

DigiCert and CyberTrust are the names of trusted Public Certificate Authorities. Certificate Authorities are like the "notaries" of the internet, they verify the identity of companies that runs a secure website via TLS, and they are obviously not the companies/websites themselves.

Public Certificate Authorities are independent companies that are trusted by browsers to verify the identity of sites and organizations like Duck Duck Go and ASUS. A Certificate Authority performs this by cryptographically signing Duck Duck Go's and ASUS' Certificates after verifying that the owner of the Public Key in the Certificates are the site/company whose detail are listed in the Certificate. Browsers can verify these cryptographic signatures because the browser ships with a pre-installed list of Certificate Authority Certificates. Note that while a Certificate Authority Certificates have very similar file format and structure as Server Certificates, they are used very differently by the browser.

You can check the details of the Certificate, the details of Certificate Authority, and any Intermediate Authorities in the browser security detail screen, by clicking on the lock icon next in the URL bar. This will show you the Chain of Trust, anchored from the Certificate Author, to end at the Server Certificate. Browsers trusts a Server Certificate by the virtue that it trust the Certificate Authority.

Pubic Certificate Authorities obtained this position of trust by convincing browser vendors that they are technically, financially, and legally capable to perform identity verification. The browser vendors requires that Public Certificate Authority publishes their Certificate issuance practice in a document called CPS (Certificate Practice Statement), and the Certificate Authority are regularly audited to ensure that the Certificate Authority conform to their own CPS. Browser vendors also sets up various requirements in the CPS if a Certificate Authority wants to be trusted by default by the browser. Details of this, you should visit the CA/B Forum and the Browser Vendor's CA Inclusion policy.

Claim 3:

Simply type “startpage.com” or “duckduckgo.com” into your address bar, watch HTTP change to HTTPS and bingo, you just installed a security certificate

This is not quite correct. Server Certificates and sometimes Intermediate Authority Certificates are downloaded by the browser from the Server every time the browser makes a new TLS Session, this is an integral part of the TLS Handshake. Note that TLS Session isn't necessarily the same as TLS Connection. A browser can speed up TLS Handshakes with servers it had connected to in the past, by performing abbreviated handshake, which does not exchange certificate details. Under no circumstances would a TLS handshake automatically installs a Certificate Authority.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.