930638 - HSTS state can track users, follows them in to private browsing mode

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[cagerton]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36

Steps to reproduce:

1) Set HSTS for a domain using Strict-Transport-Security header while in regular browsing mode.
2) Open a new private browsing window and attempt to hit the insecure version of the site.



Actual results:

The private browsing window respects the HSTS settings learned in normal browsing mode. You can use many subdomains to store arbitrary tracking ids.

Here is working proof of concept + links to an old chrome bug discussing a very similar problem: http://stain.cardsnip.com/stain/faststain.html?ff (Use the http version since mixed content blocking currently breaks the demo)


Expected results:

The private browser tabs should only honor pre-loaded HSTS state or state learned during the private browsing session.

Comment 1

[(no longer active)]

I'm not sure if I understand this bug correctly.  Is this about us remembering the HSTS entries set inside private browsing mode for the duration of that session?  If so, I don't think that's a privacy risk.  What am I missing?

Comment 2

[cagerton]

(In reply to :Ehsan Akhgari (needinfo? me!) [Away 10/29-11/6] from comment #1)
> I'm not sure if I understand this bug correctly.  Is this about us
> remembering the HSTS entries set inside private browsing mode for the
> duration of that session?  If so, I don't think that's a privacy risk.  What
> am I missing?

This is about setting HSTS state outside of private browsing mode and being able to later read HSTS state inside private browsing mode.  Try setting an ID with that demo in regular mode then open a private browsing window and you will be able to read that ID.

Comment 3

[cagerton]

Is it generally acceptable to have state which can be written in a normal browsing session and read back inside a private browsing session?

Would it be okay for an advertising company to store user tracking IDs during a normal browsing session and read during private browsing sessions?

The demo that I linked to can be used for exactly this. I've tested setting IDs in a regular session for firefox 24 and 25 then opening a new private session and reading those IDs.

Let me know if you have any trouble reproducing it.

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140213030201 CSet: a62bde1d6efe.

But as discussed in https://code.google.com/p/chromium/issues/detail?id=104935 this should be kept as is ("security vs. privacy").

Comment 5

[Rob Wu [:robwu]]

I've confirmed that HSTS is no longer shared between normal and Private browsing mode as of Firefox 34, as follows:

1. Start Firefox with a new profile.
2. Open the developer tools, Network tab.
3. Visit a website that is not on the preloaded HSTS list over http (e.g. my website).
4. Observe that a 301 redirect is being performed to https (which replies with a HSTS header).
5. Open a private browsing window and repeat step 2 - 3.

Results after step 5:
Firefox 33 and earlier: No 301 redirect is seen, which indicates that HSTS carried over from non-Private to private mode.
Firefox 34 and later (including 41.0.1): A 301 redirect is seen, which shows that HSTS state is split.

Comment 6

[Tanvi Vyas[:tanvi]]

(In reply to Rob Wu from comment #5)
> I've confirmed that HSTS is no longer shared between normal and Private
> browsing mode as of Firefox 34, as follows:
> 
Ehsan, do you know what bug this is fixed in?

HSTS benefits security.  While not using regular mode HSTS state in private mode increases privacy, it decreases security.  Hence, I'm not sure this is what we want to do here.  Which is the bigger risk?  A tracking domain catches you in private browsing mode?  Or a MITM steals you cookies and changes the content of your page?

Comment 7

[(no longer active)]

(In reply to Tanvi Vyas [:tanvi] from comment #6)
> (In reply to Rob Wu from comment #5)
> > I've confirmed that HSTS is no longer shared between normal and Private
> > browsing mode as of Firefox 34, as follows:
> > 
> Ehsan, do you know what bug this is fixed in?

No...  I looked around and couldn't find anything relevant.

> HSTS benefits security.  While not using regular mode HSTS state in private
> mode increases privacy, it decreases security.  Hence, I'm not sure this is
> what we want to do here.  Which is the bigger risk?  A tracking domain
> catches you in private browsing mode?  Or a MITM steals you cookies and
> changes the content of your page?

Are you following bug 1232961?  See bug 1232961 comment 7.  The short answer is I don't know.  :(