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.
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.
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.
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.
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.
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.
Yeah, I think if the attacker getting a valid certificate for subdomain.victim.com is a serious possibility, you've already lost long ago. If an attacker
If you're worried about the attacker getting DNS (e.g. by spoofing DNS) and running a webserver at subdomain.victim.com, the user has to click through a certificate warning. I can see why the HSTS preload list would want to worry about making it hard for user error to compromise security, but I don't think it's a very sensible part of a threat model for HSTS as a whole..
(For those cases where you explicitly permit people to register websites at a subdomain of their choosing, e.g. stuff like username.github.io, you need to register github.io in the Public Suffix List. This prohibits github.io from having any cookies set on it.)
14 comments
[ 2.3 ms ] story [ 44.6 ms ] threadhttps://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.
I think soon it will seem weird for a TLS-enabled site to not use HSTS.
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.
https://shrikantadhikarla.wordpress.com/2013/02/18/anatomy-o...
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.
If you're worried about the attacker getting DNS (e.g. by spoofing DNS) and running a webserver at subdomain.victim.com, the user has to click through a certificate warning. I can see why the HSTS preload list would want to worry about making it hard for user error to compromise security, but I don't think it's a very sensible part of a threat model for HSTS as a whole..
(For those cases where you explicitly permit people to register websites at a subdomain of their choosing, e.g. stuff like username.github.io, you need to register github.io in the Public Suffix List. This prohibits github.io from having any cookies set on it.)
Internal: subdomains.bigco.<whatever TLD you want>
Don't use HSTS if you're unable to TLS enable everything (which you should be doing, regardless)
This is how we use HSTS within our environment.