
HSTS Preload List: State of the Union 2016 - pred_
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/4gVLcw99NU4
======
tshtf
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
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.

------
david_shaw
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
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
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
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
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
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
No, not when it comes to subdomains and domain-level cookies.

[https://shrikantadhikarla.wordpress.com/2013/02/18/anatomy-o...](https://shrikantadhikarla.wordpress.com/2013/02/18/anatomy-
of-includesubdomains-directive-in-http-strict-transport-security-policy/)

~~~
colanderman
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.

