Why is implementing HSTS and preserving the current behavior more useful?
I believe trying HTTPS first wouldn't help: the MITM would refuse your connection, and your browser will try HTTP after that.
With HSTS, the server tells your browser that it is going to support HTTPS for a while. Now, if your first connection to server is secure (no MITM), from now on your browser will know that this particular domain supports HTTPS. So, it will know something fishy is going on if a MITM tries to pretend otherwise.
Probably other unknown vulnerabilities could be averted by just trying HTTPS first too. Not doing so should be considered bad practice, with or without HSTS.
Probably there will come a time when attempting HTTPS first instead of HTTP for manually-typed URLs without a protocol is the right default, but that's just a subset of the problem.
Doing https first would mean those sites were broken.
On a related note, would strict mode thwart HSTS-based cookies?
My current understanding of this technique is that it depends on the victim being able to connect to HTTP. Since strict mode prevents the victim from making normal HTTP connections, I'm inclined to believe that strict mode does help mitigate this kind of tracking.
If you try https first, and that fails, do you try again over http? Whether or not you'd fallback would leak the same information.
Note that this is for the page that was loaded only, not for additional resources hosted on other hostnames.
Would example.amazon.co.uk then not be able to set HSTS for amazon.co.uk?
The includeSubDomains directive[2] allows the HSTS policy set for amazon.co.uk to apply to its subdomain example.amazon.co.uk, but not vice versa.
I've asked here: https://twitter.com/gsnedders/status/974765437283119104
I appreciate this part. Do they actually respond to these inquiries?
Could someone explain this?
> 15. HSTS and HPKP supercookies
> An extreme (but not impossible) attack to mount is the creation of HSTS supercookies. Since HSTS effectively stores one bit of information per domain name, an adversary in possession of numerous domains can use them to construct cookies based on stored HSTS state.
> HPKP provides a mechanism for user tracking across domains as well. It allows abusing the requirement to provide a backup pin and the option to report a pin validation failure. In a tracking scenario every user gets a unique SHA-256 value serving as backup pin. This value is sent back after (deliberate) pin validation failures working in fact as a cookie.
> Design Goal: HSTS and HPKP MUST be isolated to the URL bar domain.
> Implementation Status: Currently, HSTS and HPKP state is both cleared by New Identity, but we don't defend against the creation and usage of any of these supercookies between New Identity invocations.
0) https://www.torproject.org/projects/torbrowser/design/ [February 19th, 2018]
