Wait does that mean hsts cache is per origin?
That seems like it would make tls stripping attacks a lot easier.
That seems like it would make tls stripping attacks a lot easier.
I'm not saying any of those approaches is bulletproof, just that maybe they have a more complex strategy in mind to mitigate risk.
> Or to randomly respect the cache
If the goal is to manipulate a single request to insert malicious js that gets cached, you only need a single non tls request. If you're an on path attacker, you can probably get the user to request things multiple times (e.g. randomly break and unvlbreak internet connectivity) until you get lucky with an unencrypted connection. If you're trying to make a super cookie you can just repeat and average out the random failures (random pertubation almost never prevents a side channel leak, at most it makes it more expensive)
>Or to simply make every request to both the TLS and non-TLS port but do so in parallel and discard the non-TLS response if the domain was in the HSTS cache.
Fails at confidentiality 100% of the time