[tbb-bugs] #6458 [Tor Browser]: Double-key HSTS for third party content

[Tor Bug Tracker & Wiki]

#6458: Double-key HSTS for third party content
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  tbb-team
  mikeperry              |     Status:  new
         Type:  defect   |  Milestone:
     Priority:  major    |    Version:
    Component:  Tor      |   Keywords:  tbb-linkability, tbb-bounty, tbb-
  Browser                |  firefox-patch
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by gk):

 Replying to [comment:10 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
 > 1. Only apply the preload list rules to third parties if the url bar is
 https
 > 1. 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6458#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online