Removing STS once implemented

The default is “empty” resulting is no HSTS header.

Empty (literally delete everything from the “HSTS Time to live (seconds)” text box) results in no header being sent.

Zero seconds means remove HSTS from any browsers that visit the site.

This is needed if you have previously used HSTS with a long time to live like 3 months, but decide you need to send some of the browsers to an HTTP version of the site. Simply removing the STS header would mean you need to wait 3 months before using HTTP, serving zero seconds over a properly secured connection, instructs the browser to remove the HSTS flag for your domain entirely so that browser can now use HTTP straight away.

Of course for 3 months you need to serve the HTTPS version to remove the STS flag before directing them to the HTTP version.

I’m of the view that HTTP without encryption is a legacy protocol, I can’t imagine a good reason to remove HTTPS & HSTS, especially now it is relatively easy to get free x509 certificates automatically.

Thank you for the clarity, Simon. I have subdomain URLs (CNAME entries) that aren’t yet served via HTTPS. HSTS resulted in ‘refused connections’. Until all my solutions transition to HTTPS, I’m placing HSTS implementation on hold.

If there is an alternative path, I’d love to hear about it.

• This reply was modified 7 years, 10 months ago by dajuan.

You can deploy HSTS without “includeSubdomains”, but you lose the benefits of it protecting your cookies as effectively, which in practice is probably one of the biggest benefit, as all cookie forcing attacks are off the cards, and they are legion.

It also stops SSL-Stripping, and prevents click-through on certificate errors. So it may be worth deploying STS without including subdomains, since it reduces the vigilance expected of users.

Take a look at the cookies sent to these subdomains by your browser, as the content there may determine how keen you are to migrate them to HTTPS.