Firefox Fingerprinting using intermediate CA caching

Martin Brinkmann
Feb 22, 2017
Updated • Feb 21, 2017

New browser capabilities and features are designed to improve the user experience or compatibility with technologies.

Sometimes, these features may also be used for shady activities such as user tracking.

One of the latest of these activities can be used to fingerprint Firefox users using intermediate CA caching.

To break it down into a single paragraph: Firefox caches intermediate CAs to speed up the loading of sites. These cache entries can be retrieved by sites, and it may also reveal information about the connecting user. Lastly, sites may use the caching to have Firefox users visit a unique set of intermediate CAs for tracking purposes.

Firefox Fingerprinting using intermediate CA caching

firefox intermediate ca caching fingerprinting

Alexander Klink, who notified Mozilla about the issue, created a proof of concept site that tests the browser's intermediate CA cache against 326 different intermediate CAs.

You can run the test by visiting this site. Basically, what it does is try to load images from servers that are misconfigured. If the image loads, Firefox cached the intermediate CA. If it does not load, no caching occurred.

The technique lists the intermedia CAs the user visited in the past. While the information is not linked to a specific site all the time, there are situations where this is the case.

Klink notes for instance that a cached Deutsche Bundestag CA (German Parliament CA) indicates strongly that the user is probably located in Germany, or at least in a German speaking country, and interested or involved in politics.

While the information that an attacker may gather from checking intermediate CA caching is limited, it may be used in conjunction with other fingerprinting techniques.

Also, as mentioned earlier, it may be possible to plant a set of cached intermediate CAs in the Firefox cache for identification purposes. Firefox uses the same cache for regular and private browsing sessions.

Mozilla is aware of the issue but has not made a decision yet as to what to do about it. The organization plans to gather telemetry data on intermediate CA caching, especially how often it is useful to users.

Our Firefox privacy and security preferences listing offers a way out, but it may impact your browsing experience. Check out entry 1220 on the page. Basically, what you need to do is create the Boolean preference security.nocertdb and set it to true.

security nocertdb

  1. Type about:config in the Firefox address bar and hit the Enter-key.
  2. Confirm that you will be careful if a warning prompt appears.
  3. Right-click in the main area, and select New > Boolean.
  4. Name the Boolean security.nocertdb.
  5. Set it to true.

Note that you need to restart the Firefox web browser after adding the preference. You will notice that the test will no longer identify the majority of intermediate CAs. The count dropped from more than 50 to 2 after I made the change on a test system.

You can undo the change at any time by setting the preference to false (double-click it), or by right-clicking on the preference and selecting reset.

Additional details are provided by Alexander Klink at the Shift or Die blog.

Firefox Fingerprinting using intermediate CA caching
Article Name
Firefox Fingerprinting using intermediate CA caching
A new technique to fingerprint or track Firefox users using the web browser's intermediate CA caching was revealed recently.
Ghacks Technology News

Tutorials & Tips

Previous Post: «
Next Post: «


  1. TelV said on August 29, 2017 at 2:24 pm

    The Shift or Die blog link generates a SEC_ERROR_EXPIRED_CERTIFICATE now Martin. The certificate expired on Monday, June 26, 2017 17:38

  2. Sir Pixelot said on February 26, 2017 at 4:39 pm

    Enabling this gets rid of “Technical Details” under Page Info > Security, for encrypted websites.

  3. b said on February 23, 2017 at 4:40 pm

    @Tom Hawack and @tomlast
    thank you for the links

  4. buck said on February 23, 2017 at 6:26 am

    If you are using Linux you can locate where this info is stored.

    $ locate cert8.db

    Then delete this file periodically
    $ rm /home/[username]/.mozilla/firefox/[profile-id]/cert8.db

    Add this to your .bashrc as an alias for easier use
    alias rm-int-ca=’$ rm /home/[username]/.mozilla/firefox/[profile-id]/cert8.db’

    If you have multiple profiles remove this file from each profile directory

  5. Vítor I said on February 22, 2017 at 11:20 pm

    “Testing 326 different intermediate CAs (326 images created). 0 results still pending.
    0 cached intermediate CAs identified.”

  6. XenoSilvano said on February 22, 2017 at 8:00 pm


    end of story

    Never allow or temporarily allow any scripts and you are good

    1. ams said on February 22, 2017 at 10:09 pm

      end of story?
      If so, stay tuned for the sequel,eh?

      …and your browsing experience is crippled.

      1. Super Panda-riding Squirrel said on February 23, 2017 at 3:24 pm

        Well Ghacks does require JS to comment. I’m nevah commenting again! I bet you all will notice and sorely miss whoever the fuck I might be.

      2. buck said on February 23, 2017 at 6:13 am

        Yep, end of story.

        If a site absolutely requires JS to function don’t use it, they are fingerprinting you and tracking you.

        Fingerprinting is not possilbe without JS, so Use NoScript and only enable JS on sites you trust, after researching them and reading their terms of service and privacy statement.

        Or, just become one of the ignorant, apathetic masses and continue to feed the Big Data beast.

  7. laozi said on February 22, 2017 at 1:17 pm

    I created (boolean) security.nocertdb. with true and after restarting FF, all my usernames and passwords have disappeared!

    1. Hank Ho said on February 22, 2017 at 2:43 pm

      Passwords will re-appear if you set the variable to false again. At least that worked for me. The real solution is to delete (or rename) the file cert8.db from your profile periodically, say when you log off or close FF.

      1. laozi said on February 22, 2017 at 4:42 pm

        Indeed, by passing false, IDs and passwords pass came back,
        Thank you for the solution

    2. Tom Hawack said on February 22, 2017 at 2:24 pm

      Are you and laozi twins per a chance? Just joking!

  8. Tom Hawack said on February 22, 2017 at 9:43 am

    To avoid repeating my experience of security.nocertdb set to false,

    So, another fingerprinting tool in the arsenal of privacy invaders. Last big news were sites now being able to “fingerprint you online even when you use multiple browsers” ( ).

    There’s not much to do eradicate the inquisition but it’s not checkmate yet. We can make it harder, and that’s what it’s all about.

    1. b said on February 22, 2017 at 3:53 pm

      @Tom Hawack
      where, in the dashboard, do you set ublock to block access to 3.rd party sites? quite a lot are listed. do you mean the 3 ones listed under “social”?

      1. Rick A. said on February 23, 2018 at 4:43 am

        @Pants – i didn’t read the comments, just read the article and made the Boolean and reset Firefox. Then i read the comments and saw about the Passwords, checked my passwords and it was blank and i was pissed. So i reset the Boolean and restarted Firefox and checked my passwords and they was all there which was a relief.

        i’m just gonna do without this Boolean because i don’t wanna take a chance of messing with my Passwords and the Sync. Don’t know if there is a work around.

        Martin, you should put an update in the article warning people.

      2. tomlast said on February 22, 2017 at 6:44 pm
      3. Tom Hawack said on February 22, 2017 at 5:47 pm

        @b, it’s not in the dashboard only. From the toolbar button, clicked, you have two columns related to settings images, 3rd-party, inline scripts, 1st-party scripts … the left column sets default values and the right one handles values for the site you’re visiting …

        Gorhill’s Github pages are very well crafted, the Wiki is more than a word. Maybe this can help you :

        But if you have a look on those pages you’ll find full documentation. I don’t explain very well because my use of technology is intuitive far more than academic.

    2. laozi said on February 22, 2017 at 1:15 pm

      I created (boolean) security.nocertdb. with true and after restarting FF, all my usernames and passwords have disappeared !!!

      1. Pants said on February 22, 2017 at 3:34 pm

        That’s unfortunate. Did you not read the preference descriptions and notes and links? I hope you made a backup your profile? Otherwise, hopefully you can just flip the pref, reset it in about:config, restart Firefox, and over the next few weeks as you revisit sites, re-save your passwords and logins. Will be a good exercise for you to check if you need to change them and make sure they are all different. The guthub release has been updated and the description reworded to make it perfectly clear
        “We have been using “security.nocertdb” -> true in Tor Browser for a while, and it does work, in the sense that HTTP username/password are remembered within a session. However, in a new Firefox session, the credentials must be entered anew (which is the desired behavior).”

      2. Tom Hawack said on February 22, 2017 at 2:21 pm

        Do you happen to use a master password? Here nothing had disappeared but I was asked to change my master password at start, in a sort of impossible loop … that was with the FIPS option. I closed Firefox and restored a backup, otherwise I have no idea of what would have become of my beloved (the browser that is, her I don’t care!).

        How are you managing now with those logins? Recovered?

        We do know that the setting security.nocertdb is commented out in Pants’ user.js 11.0, right? Means bypassing is at our risk :)

  9. mike said on February 22, 2017 at 9:26 am

    Tested this with no result, still 76 cached

    1. Tom Hawack said on February 22, 2017 at 9:49 am

      ‘0 cached intermediate CAs identified.’ … but I’ve just opened the browser.
      I’ll have to check further on.

      1. Tom Hawack said on February 22, 2017 at 2:15 pm

        @Marcin, must be because you haven’t set uBo to block access to 3rd-party sites by default. The test page calls dozens of sites to perform, blocking those calls blocks the test.

      2. Marcin said on February 22, 2017 at 11:35 am

        Run the test …I had 46 CAs identified despite I also had uBlock active.
        Why so ?

      3. Tom Hawack said on February 22, 2017 at 10:00 am

        I had 0 intermediate CAs identified because uBlockO was active. Once disabled for the test site I’m at 73 …
        uBlockO does the job because the test is performed as a pOc, I guess. Blocking external calls with uBlock prevents the pOc of running correctly, no more.

  10. Pants said on February 22, 2017 at 9:10 am

    For fingerprinting you need to build a defense based on a worse case scenario. As Owl says, do everything possible to reduce the attack surface (JS, XSS etc), but look at the problem in isolation.

    Enabling entry 1220 on the user.js is a REALLY BAD idea IMO. TBB does this, and I am not convinced (there’s a reason it is commented out) and neither is pyllyukko (whose advice and knowledge I absolutely respect). Go here: and scroll down to 1220 in the list in the first post:

    “This is the single most important feature to keep the internets working, because people don’t know how to configure their servers with proper certificate chains” -pyllyukko

    1. Jason said on February 22, 2017 at 4:09 pm

      Your word on this issue is as good as gold for me – thanks. And thanks also to Martin for bringing this up.

      1. Pants said on February 22, 2017 at 5:47 pm

        It actually makes sense for TBB, but IMO they used a bit of a hack really. Now that its a bit more public with the PoC, there are a few possible solutions – I think FPI will be the answer to a lot of issues when it is ready for mainstream

  11. Owl said on February 22, 2017 at 8:00 am

    …..’Alternatively, blocking third-party requests with an addon such as Request Policy might be useful since the attack obviously needs to make (a lot of) third-party requests.’ From Alexander Klink’s site.

    1. ams said on February 22, 2017 at 10:04 pm

      Thanks, Owl, that’s a good point. Request Policy FTW!

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.