Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HSTS Super Cookies

radicalresearch.co.uk

Post reply on HN
Print view View original

11–20 of 56 posts

Re: HSTS Super Cookies

#14

Post by agwa »

Firefox stores HSTS entries in a SQLite database, which you can query by running:

  echo "SELECT * FROM moz_hosts WHERE type='sts/use';" | sqlite3 permissions.sqlite
from inside your profile directory.

To clear HSTS entries (which the "Clear recent history" UI does not delete), you can do:

  echo "DELETE FROM moz_hosts WHERE type='sts/use';" | sqlite3 permissions.sqlite
I've been periodically monitoring this database for HSTS supercookies over the last couple years and have yet to see any in the wild.

Re: HSTS Super Cookies

#15

Post by schoen »

spacefight wrote: post #10
xyby wrote: post #8

I have Chromium set to delete browsing data on close. The HSTS Cookie survives that. Manually deleting browsing data kills it.

That would somehome indicate to me (without having looked at the code), that this has been implemented like this on purpose.

The basic background problem is that in the "normal" case, HSTS is a security and privacy protection rather than a tracking mechanism. That's why one would typically want it to persist as much as possible. But it has the potential for tracking effects too (as this project demonstrates). I guess the current browser behavior is indeed an attempt to project user intentions based on that.

Re: HSTS Super Cookies

#16

Post by f- »

schoen wrote: post #7
schoen wrote: post #2

This privacy risk is actually documented in the official HSTS specification, section 16.9 of https://www.rfc-editor.org/rfc/rfc6797.txt However, the spec doesn't propose a mitigation for it. I'm afraid many new security policy mechanisms can actually be used to track users or devices this way, because you can experiment to see whether the browser has heard about a particular security policy by observing its behavior…

The HPKP tracking problem is described in section 5 https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinni... which also includes another description of this HSTS problem.

We also have a pretty comprehensive discussion of this and many other vectors in:

http://www.chromium.org/Home/chromium-security/client-identi...

Re: HSTS Super Cookies

#17

Post by thijsw »

Tomdarkness wrote: post #9

Seems Chrome has addressed the issue with incognito mode - if you open the page in incognito mode you get a different code.

Not for me. Mac OS X 10.10.1, Chrome 39.0.2171.95. I get the same code even in incognito mode.

Re: HSTS Super Cookies

#18

Post by schoen »

f- wrote: post #16
schoen wrote: post #7

Earlier quoted context omitted.

The HPKP tracking problem is described in section 5 https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinni... which also includes another description of this HSTS problem.

We also have a pretty comprehensive discussion of this and many other vectors in: http://www.chromium.org/Home/chromium-security/client-identi...

Thanks, I didn't know about that article.

Re: HSTS Super Cookies

#19

Post by JadeNB »

> The impact is that it's possible for a site to track you even if you choose to use "incognito" or "private" browsing features in an effort to avoid such tracking.

I've always thought that (despite user hopes) the point of 'private' browsing was explicitly and only to avoid leaving traces on the user's computer anyway. (For example, I used it when shopping for Christmas presents.) The Firefox new private window has a warning to this effect:

> While this computer won't have a record of your browsing history, your employer or internet service provider can still track the pages you visit.

Re: HSTS Super Cookies

#20

Post by jjmason »

Wow, can't get it to go away on Firefox 33.0 Ubuntu. I was able to clear it by manually deleting the info from the permissions.sqlite3 database as described by agwa.

Very clever!

Post reply on HN