|
|
|
|
|
by CydeWeys
2677 days ago
|
|
In Chromium, the whole HSTS preload list is expired if it gets too out of date, as domains are both added to and removed from the list. So you're giving up real security by running an out-of-date browser. Not only are HSTS-preloaded TLDs not secured, but even, say, gmail.com or yourbank.com aren't. See: https://chromium.googlesource.com/chromium/src/+/lkgr/compon... I think it'd be better to use an out-of-date list instead of nothing; I should go push for that again. |
|
(2) is not really a concern any more, (3) occasionally becomes a concern, (1) is a concern for most of the web, and (4) is a concern for literally every use of HSTS.
The whole point of HSTS is to ward off man-in-the-middle. If all a man in the middle has to do is wait, and is eventually guaranteed a shot at exploiting you, they will. So all HSTS gives you is the small hedge that if an attacker is present, but not persistent, and not targeting you specifically, you're slightly more secure.
Basically, it only protects you if a random hacker is sitting in a coffee shop you don't normally go to, and only if your browser is up to date, and only if every site you want to visit uses HSTS, and only if you've visited them before. It's so incredibly specific that it's almost pointless.
A better solution would be either (A) an extention to the specification to actually support a "secure://" URI prefix, or (B) a proxy or browser mode that only allows valid HTTPS connections. These are user interface fixes, because the entire point of HSTS is to prevent users (and really bad apps, I guess) from accidentally using HTTP.