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

51–56 of 56 posts

Re: HSTS Super Cookies

#51

Post by frenchpress »

agwa wrote: post #14

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…

Ran the above query on my Fx 34.0.5 profile, which is set to clear all history, cookies, cache, etc. on close of each session.

Among the entries was one named track.nextuser.com

"About NextUser: We believe every user should have an experience personalized for them..."

That doesn't sound very promising.

Re: HSTS Super Cookies

#52

Post by agwa »

frenchpress wrote: post #51
agwa wrote: post #14

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…

Ran the above query on my Fx 34.0.5 profile, which is set to clear all history, cookies, cache, etc. on close of each session. Among the entries was one named track.nextuser.com "About NextUser: We believe every user should have an experience personalized for them..." That doesn't sound very promising.

> Among the entries was one named track.nextuser.com

In order to be a supercookie they need more than one entry (since each entry only stores 1 bit of information). Do you see any other entries that look like they could be associated with this one?

Re: HSTS Super Cookies

#53

Post by agwa »

WireWrap wrote: post #48
agwa wrote: post #14

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…

They were recently moved to the SiteSecurityServiceState.txt file: https://bugzilla.mozilla.org/show_bug.cgi?id=775370

Good grief. They've replaced a SQLite database with a text file that's loaded into an in-memory hash table because "adoption of HSTS is not very widespread yet" so "using any kind of off-the-shelf database to store this would be inefficient and overly complex." This required a patch that took over a year to review, during which time issues were raised with the text file parser they had to write from scratch. Loading the whole table into memory has clear DoS implications, so they're limiting the table to 1024 entries (making the use of a hash table rather silly), with an eviction strategy[1] that is going to favor older entries and effectively prevent newer entries from being added.

[1] https://hg.mozilla.org/releases/mozilla-aurora/rev/b339d53f9...

Re: HSTS Super Cookies

#54

Post by cm2187 »

Am I right to understand that this can even be a server side cookie, i.e. that it can't even be killed by disabling javascript (since the server can tell if there was a redirect)?

Re: HSTS Super Cookies

#55

Post by phlogisticfugu »

It seems like the main use case for HSTS is with the site being requested by the user in the URI bar, for protecting cookies and login credentials associated with that domain.

It does not seem like there's a major use-case for secondary resources: images, css, javascript, etc loaded on the page itself, and which serve as the vector in this attack. Such resources must be requested via https on a https site itself anyways.

So, wouldn't it be better to just restrict the usage of HSTS protocol overrides to just the main domain being requested by the user in the URI bar?

Re: HSTS Super Cookies

#56

Post by jcrawfordor »

Buge wrote: post #44
jcrawfordor wrote: post #31

I'm actually pretty irritated that this researcher makes it out as an iOS thing only, it feels like he/she just didn't care to try on anything other than the device they had in front of them. Chrome on Android behaves the same way the researcher described (fingerprinting works in Incognito tabs), but Chrome, Opera, Firefox, and IE on Windows all get different IDs.

I got the same ID on Chrome on Windows.

Uh-oh, looks like I made a mistake. I get the same behavior on Chrome on Windows too.
Post reply on HN