User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20151208100201 Steps to reproduce: # a) access site to get HSTS 1. Open firefox 2. Paste 'http://mail.ru/' in the address bar and press Enter 3. Close firefox when page is loaded # b) access site in the private mode 4. Open firefox again 5. Open private window 6. Paste 'http://mail.ru/' in the address bar and press Enter Any HTTP/1.x site with HSTS enabled can be used instead of 'http://mail.ru' to reproduce the issue. Actual results: First request is performed via HTTP. HSTS is ignored. It can lead to the following problems (in a public network for example): - an ssl strip attack is possible if the user is not attentive or experienced enough - some browsing history is exposed because http requests are sent in clear text Expected results: HTTP is not used, 'mail.ru' is accessed via HTTPS because of HSTS.

This seems like a logical consequence of bug 930638 which is public, so this can probably just be public too. Ehsan, can you confirm that this is by design?

POC links from bug 930638 are out of date, so maybe I missed something... As far as I understand it is possible to use https without cookies exposure in the private mode (equal to typing 'https://some.site' in the address bar). If no cookies are sent then a site can't get any sensitive information about a user.

(In reply to andreydanin from comment #2) > POC links from bug 930638 are out of date, so maybe I missed something... > > As far as I understand it is possible to use https without cookies exposure > in the private mode (equal to typing 'https://some.site' in the address bar). > > If no cookies are sent then a site can't get any sensitive information about > a user. https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/ is a reasonable explanation of the issue here, I believe.

Hmm, my recollection is that the design goal was for STS entries added in private mode to not leak to the non-private mode, not vice versa. Josh, does this look wrong to you too?

Ehsan: both directions are a privacy concern. How do we handle cookies? Any cookies set inside PB are thrown away -- of course! But also when you start a PB window you don't have any of your existing non-private cookies. Our current behavior (e.g. bug 930638) stems from worrying about the fact that HSTS can be abused to function like a tracking cookie. On the other hand, preserving HSTS data across the boundary would be safer against TLS-stripping downgrade attacks. The NakedSecurity article does a good job outlining the trade off. How do we treat the HTTP cache? I know PB cached files aren't persisted, but does PB take advantage of files cached in non-private mode? If not that bolsters our privacy-weighted approach to HSTS. If it does then since cached files can be detected in a supercookie-ish way we've demonstrated that privacy isn't our ultimate value and preserving HSTS security should win (as it has for Chrome). Don't know if Sid has time to poke his head in but I'll needinfo? him on this anyway.

I meant HSTS set in normal browsing functioning in private mode (as in this bug's summary); nobody is seriously suggesting that HSTS from a private session should persist outside that session.

(In reply to Daniel Veditz [:dveditz] from comment #5) > Ehsan: both directions are a privacy concern. How do we handle cookies? Any > cookies set inside PB are thrown away -- of course! But also when you start > a PB window you don't have any of your existing non-private cookies. Our > current behavior (e.g. bug 930638) stems from worrying about the fact that > HSTS can be abused to function like a tracking cookie. > > On the other hand, preserving HSTS data across the boundary would be safer > against TLS-stripping downgrade attacks. The NakedSecurity article does a > good job outlining the trade off. Yes, I understand. The point of disconnect for me is that I thought our implementation behaves as comment 4, and I'm not sure whether that is because my understanding was incorrect or I'm misremembering or what... I'm especially worried since I don't know what changed in bug 930638. > How do we treat the HTTP cache? I know PB cached files aren't persisted, but > does PB take advantage of files cached in non-private mode? No. > If not that You meant "If yes", right? > bolsters our privacy-weighted approach to HSTS. If it does then since cached > files can be detected in a supercookie-ish way we've demonstrated that > privacy isn't our ultimate value and preserving HSTS security should win (as > it has for Chrome). Having to trade off privacy and security like this really sucks. Especially since HSTS can not only let an attacker connect a private and non-private session, but also it allows them to uniquely identify the victim. :( The right thing to do here is certainly not obvious to me...

(In reply to Daniel Veditz [:dveditz] OOO until Jan 2016 from comment #5) > Don't know if Sid has time to poke his head in but I'll needinfo? him on > this anyway. Since you asked so nicely, here's my probably under-informed opinion. :) (In reply to :Ehsan Akhgari from comment #4) > Hmm, my recollection is that the design goal was for STS entries added in > private mode to not leak to the non-private mode, not vice versa. Josh, > does this look wrong to you too? This is my recollection too. The problem surfaces when we ship a "private browsing mode" where the adversary is both remote and local. HSTS was originally implemented with only local adversary in scope, which doesn't work for the new scope. (In reply to :Ehsan Akhgari from comment #7) > I'm especially worried since I don't know what changed in bug 930638. I'm not sure what Firefox currently does (I haven't tested or dug into all the related bugs). But yeah, what changed? I'm really curious! > Having to trade off privacy and security like this really sucks. Especially > since HSTS can not only let an attacker connect a private and non-private > session, but also it allows them to uniquely identify the victim. :( The > right thing to do here is certainly not obvious to me... I completely agree. But the design needs to be *crystal clear* about what private browsing should do before anyone can rationalize about what the right thing is. If PB is intended to avoid exposing any custom state to remote adversaries (I think this is the new PB goal), then the right thing feels like reverting to the factory default state for features like HSTS, cookies cache, or the whole profile. If the remote adversary is *not* the user's main threat (old PB style), we want to err on the side of security and use as much HSTS state as we can. If "remote tracking protection" is the direction we want the feature to eventually go, my opinion is that we want to reset all HSTS state when entering private mode. Based on how the mode is advertised in product and in marketing literature, I think this is the de-facto "legit" scope for PB, but that means more work to reduce browser state uniqueness needs to happen to do it right -- more than just resetting HSTS.

I don't remember the original intention for HSTS behaviour for private windows, but I also have no recollection of discussing the trade-off between privacy and security if I was involved in that work. Sorry.

Is it possible to have a warning (about missed redirect to httpS) in the private mode for a site with HSTS ? Example: User used some site in the common mode. HSTS was stored for the site. User opens the private mode and goes to the site. If redirect to httpS version of the site is missing while HSTS is set, then a) the site has changed or b) there is a MITM with ssl drop. Unfortunately multiple redirect options can be a problem in this scenario.