24

Suppose that my site is located at foo.example.com and I send the following HTTP header when visitors accessing my site using HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Would the HSTS policy have any effect on domains such as example.com or bar.example.com?

I'm not in charge of the certificates but the common name is *.example.com on the certificate so I'm not sure if that matters.

The certificate isn't valid for abc.foo.example.com, but I imagine that if there is a valid cert for such a host that the HSTS policy would apply there.

31

Based on the RFC, HTTP Strict Transport Security (HSTS), the includeSubDomains states:

6.1.2. The includeSubDomains Directive

The OPTIONAL "includeSubDomains" directive is a valueless directive which, if present (i.e., it is "asserted"), signals the UA that the HSTS Policy applies to this HSTS Host as well as any subdomains of the host's domain name.

Therefore your HSTS policy would only apply to foo.example.com and *.foo.example.com

example.com and bar.example.com would not be impacted.

For more info, there is a great thread on webmasters titled Do I need a wildcard SSL certificate for inclusion in the HSTS preload list?

1

It depends, section 11.4.2 describes the scenario of web apps interacting with the subdomains but not with the HSTS host (abc.domain.com but not domain.com) and in this case the UAs will not enforce the HSTS policy. The suggestion is:

HSTS Hosts should be configured such that the STS header field is emitted directly at each HSTS Host domain or subdomain name that constitutes a well-known "entry point"

But section 11.4.1 says that all subdomains must implement HTTPS, so as long as they do it should work just fine.

From the spec:

If ca.example.com were to issue an HSTS Policy with the
includeSubDomains directive, then HTTP-based user agents implementing HSTS that have interacted with the ca.example.com web application
would fail to retrieve CRLs and fail to check OCSP for certificates,
because these services are offered over plain HTTP.

In this case, Example CA can either:

  • not use the includeSubDomains directive, or

  • ensure that HTTP-based services offered at subdomains of ca.example.com are also uniformly offered over TLS/SSL, or

  • offer plain HTTP-based services at a different domain name, e.g., crl-and-ocsp.ca.example.NET, or

  • utilize an alternative approach to distributing certificate status information, obviating the need to offer CRL distribution and OCSP services over plain HTTP (e.g., the "Certificate Status Request" TLS extension [RFC6066], often colloquially referred to as "OCSP Stapling").

0

Would the HSTS policy have any effect on domains such as example.com or bar.example.com?

Yes. includeSubDomains affects all subdomains of the domain name. Crucially, the domain name of foo.example.com is example.com so all compliant user agents will apply the HSTS restriction to *.example.com.

6.1.2. The includeSubDomains Directive

The OPTIONAL "includeSubDomains" directive is a valueless directive which, if present (i.e., it is "asserted"), signals the UA that the HSTS Policy applies to this HSTS Host as well as any subdomains of the host's domain name.

(emphasis mine)

The certificate isn't valid for abc.foo.example.com, but I imagine that if there is a valid cert for such a host that the HSTS policy would apply there.

That's correct. Certificate validity is orthogonal to whether a host name is subject to a Strict Transport Security restriction.

  • 1
    Wouldn't this be an easy way to DoS any subdomain that is not served over HTTPS? If I controlled the code for foo.example.com which uses HTTPS then I can send an HSTS header to prevent access to an HTTP site, ex: bar.example.com? – rink.attendant.6 Jul 24 '18 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.