3 ms·
Maybe. But a more clever approach might be to limit the size of the HSTS cache per second-level-domin per orign. Or to randomly respect the cache. Or to simply
by kag0 6y ago
Maybe. But a more clever approach might be to limit the size of the HSTS cache per second-level-domin per orign. Or to randomly respect the cache. 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.
I'm not saying any of those approaches is bulletproof, just that maybe they have a more complex strategy in mind to mitigate risk.
- bawolff 6y agoThose would be much worse strategies than even just not supporting hsts at all. > 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