7

We have a website www.example.com with a certificate for domain www.example.com, we also have HSTS enabled. The Qualys SSL Labs (https://www.ssllabs.com/index.html) confirmed that HSTS has been enabled.

I noticed that if you go to https://test.example.com (which is served by the same Web Server), you encounter a certificate error, which is to be expected, as there is no certificate for test.example.com loaded on the Web Server. However, I have noticed that you can click through the certificate errors, and the web content is then served.

To me this is unexpected behavior. I thought that one of the central ideas behind HSTS is that you cannot click through certificate errors. From Wikipedia: "If the security of the connection cannot be ensured (e.g. the server's TLS certificate is not trusted), show an error message and do not allow the user to access the web application".

This happened with both Firefox 59.0.2 (32-bit) and Chrome (65.0.3325.146 (64-bit)).

My question: Why would a browser allow a user to click through certificate errors on a website where HSTS is enabled?

  • 3
    Does https://test.example.com/ send a HSTS header? – Arminius Apr 17 '18 at 18:16
  • @Arminius: It sure does. From the Developer Tools: strict-transport-security: max-age=31536000; includeSubDomains – Jakkals Apr 17 '18 at 18:28
15

Your browser doesn't apply the HSTS policy of test.example.com because it hasn't seen the header before over error-free secure transport. Therefore, it still allows you to "add an exception".

The user agent processing model [...] stipulates that a host is initially noted as a Known HSTS Host, or that updates are made to a Known HSTS Host's cached information, only if the UA receives the STS header field over a secure transport connection having no underlying secure transport errors or warnings.

(From RFC 6796, emphasis my own)

Seeing the header over plain HTTP or with certificate warnings doesn't count:

The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.

(From MDN)

Also, note that your includeSubDomains directive from www.example.com doesn't apply since test.example.com isn't a direct subdomain (doesn't match *.www.example.com).

  • 1
    however, as he said in another comment, he's adding the subdomains. strict-transport-security: max-age=31536000; includeSubDomains so your assumption is not valid – yzT Apr 17 '18 at 18:39
  • 5
    @yzT test.example.com is not a subdomain of www.example.com. – Arminius Apr 17 '18 at 18:40
  • yeah sorry, I missed that part. I read just example.com :P – yzT Apr 17 '18 at 18:41
  • @Arminius: So the implication of what you are saying is that "https with certificate errors" is the same as http (at least as far as HSTS is concerned). Makes sense, thanks for the feedback, I have some food for thought regarding the ramifications of this. – Jakkals Apr 17 '18 at 18:47
  • 4
    @Jakkals Curiously, the RFC has a section Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport which you may find helpful. – Arminius Apr 17 '18 at 19:27

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.