4 ms·

HSTS Preload List: State of the Union 2016

30 points by pred_ 11y ago

tshtf 11y ago
Interesting to see a high-profile domain requesting removal: https://bugs.chromium.org/p/chromium/issues/detail?id=527947 https://bugs.chromium.org/p/chromium/issues/detail?id=527947 uber.com: Issues with subdomains maintained by contractors. Of course there's an order of magnitude more insignificant sites requesting removal.... It's pretty clear that HSTS Preload isn't going to scale.
- geofft 11y ago
  Manual HSTS preload isn't the only way to make it scale, and it probably wasn't going to scale even if nobody wanted to be removed. You could automate the process for both additions and removals entirely, and make it a separate thing the browser keeps up-to-date independently of itself, as mentioned in the article.
- deleted 11y ago
  [deleted]
david_shaw 11y ago
It's awesome to see that intense hockey-stick growth for sites on the HSTS preload list. I think soon it will seem weird for a TLS-enabled site to not use HSTS.
- skywhopper 11y ago
  I honestly can't think of a reason not to except for very specific cases. It's trivially easy to send the header, and the only thing you are promising is that you will continue providing your site over TLS.
  - dantiberian 11y ago
    One reason discussed in the article is that it would force any internal company sites at internal.bigco.com to use TLS too. This is fine in theory, but is a large amount of work in practice to make sure every internal site, dashboard, monitoring tool, etc uses TLS.
    - geofft 11y ago
      The HSTS header allows you to specify "includeSubDomains" or not, as you like. The thing the article discusses is, if you're on the HSTS preload list (your HSTS entry is hard-coded into the browser binary), Chromium policy is to require that includeSubDomains be set. It's technically possible for them to add an includeSubDomains=false entry on the preload list, they just choose not to.
      - toomuchtodo 11y ago
        If you're using HSTS, you need to include subdomains to prevent http/https issues with subdomain-served resources, hence the requirement to include subdomains if you're on the preload list.
        colanderman 11y ago
        I don't get this. If my pages are served over https, aren't they forbidden from accessing non-https content, HSTS or not?
        toomuchtodo 11y ago
        No, not when it comes to subdomains and domain-level cookies. https://shrikantadhikarla.wordpress.com/2013/02/18/anatomy-of-includesubdomains-directive-in-http-strict-transport-security-policy/ https://shrikantadhikarla.wordpress.com/2013/02/18/anatomy-o...
        colanderman 11y ago
        Sorry, that page makes no sense to me. Beside not addressing my original question at all (which was about accessing non-https content from an https context): 1) I don't understand how an attacker would manage to "register" a sub-domain within a domain I control. AFAIK this would require a DNS MITM. 2) How can the attacker's HTTP server present a TLS certificate? Presumably the author missed a step in there; a redirect? 3) Why is an intermediate HTTP request even necessary in this scenario? If a browser is pointed at the false sub-domain via https and the user clicks through the TLS cert, won't it give up the domain cookie regardless? 4) Given #3, the only benefit I see includeSubdomains providing is that it changes the TLS cert warning into an error. Is this a correct analysis? A much more realistic scenario would be that an attacker MITMs an existing HTTP-only subdomain and upgrades it to HTTPS with a false cert. Or that an attacker MITMs DNS to serve a false HTTPS subdomain. (I think the author conflated these two scenarios.) In these cases I see the safety includeSubdomains would provide, albeit one that DNSSEC would also provide.
deleted 11y ago
[deleted]

30 points by pred_ 11y ago

tshtf 11y ago

Interesting to see a high-profile domain requesting removal: https://bugs.chromium.org/p/chromium/issues/detail?id=527947 https://bugs.chromium.org/p/chromium/issues/detail?id=527947 uber.com: Issues with subdomains maintained by contractors. Of course there's an order of magnitude more insignificant sites requesting removal.... It's pretty clear that HSTS Preload isn't going to scale.

geofft 11y ago
Manual HSTS preload isn't the only way to make it scale, and it probably wasn't going to scale even if nobody wanted to be removed. You could automate the process for both additions and removals entirely, and make it a separate thing the browser keeps up-to-date independently of itself, as mentioned in the article.
deleted 11y ago
[deleted]

david_shaw 11y ago

It's awesome to see that intense hockey-stick growth for sites on the HSTS preload list. I think soon it will seem weird for a TLS-enabled site to not use HSTS.

skywhopper 11y ago
I honestly can't think of a reason not to except for very specific cases. It's trivially easy to send the header, and the only thing you are promising is that you will continue providing your site over TLS.
- dantiberian 11y ago
  One reason discussed in the article is that it would force any internal company sites at internal.bigco.com to use TLS too. This is fine in theory, but is a large amount of work in practice to make sure every internal site, dashboard, monitoring tool, etc uses TLS.
  - geofft 11y ago
    The HSTS header allows you to specify "includeSubDomains" or not, as you like. The thing the article discusses is, if you're on the HSTS preload list (your HSTS entry is hard-coded into the browser binary), Chromium policy is to require that includeSubDomains be set. It's technically possible for them to add an includeSubDomains=false entry on the preload list, they just choose not to.
    - toomuchtodo 11y ago
      If you're using HSTS, you need to include subdomains to prevent http/https issues with subdomain-served resources, hence the requirement to include subdomains if you're on the preload list.
      - colanderman 11y ago
        I don't get this. If my pages are served over https, aren't they forbidden from accessing non-https content, HSTS or not?
        toomuchtodo 11y ago
        No, not when it comes to subdomains and domain-level cookies. https://shrikantadhikarla.wordpress.com/2013/02/18/anatomy-of-includesubdomains-directive-in-http-strict-transport-security-policy/ https://shrikantadhikarla.wordpress.com/2013/02/18/anatomy-o...
        colanderman 11y ago
        Sorry, that page makes no sense to me. Beside not addressing my original question at all (which was about accessing non-https content from an https context): 1) I don't understand how an attacker would manage to "register" a sub-domain within a domain I control. AFAIK this would require a DNS MITM. 2) How can the attacker's HTTP server present a TLS certificate? Presumably the author missed a step in there; a redirect? 3) Why is an intermediate HTTP request even necessary in this scenario? If a browser is pointed at the false sub-domain via https and the user clicks through the TLS cert, won't it give up the domain cookie regardless? 4) Given #3, the only benefit I see includeSubdomains providing is that it changes the TLS cert warning into an error. Is this a correct analysis? A much more realistic scenario would be that an attacker MITMs an existing HTTP-only subdomain and upgrades it to HTTPS with a false cert. Or that an attacker MITMs DNS to serve a false HTTPS subdomain. (I think the author conflated these two scenarios.) In these cases I see the safety includeSubdomains would provide, albeit one that DNSSEC would also provide.

deleted 11y ago

[deleted]