4 ms·

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.
- geofft 11y ago
  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.)

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.
geofft 11y ago
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.)