Opened 5 years ago

Closed 9 months ago

Last modified 9 months ago

#6458 closed defect (duplicate)

Double-key HSTS for third party content

Reported by: mikeperry Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-linkability, tbb-bounty, tbb-firefox-patch
Cc: gk, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

With proper cache+identifier siloing to url bar origin, it is no longer a security issue to allow 3rd party content from HSTS urls to get loaded from non-HSTS sites. Therefore, we can disable HSTS enforcement for third parties in this case.

This will eliminate a super-cookie vector that HSTS creates (registering 32 domains, using HSTS for each domain as a bit).

This is going to be a painful patch to write, though...

Child Tickets

Change History (15)

comment:1 Changed 5 years ago by gk

  • Cc g.koppen@… added

comment:2 follow-up: Changed 5 years ago by mikeperry

gk: We currently clear HSTS on New Identity, but we do not disable it entirely. It's my feeling that an HSTS supercookie is a rather extremely visible and heavy-weight attack that is not worth disabling the security benefits of HSTS to mitigate. Do you disagree? Should we create a stopgap "Disable HSTS" ticket in the meantime until this one can get closed?

I could go either way. We also have until #5742 is closed to decide for sure, since that #5742 probably the current best known long term 3rd party linkability vector between "New Identity" invocations.

comment:3 in reply to: ↑ 2 Changed 5 years ago by gk

Replying to mikeperry:

gk: We currently clear HSTS on New Identity, but we do not disable it entirely. It's my feeling that an HSTS supercookie is a rather extremely visible and heavy-weight attack that is not worth disabling the security benefits of HSTS to mitigate. Do you disagree?

No.

Should we create a stopgap "Disable HSTS" ticket in the meantime until this one can get closed?

No.

What makes me a bit nervous here is relaxing the security requirements HSTS imposes (opening the road for e.g. injecting malicious scripts which could be prevented by HSTS) and how to translate that to the user. I mean, everybody is getting trained to "HSTS important in making your browsing session safer", right?. Thus, I wonder if we may find a better solution to this identifier problem (although I cannot come up with one yet). The one mentioned on http://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-HSTS-Persistence-and-Privacy.html does not help, though.

comment:4 Changed 4 years ago by mikeperry

  • Keywords tbb-bounty added

comment:5 Changed 3 years ago by erinn

  • Keywords tbb-firefox-patch added

comment:6 Changed 3 years ago by erinn

  • Component changed from Firefox Patch Issues to Tor Browser
  • Owner changed from mikeperry to tbb-team

comment:7 Changed 3 years ago by arthuredelstein

mikeperry on IRC wrote: "I thought there was also a project to crawl sites and transform any with hsts rules into https-everywhere rules". Here's an HTTPS Everywhere ticket to transform HSTS rules to HTTPS-Everywhere rules. https://github.com/EFForg/https-everywhere/issues/77

Would this allow us to turn off HSTS altogether?

comment:8 Changed 2 years ago by mikeperry

comment:9 Changed 2 years ago by gk

  • Cc gk added; g.koppen@… removed

https://bugzilla.mozilla.org/show_bug.cgi?id=648186 is the corresponding Mozilla bug.

comment:10 follow-up: Changed 2 years ago by mikeperry

  • Summary changed from Disable HSTS for third party content on non-HSTS domains to Double-key HSTS for third party content

http://tsyrklevich.net/2014/10/28/abusing-strict-transport-security/ is another PoC that is a bit more interesting. It uses the HSTS preload list to fingerprint the underlying Firefox ESR version, and then also uses the Tails homepage HSTS presence to fingerprint Tails users.

This example indicates that we shouldn't try any games with allowing HSTS for third parties only if the first party is HSTS, since that site could have been deployed on HTTPS+HSTS. To me, it indicates that we should fully double-key both the HSTS headers, and maybe also the preload list.

The good news is that this is probably not as tricky as I thought. I think we can get away with just patching the calls to the nsISecurityService in nsHttpChannel::ProcessSingleSecurityHeader() and nsHttpChannel::Connect(). I don't think we need to worry about the HPKP bits.

Double-keying the preload list may require some finesse though, since it covers a lot of API sources, and sites may have become dependent on it accidentally. I can think of a few heuristics:

  1. Only apply the preload list rules to third parties if the URL bar domain is in the preload list
  2. Only apply the preload list rules to third parties if the url bar is https
  3. Always apply the preload list

I think that either 2 or 3 are our best options.

comment:11 in reply to: ↑ 10 Changed 23 months ago by gk

Replying to mikeperry:

http://tsyrklevich.net/2014/10/28/abusing-strict-transport-security/ is another PoC that is a bit more interesting. It uses the HSTS preload list to fingerprint the underlying Firefox ESR version, and then also uses the Tails homepage HSTS presence to fingerprint Tails users.

This example indicates that we shouldn't try any games with allowing HSTS for third parties only if the first party is HSTS, since that site could have been deployed on HTTPS+HSTS. To me, it indicates that we should fully double-key both the HSTS headers, and maybe also the preload list.

The good news is that this is probably not as tricky as I thought. I think we can get away with just patching the calls to the nsISecurityService in nsHttpChannel::ProcessSingleSecurityHeader() and nsHttpChannel::Connect(). I don't think we need to worry about the HPKP bits.

I am not sure about that. Why do you think the HPKP bits are not an issue?

Double-keying the preload list may require some finesse though, since it covers a lot of API sources, and sites may have become dependent on it accidentally. I can think of a few heuristics:

  1. Only apply the preload list rules to third parties if the URL bar domain is in the preload list
  2. Only apply the preload list rules to third parties if the url bar is https
  3. Always apply the preload list

I think that either 2 or 3 are our best options.

Why do you want to double-key the preload list and what does it mean at all? The preload list is basically applied to all requests right from the beginning. The only thing that could leak here is the ESR version. But we are not concerned with different ESR versions as we only support the latest anyway due to security fixes.

comment:12 Changed 18 months ago by arthuredelstein

  • Cc arthuredelstein added
  • Severity set to Normal

comment:13 Changed 10 months ago by arthuredelstein

Here's another Mozilla ticket that seems like the way to go. HSTS could be isolated by OriginAttributes, which are going to include first party domain.
https://bugzilla.mozilla.org/show_bug.cgi?id=1253006

comment:14 Changed 9 months ago by arthuredelstein

  • Resolution set to duplicate
  • Status changed from new to closed

comment:15 Changed 9 months ago by arthuredelstein

Resolving this bug is a duplicate of #17965, because HSTS and HPKP work pretty much the same way and a single patch can solve both.

Note: See TracTickets for help on using tickets.