Firefox Fingerprinting using intermediate CA caching
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
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.
- Type about:config in the Firefox address bar and hit the Enter-key.
- Confirm that you will be careful if a warning prompt appears.
- Right-click in the main area, and select New > Boolean.
- Name the Boolean security.nocertdb.
- 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.
…..’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.
Thanks, Owl, that’s a good point. Request Policy FTW!
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: https://github.com/pyllyukko/user.js/issues/208 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
Your word on this issue is as good as gold for me – thanks. And thanks also to Martin for bringing this up.
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
Tested this with no result, still 76 cached
‘0 cached intermediate CAs identified.’ … but I’ve just opened the browser.
I’ll have to check further on.
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.
Run the test …I had 46 CAs identified despite I also had uBlock active.
Why so ?
@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.
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” ( https://arstechnica.com/security/2017/02/now-sites-can-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.
I created (boolean) security.nocertdb. with true and after restarting FF, all my usernames and passwords have disappeared !!!
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 :)
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).”
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”?
@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.
No, use Dynamic Filtering in uB0. See https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide and https://github.com/gorhill/uBlock/wiki/Blocking-mode
@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.
I created (boolean) security.nocertdb. with true and after restarting FF, all my usernames and passwords have disappeared!
Are you and laozi twins per a chance? Just joking!
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.
Indeed, by passing false, IDs and passwords pass came back,
Thank you for the solution
end of story
Never allow or temporarily allow any scripts and you are good
end of story?
If so, stay tuned for the sequel,eh?
…and your browsing experience is crippled.
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.
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.
“Testing 326 different intermediate CAs (326 images created). 0 results still pending.
0 cached intermediate CAs identified.”
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
@Tom Hawack and @tomlast
thank you for the links
Enabling this gets rid of “Technical Details” under Page Info > Security, for encrypted websites.
The Shift or Die blog link generates a SEC_ERROR_EXPIRED_CERTIFICATE now Martin. The certificate expired on Monday, June 26, 2017 17:38