Open Bug 891629 Opened 11 years ago Updated 2 years ago

Blocking storage of HSTS data for third-party domains (when requested)

Categories

(Core :: Security, defect)

x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: jbonneau, Unassigned)

Details

(Keywords: privacy)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36

Steps to reproduce:

1) Disable third-party cookies
2) Load a page firstparty.com which loads a resource from a third-party HSTS domain https://thirdparty.com
3) Attempt to access http://thirdparty.com


Actual results:

The HSTS pin set for thirdparty.com is retained, so the request is re-written to http://thirdparty.com


Expected results:

The HSTS pin should not have been stored since the user requested no third-party storage of data. This applies to other scenarios like blocking a specific site from setting cookies, or blocking all sites. 

The ability to set HSTS pins could potentially be used for tracking through the use of subdomains-a site can set up N subdomains https://1.example.com, https://2.example.com, etc. and then direct a user to a unique subset of these domains which will set HSTS pins with includeSubdomains set. The site can then direct users to load a resources from http://test.x.example.com for x in [1, N] and the loads will fail for domains which had HSTS pins set, recovering the a unique fingerprint from a set of 2^N possibilities...

See https://bugzilla.mozilla.org/show_bug.cgi?id=648186, though the important point here is that HSTS data should not be stored for third-party domains or other situations where the user has requested not to have data stored which can be used for tracking...
Summary: HSTS → Blocking storage of HSTS data for third-party domains (when requested)
Component: Untriaged → Security
Keywords: privacy
Product: Firefox → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.