Malicious users can track whether users have visited servers sending down an HSTS Strict-Transport-Security header without being present in the HSTS preload list. The HSTS standard specifies that for servers using HSTS, connections over port 80 must be redirected to port 443, but that HTTP requests to other ports must be transparently proxied to HTTPS on the same port. An attacker can request valid resources from http://hstsserver.com:443 and use onerror/onload handlers to determine whether that server is in the HSTS cache by seeing whether the request fails (not in the cache) or succeeds (transparently proxied to HTTPS on 443 because it's in the cache) This attack affects very few servers, but does allow attackers to determine ESR minor releases by looking for differences in the HSTS list and track some websites and FF configurations (e.g. http://tsyrklevich.net/2014/10/28/abusing-strict-transport-security/ details such an attack to track whether users are using TAILS and which versions they are using.)

Looks like Blink plans to disallow HTTP to port 443. See https://chromium.googlesource.com/chromium/src.git/+/b6cf19c7b9dd536405c3c4f80876411733c9d5a5

And they've reverted their patch due to web compat fallout. See https://code.google.com/p/chromium/issues/detail?id=439797 for the fallout and https://code.google.com/p/chromium/issues/detail?id=436451 for the Blink issue where they made and reverted the change.

In particular timing attacks from https://code.google.com/p/chromium/issues/detail?id=436451#c21 rings true. What did seem interesting is that they claim this broke WebSocket as well. Are they applying HSTS to WebSocket URLs? https://code.google.com/p/chromium/issues/detail?id=439797

No, apparently people use ws://something:443 (so non-encrypted websocket on port 443) to tunnel through firewalls that are blocking port 80.

Hmm yes, but still unclear why WebSocket URLs would have changed given a change to HTTP URLs motivated by HSTS rewrites.

The change Chrome tried was to block all HTTP traffic on port 443. That includes http:// and ws:// URLs. But yes, I expect they did that because they do in fact apply HSTS to websocket. We might too, actually; worth checking.

We do, it turns out. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27554 to get the specification updated since nobody acted on the comment about that in the original bug :-( Not sure what remains for this bug. Unless we have a way to defeat timing attacks, there's not much we can do here.

Would this combination work? 1. Make http://hstsserver.example:443 fail instead of upgrading to https on the same port. This redirect wouldn't work without HSTS, so it doesn't make sense for it to work with HSTS. (This would violate the letter of RFC 6797, but it's not clear this is intentional: who serves HTTP and HTTPS on the same port?) 2. Reduce the timing precision of "onerror" for cross-origin loads.

Reducing timing precision seems really hard. You can probably figure it out from simply loading http://hstsserver.example/ as well and then measuring whether you got a redirect or instant upgrade. There's also: http://www.radicalresearch.co.uk/lab/hstssupercookies/ HSTS is rather annoying when it comes to tracking :-(

@jess(In reply to Jesse Ruderman from comment #9) > Would this combination work? > > 1. Make http://hstsserver.example:443 fail instead of upgrading to https on > the same port. This redirect wouldn't work without HSTS, so it doesn't make > sense for it to work with HSTS. (This would violate the letter of RFC 6797, > but it's not clear this is intentional: who serves HTTP and HTTPS on the > same port?) > > 2. Reduce the timing precision of "onerror" for cross-origin loads. #2 is a good idea on it's own. #1 was shot down in Chromium, and it seems like the same issue would affect FF?

I think what was shot down in Chromium was blocking http to port 443 entirely. What if we just "blocked" it for HSTS sites?

That doesn't seem unreasonable to me (though the inner workings and interactions of HSTS and websockets are a mystery to me.)

I believe that this can be closed with Bug 1323644 being fixed.

(In reply to Tom Ritter [:tjr] from comment #14) > I believe that this can be closed with Bug 1323644 being fixed. (In reply to Vlad Tsyrklevich from comment #0) > Malicious users can track whether users have visited servers sending down an > HSTS Strict-Transport-Security header without being present in the HSTS > preload list. The HSTS standard specifies that for servers using HSTS, > connections over port 80 must be redirected to port 443, but that HTTP > requests to other ports must be transparently proxied to HTTPS on the same > port. > > An attacker can request valid resources from http://hstsserver.com:443 and > use onerror/onload handlers to determine whether that server is in the HSTS > cache by seeing whether the request fails (not in the cache) or succeeds > (transparently proxied to HTTPS on 443 because it's in the cache) > > This attack affects very few servers, but does allow attackers to determine > ESR minor releases by looking for differences in the HSTS list and track > some websites and FF configurations (e.g. > http://tsyrklevich.net/2014/10/28/abusing-strict-transport-security/ details > such an attack to track whether users are using TAILS and which versions > they are using.) The isolation on HSTS cache introduced in bug 1323644 can prevent users visits being tracked, but the preloaded HSTS list is still detectable. Besides, the isolation only works when the pref privacy.firstparty.isolate is on. I'm not sure if this bug should be considered resolved.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258