Prevent HSTS Super Cookies

[Mosrite]

Apparently, there is yet another instrument that could be used to track users using HSTS which is originally intended to enforce encrypted connections. http://www.radicalresearch.co.uk/lab/hstssupercookies/ Apparently, this can be circumvented by using incognito mode in the latest Firefox versions, so there seems to be a way around it (I think it is related to Website settings which are automatically deleted after a private session). Maybe this could be implemented in RAS as well so one doesn't have to use private browsing for protection against HSTS tracking?

[dillbyrne]

@Mosrite

The value never stays the same for me.

I'm blocking cookies with Cookie Monster. I'm allowing javascript for the purpose of the test with NoScript

Using RAS with the following options

random desktop sending the accept headers disabling authorization headers No referer is sent all the extras are enabled screen spoofing is set to profile timezone is set to random.

[dillbyrne]

After some testing it seems no script is causing it to fail in its tracking. The full addresses option has to be used under No Script's appearance tab and only allow "radicalresearch.co.uk" and block the rest . This is not a fix however as all the tracking could be bundled in one script.

Request policy may help with this also.

I will look into this when I get time and see if there is anything I can do.

[Mosrite]

Well, I guess it needs JS enabled and saving of website settings in Firefox. Therefore, if you check all extras within RAS browsing history is disabled which maybe disables saving of website settings as well? This is all just a guess, though... If I understand the method correctly then all it needs would be to make Firefox not saving the HSTS flags. I'm not sure if this would have any impact on security, though.

[dillbyrne]

@Mosrite

There may be a way to modify the HSTS header's max age attribute before the browser saves it or not save it at all.

As for how it works , from the limited reading I have done on it thus far the fingerprinting here appears to work by checking if you have HSTS flags set for a site you previously visited and then checks these sites against a list to get a fingerprint . No script in this case was blocking the other scripts doing the checking.

[RoxKilly]

A simple way to protect yourself against this, the evercookie and most other tracking mechanisms that rely on storing data on your computer is to run your browser within a sandbox such as Sandboxie (http://www.sandboxie.com/) before the tracker is set. Any tracker set within the sandbox will not survive once the sandbox is cleared at the end of the browsing session. Alternatively, if you install a clean Firefox profile and set Firefox to always browse in private mode, I don't think the tracker will survive between sessions since Firefox does not carry previous HSTS settings into a new private mode session If a site requires Javascript to function, then I can't think of any way to take advantage of the security benefit of HSTS without exposing myself to the possibility of being tracked. If Javascript is not required, as mentioned above, a default-deny stance (having Javascript disabled except for sites that require it to work) would protect against this.

[Mosrite]

I already did show that the private mode doesn't help. Blocking the hosts is the only way, so I highly recommend to use Firefox uMatrix - which is the strongest weapon atm or uBlock, both can handle hosts which already blocking the most known supercookies/evercookies if the somewherewhocares list was activated, the rest can be monitored by e.g. uMatrix/uBlock's own logging function (similar to the integrated dev console but it only shows the necessary stuff). Personally I use uMatrix since it's a bit stronger compared to uMatrix, it have a what is behind the scene filter [click dashboard - and then the uMatrix icon] -> together with the own logging function, nothing can bypass your eyes or browser without that you explicit can't control.

I don't understand how a hosts blocker would help. This is simply a blacklist approach which blocks certain domains entirely. Thus, they cannot use HSTS anymore, because they simply cannot be loaded at all. But what about the domains you want to use but you don't want to be tracked by? E.g. almost noone would block youtube.com per se. So, if YT would use HSTS for tracking purposes (I don't know if they actually do...), this wouldn't help a bit. Or am I missing something here?

[RoxKilly]

@CHEF-KOCH "A sandbox never protects against something which is established during a browser session, it only deletes the stuff after you're finished." The second part of your sentence is accurate, but the conclusion you draw in the first part is not accurate. The purpose of a persistent tracker is to recognize you. Clearing the sandbox once you finish browsing destroys any tracker stored on your machine. So after I restart my browser and return to the tracking website, it will not recognize me (based on this HSTS super cookie); thus the tracking is defeated; it only works during a single browsing session.

You also wrote "I already did show that the private mode doesn't help." If you use it as I indicated it will work. HSTS settings captured during private browsing are not saved when you close the browser. So if you are always in private browsing as I suggested, this form of tracking will not work between browsing sessions. I just tested this to make sure: 1) in private browsing mode (FF), go to http://www.radicalresearch.co.uk/lab/hstssupercookies (javascript enabled) and notice your tracker ID. 2) restart the browser (do not clear any sandbox) in private browsing and return to the page. The tracker ID will be new. You should have FF 34+. Check out the "update" section of http://arstechnica.com/security/2015/01/browsing-in-privacy-mode-super-cookies-can-track-you-anyway/

I also agree with Mosrite that a host blocker is not a good solution. Sure this type of tracking is not widely used today, but if it becomes widely used, blocking hosts would become impractical. This is for the same reason that disabling javascript is not a good solution to blocking canvas fingerprinting. It will break services that people want to use badly enough that they will accept the risk of tracking (gmail, youtube...).

As a side note, I am also a big fan of uBlock. It's a terrific add-on. Oh, and by the way, Sandboxie can be used for free, forever, legally. The limitations of the free version do not prevent browsing (or using any program) in a sandbox.

Thanks for the info about FF42

[RoxKilly]

@CHEF-KOCH You make some good points, but your argument has moved far away from the topic: HSTS super cookie tracking. The reason sandboxing works to prevent this type of tracking is that this type of tracking depends on the server writing and later reading the contents of a file on your machine. There is nothing "uploaded" to the server. Once the sandbox destroys what the server wrote, the HSTS data is lost at the next visit, the server is unable to recognize the machine.

It is for that same reason that private browsing defeats this type of tracking. The private browsing mode does not give the server access to the information it needs to recognize/track you once you begin a new browsing session. When you make the point that because your data has already been uploaded there is nothing to be done, you are either talking about something else or misunderstanding how HSTS tracking works. In fact the mechanism is very similar to how cookies work, except that the HSTS data is not stored as a simple cookie file, but as a setting in the browser.

Of course the server could track the machine using other techniques but I will not address the other types of tracking you bring up because they are beyond the scope of this specific issue. All I wanted to show is how to defeat HSTS super cookie tracking. It can be done easily, without a new add-on/browser feature etc...

[RoxKilly]

@CHEF-KOCH You misunderstand me. When I wrote that the sandbox "prevents this type of tracking" I think you understood it to mean the sandbox prevents the server from setting the cookie. That's not what I was saying. I agree the sandbox does not prevent a cookie from being set. However the sandbox prevents tracking by deleting the cookie, thus making it useless for tracking purposes.

Remember that just setting the cookie is not tracking. Tracking can only succeed if the server can recognize the user to follow him over time. After the sandbox is emptied, the next time I visit the site, it will not recognize me (based on HSTS). Think of it this way: if I clear the sandbox between browsing sessions, how could a site use HSTS data to track me over time?

Again you talked about stealing credit card numbers, downloading malware etc... These things are off-topic from HSTS tracking, so I am not responding to those statements. I think where you and I agree (for different reasons) is that HSTS tracking is not a big deal and can be easily defeated (just running in private mode will defeat it in FF 34+), so this add-on (Random Agent Spoofer) should prioritize other vulnerabilities.