I believe I have found a security problem in the HSTS interpretation of Firefox. Take the following three URLs (this is a live example on a test domain of mine; I intend to keep it functional until this issue is resolved): * https://q2.re/ has an HSTS policy *with* includeSubDomains. * https://sub.q2.re/ has an HSTS policy *without* includeSubDomains. * http://plain.sub.q2.re/has no HTTPS support. If one opens these URLs in that order, it will open the last one over unencrypted HTTP. It appears Firefox interprets the policy on the subdomain without includeSubDomains as a signal to unset HSTS for further sub-subdomains. In my reading of the RFC 6797, this is wrong. The policy on the apex domain - with includeSubDomains - applies to all subdomains. The policy without includeSubDomains on the subdomain only applies to that specific host. It should not have any transitive effects on further subdomains. Notably, this even works for preloaded domains. This severely breaks expectations. When one preloads a domain, it is expected that no unencrypted access is possible. A plausible scenario where this could lead to an attack could look like this: * https://example.com/ has a strict HSTS policy with includeSubDomains and may even be preloaded. * https://example.com/ sets a cookie scoped for .example.com without a secure flag. (This is not unusual - there is advice out there that the secure flag is less important if one uses HSTS. This is e.g. implied by the Mozilla Observatory scoring.) * Attacker looks for any subdomain of example.com with an HSTS policy without includeSubDomains. (This is also not unusual. The expectation may be that includeSubDomains is only important for the apex domain.) I quickly found a live example on a popular page (netflix.com) where all criteria apply (though I do not know if the cookie is security relevant). I have not performed a thorough search for affected pages, I expect this to be very common. Given it is close to the end of the year, I should say that I do not plan any short-term disclosure and do not expect any handling of this issue during Christmas and New Year time.
Bug 1870262 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I believe I have found a security problem in the HSTS interpretation of Firefox. Take the following three URLs (this is a live example on a test domain of mine; I intend to keep it functional until this issue is resolved): * https://q2.re/ has an HSTS policy *with* includeSubDomains. * https://sub.q2.re/ has an HSTS policy *without* includeSubDomains. * http://plain.sub.q2.re/ has no HTTPS support. If one opens these URLs in that order, it will open the last one over unencrypted HTTP. It appears Firefox interprets the policy on the subdomain without includeSubDomains as a signal to unset HSTS for further sub-subdomains. In my reading of the RFC 6797, this is wrong. The policy on the apex domain - with includeSubDomains - applies to all subdomains. The policy without includeSubDomains on the subdomain only applies to that specific host. It should not have any transitive effects on further subdomains. Notably, this even works for preloaded domains. This severely breaks expectations. When one preloads a domain, it is expected that no unencrypted access is possible. A plausible scenario where this could lead to an attack could look like this: * https://example.com/ has a strict HSTS policy with includeSubDomains and may even be preloaded. * https://example.com/ sets a cookie scoped for .example.com without a secure flag. (This is not unusual - there is advice out there that the secure flag is less important if one uses HSTS. This is e.g. implied by the Mozilla Observatory scoring.) * Attacker looks for any subdomain of example.com with an HSTS policy without includeSubDomains. (This is also not unusual. The expectation may be that includeSubDomains is only important for the apex domain.) I quickly found a live example on a popular page (netflix.com) where all criteria apply (though I do not know if the cookie is security relevant). I have not performed a thorough search for affected pages, I expect this to be very common. Given it is close to the end of the year, I should say that I do not plan any short-term disclosure and do not expect any handling of this issue during Christmas and New Year time.