How to prevent HSTS tracking in Firefox
HTTP Strict Transport Security (HSTS) was designed to help secure websites (those using HTTPS) by declaring to web browsers that they should communicate only via HTTPS with the server to protect connections against downgrade attacks and cookie hijacking.
Mozilla implemented support for HSTS in its current form in Firefox in 2014 and it has been active in all Firefox versions ever since.
Ars Technica were among the first to raise concerns about the implementation of HSTS in web browsers as it allowed site operators to plant supercookies in browsers using the technology that was designed to improve user security.
A demo site was created by Sam Greenhalgh to demonstrate the concept. When you visit the site in a browser supporting HSTS, you are assigned a unique ID which persists across browser sessions and can be used to track you because of it.
Note: This issue is not limited to the Firefox web browser as Google Chrome and other browsers who have implemented the feature are vulnerable to HSTS tracking as well.
How HSTS is handled by Firefox currently
Firefox saves HSTS information to the file SiteSecurityServiceState.txt which you find in the root of your Firefox profile folder.
The easiest way to open it is to load about:support in Firefox's address bar and to click on the "show folder" button on the page after it has loaded. This opens the profile folder of Firefox in the default system file browser.
When you open the file in a plain text editor you will get a list of domain names and values associated with them including an expiration date.
Firefox handles HSTS in private browsing mode and regular browsing mode differently.
- Regular browsing mode: HSTS persists across sessions.
- Private browsing mode: HSTS information are deleted after the session.
Note that sites can access HSTS information created during regular browsing sessions when you enter private browsing mode in that session.
Protection against HSTS tracking
Unlike cookies, HSTS offers no whitelist or blacklist approach. The feature is enabled by default and there appears to be no preference to disable it.
Even if there would be an option to do so, it would affect security while browsing the Internet.
1. Only use Private Browsing Mode
Since Firefox is clearing HSTS information after you close private browsing sessions, it is currently the best option to prevent supercookie tracking without compromising security.
To launch Firefox in private browsing mode, use the shortcut Ctrl-Shift-P, or hit the Alt-key and select File > New Private Window.
2. Clear the Site Preferences on exit
The second option that you have is to clear Site Preferences whenever you close the Firefox browser. This gets rid of all HSTS information saved to the SiteSecurityServiceState.txt file but impacts other site specific preferences such as site-specific permissions or zoom levels as they get cleared as well by the operation.
Note: This works in Google Chrome as well. Tap on Ctrl-Shift-Del to open the clear browsing data dialog in the browser. Make sure "cookies and other site and plugin data" is selected and hit clear browsing data afterwards.
This will remove cookies and site preferences as well.
3. Remove entries from the HSTS file manually
The HSTS file is a plain text document which means that you can manipulate data in it easily using text editors.
Make sure Firefox is closed before you do so as content will be overwritten when Firefox is terminated.
The method gives you full control over HSTS but it requires manual intervention regularly, and may not be suitable because of this.
One option that you may have is to keep select sites in and make the file read-only afterwards to block new entries to it.
You will still need to edit it manually regularly as HSTS information have an expiry date.
4. Remove HSTS file data automatically
Programs like CCleaner support the cleaning of HSTS Supercookies but you can also run a local command such as echo ' ' >/SiteSecurityServiceState.txt
on the file regularly to remove it. If you add it to a batch file and run it on system start or shut down, then you should not have to worry about HSTS information persisting across sessions.
5. Make the HSTS file read-only
This radical approach blocks Firefox from saving information to the HSTS file. While that is effective in preventing tracking, it means that the browser cannot make use of HSTS to improve security.
To make it read-only on Windows, right-click the file and select properties from the context menu. Locate the read-only box on the properties page and check it. Click ok afterwards to apply the change. (Thanks Pants)
Can confirm, I am in the court system. This was used successfully to profile darknet criminals abusing the postal service in the United States. It is activly used by the Northern California Illicit Economy Task Force. guessguess guessed wrong.
Martin, Pants, CHEF-KOCH, somebody please update us on this. According to the ARS article linked in this post, these supercookies set in regular Firefox windows can no longer be read in Private Browsing windows.
What i want to know, how does this work in regular windows using containers? i use Multi Account Containers and Temporary Containers. i also use First.Party.isolation. i recently erased all cookies and blocked all cookies and set exceptions on sites i need them, but Clearing Site Preferences on exit deletes all my exceptions. This ain’t a big deal, as when i go to a site that needs my allowed cookies, i just right click, click View Page info, click Permissions and allow the cookies then i just refresh the page and the site uses my already set cookies.
i’m just trying to see if my Containers take care of this and i don’t have to keep making new exceptions and refreshing the page.
Or do i need to keep doing what i’m doing.
Thank You in advance to whoever can help with this. i’m gonna reply this comment to Pants and CHEF-KOCH so that the chances of them seeing this are increased.
Thanks in advance again.
To disable the HSTS tracking in Firefox, enter about:config in the address bar. And give the “false” value to the “network.stricttransportsecurity.preloadlist” key.
Source : https://www.dsfc.net/logiciel-libre/firefox-logiciel-libre/collecte-sites-tls-firefox/#Desactiver_la_collecte_des_sites_dans_le_fichier_SiteSecurityServiceStatetxt (in French)
Thank you. :)
1.How to add your own HSTS records?
2.http://www.radicalresearch.co.uk/lab/hstssupercookies
How to store the data, where to store?
thx
With “Cookie Controller” you can destroy supercookies selectively.
https://addons.mozilla.org/de/firefox/addon/cookie-controller/?src=search
Thank you, Martin, for another great article. I’m looking forward to what
will be presented some day by Pants, Leandro or somebody else.
I highly doubt that this will prevent the browser from just create another file if it’s needed. You can’t really prevent it without blocking the entire domain, so the tip with ccleaner is better imho. In fact hsts isn’t always evil, as mentioned it’s a standard which also can be used for evil things, same like normal cookies, webrtc, webgl, fonts and and and. So be careful with this trick.
CCleaner can since the latest 2 releases clean HSTS, also on Chrome without any bigger problems.
@CHEF-KOCH – Martin, Pants, CHEF-KOCH, somebody please update us on this. According to the ARS article linked in this post, these supercookies set in regular Firefox windows can no longer be read in Private Browsing windows.
What i want to know, how does this work in regular windows using containers? i use Multi Account Containers and Temporary Containers. i also use First.Party.isolation. i recently erased all cookies and blocked all cookies and set exceptions on sites i need them, but Clearing Site Preferences on exit deletes all my exceptions. This ain’t a big deal, as when i go to a site that needs my allowed cookies, i just right click, click View Page info, click Permissions and allow the cookies then i just refresh the page and the site uses my already set cookies.
i’m just trying to see if my Containers take care of this and i don’t have to keep making new exceptions and refreshing the page.
Or do i need to keep doing what i’m doing.
Thank You in advance to whoever can help with this. i’m gonna reply this comment to Pants and CHEF-KOCH so that the chances of them seeing this are increased.
Thanks in advance again.
It is getting more complicated by the day to keep ones privacy.
I will wait until there is an extension to zap HSTS.
Thanks Martin for this informative article.
For those who want to know what’s going on, read this: https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/
By emptying and rendering the SiteSecurityServiceState.txt read only, you are NOT totally defeating HSTS tracking. Everytime you restart your FF, you start clean and would get assigned a new unique ID. But that will persist until you close FF. Not sure about you, but my FF stays open for days at a time. If the txt file isn’t being used, then where the hell is that information being stored?
I don’t want to wipe all of site prefs so I added this to my CCleanear winapp2.ini
[Firefox HSTS Storage]
LangSecRef=3026
DetectFile1=%AppData%\Mozilla\Firefox\Profiles\*
Default=False
FileKey1=%AppData%\Mozilla\Firefox\Profiles\*|SiteSecurityServiceState.txt
CCleaner already detects and cleans the SiteSecurityServiceState.txt – leaving in any allowed domains
ConfigFox’ next version has a tool for it. I call it Dummy Files:
http://s2.postimg.org/dkbsii7g9/clipboard20151016200920.png
That’s really cool Leandro, let me know when it is ready.
Sure. I’ll keep you posted.
I use “selectivecookiedelete” addon for Firefox.
You can whitelist (or blacklist) sites and when you close the browser it will delete all cookies that are not in the whitelist automatically.
Works for me.
Nvm… After some tests I see it doesn’t delete super cookies :/
Something I’ve noticed,
NoScript adds – secure.informaction.com:HSTS 0 16724 1602697055679,1,0
and
Firefox adds – blocklist.addons.mozilla.org:HSTS 0 16724 1476553172208,1,0
to SiteSecurityServiceState.txt. Both entries are persistent across browser sessions regardless of whether you have Private Browsing Mode enabled, or you clear Site Preferences.
Thanks, Martin & Pants for bringing this subject to our attention.
Yes, I’ve noticed those two domains persisting as well, along with two more from Mozilla: blocklist.addons.mozilla.org and publicsuffix.org.
I, too, am running in Private Browsing mode always, and run CCleaner every time after closing the browser. Yet, the three from Mozilla (and one from NoScript) persist. I even manually removed them from the txt file, saved the file that way, and yet, they always return.
Anyone have any thoughts at all about this? I don’t like that Mozilla has three persistent domains in there that are or may be, or at least are able, to track me. Thanks in advance for any help!
This addon can help to delete Firefox’s site preferences (among other things about privacy): https://addons.mozilla.org/en-GB/firefox/addon/clickclean/
(see on Gizmo)
So will we now have a FF and Chrome add-on appearing soon to tackle this in an easy way on the add-on toolbar. Can an add-on do this.
I’m thinking some sort of script injection that strips out any attempts to store a unique identifier – not sure what this entails or even feasible. I’m also thinking nothing will happen because this has been around for 18months
Martin – you have written “HTST” a number of times – it should be “HSTS” – search and replace time dude
Thanks, corrected that ;)
Missed one. :)
Thanks ;)
I mentioned this to Martin because CCleaner was finding “cookies” that shouldn’t have been there, and my initial thought was something fundamental had broken in an extension or in FF. I did some testing in a new clean portable FF but the problem persisted .. turns out recently CCleaner added entries in that txt file under “cookies”
I am getting concerned about the myriad of places where “tracking data” is being stored, with no fine tuning ability to clean that #h!T out, if any ability at all – think dom storage, indexeddb, seer/necko databases and more. I don’t consider wiping site prefs as a solution, as it disrupts too many other features (I save and allow 20 odd cookies for convenience,
and no doubt there are a couple of specific site pref overrides from my defaults).
I personally am going the route of a read only empty txt file. It’s a trade off but the chances of getting stung are slim to none, and there are other countermeasures. Or since it’s just metadata on my local drive – ccleaner will do the job.
I also want to say blocking the use of the SiteSecurityServiceState.txt does not stop HSTS tracking – at least not fully. I don’t profess to knowing how this all works, or where it’s being stored – but using the test site (and I have no dom storage, no cookies, no indexeddb, nothing, no disk cache, nada, zip: I am screwed down tighter than a nun’s arse) – across any FF session the unique code persists. NOTE: there is no cross-contamination between normal browsing and private browsing modes – but you are still tracked across that mode.
FF normal mode – until I restart FF, the site “READS” my unique code.
FF private browsing – If I start a new private window, UNTIL that window is closed, it tracks me across it – i.e each private window has its own session/unique code
*sigh* I’m kinda getting tired of all this .. maybe I’ll just get ahead of the game and release my dick picks and home made hairy midget porn .. god only knows I’ve already leaked them three times to that TMZ reporter .. I’ll try again this weekend guys
@Pants – Martin, Pants, CHEF-KOCH, somebody please update us on this. According to the ARS article linked in this post, these supercookies set in regular Firefox windows can no longer be read in Private Browsing windows.
What i want to know, how does this work in regular windows using containers? i use Multi Account Containers and Temporary Containers. i also use First.Party.isolation. i recently erased all cookies and blocked all cookies and set exceptions on sites i need them, but Clearing Site Preferences on exit deletes all my exceptions. This ain’t a big deal, as when i go to a site that needs my allowed cookies, i just right click, click View Page info, click Permissions and allow the cookies then i just refresh the page and the site uses my already set cookies.
i’m just trying to see if my Containers take care of this and i don’t have to keep making new exceptions and refreshing the page.
Or do i need to keep doing what i’m doing.
Thank You in advance to whoever can help with this. i’m gonna reply this comment to Pants and CHEF-KOCH so that the chances of them seeing this are increased.
Thanks in advance again.
Hi Pants,
I’ve been doing some testing on http://www.radicalresearch.co.uk/lab/hstssupercookies (“SuperCookieID”) together with my SiteSecurityServiceState.txt file.
I didn’t delete Firefox’s site preferences, only cache and cookies even if the latter two don’t change anything to the problematic here on Firefox.
SiteSecurityServiceState.txt normal : SupercookieID remains the same even after restart ;
SiteSecurityServiceState.txt 0byte Read-only : SupercookieID changes after restart ;
Whatever SiteSecurityServiceState.txt AND Private Mode : SupercookieID changes every time it is checked (without restart)
So now I’m testing SiteSecurityServiceState.txt 0byte Read-only together with HTTPS Everywhere which I’ve reinstalled after having dropped it for some time. Seems at this time to be a good combination.
What’s your setup now with regards to HSTS now that you’ve finished your testing (presumably)?
Or just use Pale Moon, problem solved.
HSTS is a web standard.
https://www.ietf.org/rfc/rfc6797.txt
It’s optional to enable/disable HSTS in Pale Moon, is what Corky was trying to say. Privacy vs. security choice.
Isn’t the problem, as Martin mention in the article, getting issued a unique ID which persists across browser sessions, when i used the site linked in the article i get a different ID when doing each of the tests listed.
I haven’t looked into it anymore than that as i just assumed as i wasn’t getting the same tracking ID each time that the tracking wouldn’t work.
Very very useful piece of information I was unaware of. Thanks Martin
This is most interesting and I feel ashamed of not having been aware of this when I am so deeply committed to privacy.
This could be an argument in favor of HTTPS Everywhere, the extension, together with creation of an empty SiteSecurityServiceState.txt set to Read-only. Correct me if I’m wrong.
Well, you learn every day. Many thanks, Martin.
It should be noted HTTPS Everywhere isn’t actually “everywhere” but where “every” is for what exists in its Rules: in the menu see View All Rules. A great tool in anyone’s browser privacy strategy, but not a fix-all.