4 ms·

> HSTS was dead in the water from day one. No, it has served and is serving a useful purpose (reducing MITM risk) for a large number of websites.

dcow 3y ago
You know what, I was thinking of HPKP, which is obsolete. HSTS, while I doubt it’s actually prevented a single adversarial MITM, isn’t a terrible idea.
BrandoElFollito 3y ago
Could you explain shortly what can be prevented? The hard part is I believe to spoof the DNS entry and then get a cert from a CA they is in the browser root. Were there cases where HSTS actually stopped something after that? (serious question - I always wondered how much of a peripheral problem HSTS solves)
- Dylan16807 3y ago
  I'm confused by your question. The entire point is to force an attacker to do "the hard part" that you list there, which is genuinely very hard to do. So it won't do anything "after" that.
  - BrandoElFollito 3y ago
    Sorry for not having been clear. Put it another way: are there hard stats about HSTS actual value? How many orgs that had their DNS defaced and new certs issued were saved by HSTS? Since a mistake with HSTS is catastrophic, setting it must make sense risk wise.
    - Dylan16807 3y ago
      Are you confusing HSTS with HPKP like the other poster? HSTS says the site has to be https, nothing else. It does nothing if someone gets a valid cert. It exists to prevent every attack weaker than that, such as local MitM. And mistakes are not catastrophic at all unless you have some horrible legacy setup that can't do https.
      - BrandoElFollito 3y ago
        oh crap, I was thinking HPKP and reading/writing HSTS. Sorry for the entropy. Yes, HSTS (this time HSTS :)) is useful (though there are problems with scaling for the initial seed of pages, but maybe that was already solved).
- dspillett 3y ago
  Once you have managed to poison DNS, so your server is contacted instead of the right one, without HSTS you could potentially⁰ serve your responses using plain HTTP with no in-your-face warning to the user¹. With HSTS that initial request won't be plain HTTP if the user has been to the site before or the name is present in their browser's HSTS preload list. Chrome will default to HTTPS when given a typed URL that doesn't specify protocol these days, falling back to HTTP if that connection fails, but that doesn't protect you from plain HTTP links in other pages or stored as bookmarks. In fact this doesn't protect you as much as you think it might: IIRC this fallback to HTTP happens for any connection error including being served an invalid certificate, so a DNS-poisoning based MitM attack could still work for some users² meaning HSTS would still be useful even if all browsers used the same HTTPS-default-HTTP-fallback procedure. > I always wondered how much of a peripheral problem HSTS solves HSTS, especially with preload, solves a potentially serious but likely-to-be-rare problem. Even if the circumstances where it saves the day are rare, it is so easy to implement it is worth (IMO) the small amount of admin for that protection. -- [0] if the initial request is plain HTTP [1] some browsers will display an “insecure” flag when a page delivered by HTTP contains a form, or at least a form with a password box, but a user focusing on just what they are typing may not notice that [2] as the fallback to HTTP, if not blocked by HSTS, will happen without warning

dcow 3y ago

You know what, I was thinking of HPKP, which is obsolete. HSTS, while I doubt it’s actually prevented a single adversarial MITM, isn’t a terrible idea.

BrandoElFollito 3y ago

Could you explain shortly what can be prevented? The hard part is I believe to spoof the DNS entry and then get a cert from a CA they is in the browser root. Were there cases where HSTS actually stopped something after that? (serious question - I always wondered how much of a peripheral problem HSTS solves)

Dylan16807 3y ago
I'm confused by your question. The entire point is to force an attacker to do "the hard part" that you list there, which is genuinely very hard to do. So it won't do anything "after" that.
- BrandoElFollito 3y ago
  Sorry for not having been clear. Put it another way: are there hard stats about HSTS actual value? How many orgs that had their DNS defaced and new certs issued were saved by HSTS? Since a mistake with HSTS is catastrophic, setting it must make sense risk wise.
  - Dylan16807 3y ago
    Are you confusing HSTS with HPKP like the other poster? HSTS says the site has to be https, nothing else. It does nothing if someone gets a valid cert. It exists to prevent every attack weaker than that, such as local MitM. And mistakes are not catastrophic at all unless you have some horrible legacy setup that can't do https.
    - BrandoElFollito 3y ago
      oh crap, I was thinking HPKP and reading/writing HSTS. Sorry for the entropy. Yes, HSTS (this time HSTS :)) is useful (though there are problems with scaling for the initial seed of pages, but maybe that was already solved).
dspillett 3y ago
Once you have managed to poison DNS, so your server is contacted instead of the right one, without HSTS you could potentially⁰ serve your responses using plain HTTP with no in-your-face warning to the user¹. With HSTS that initial request won't be plain HTTP if the user has been to the site before or the name is present in their browser's HSTS preload list. Chrome will default to HTTPS when given a typed URL that doesn't specify protocol these days, falling back to HTTP if that connection fails, but that doesn't protect you from plain HTTP links in other pages or stored as bookmarks. In fact this doesn't protect you as much as you think it might: IIRC this fallback to HTTP happens for any connection error including being served an invalid certificate, so a DNS-poisoning based MitM attack could still work for some users² meaning HSTS would still be useful even if all browsers used the same HTTPS-default-HTTP-fallback procedure. > I always wondered how much of a peripheral problem HSTS solves HSTS, especially with preload, solves a potentially serious but likely-to-be-rare problem. Even if the circumstances where it saves the day are rare, it is so easy to implement it is worth (IMO) the small amount of admin for that protection. -- [0] if the initial request is plain HTTP [1] some browsers will display an “insecure” flag when a page delivered by HTTP contains a form, or at least a form with a password box, but a user focusing on just what they are typing may not notice that [2] as the fallback to HTTP, if not blocked by HSTS, will happen without warning