0

I have a haproxy-ssl-terminated (haproxy 1.5.8 2014/10/31, debian jessie stock) test website, where the certificate expired. I'd like to be able to use the site while the new certificate arrives, but chrome and firefox tell me I have HSTS enabled. I looked up what I would have needed to enable HSTS in haproxy, but it seems to me, that I have none of the relevant lines in my haproxy.conf. Also, I do not see any trace of the relevant Strict-Transport-Security header, neither when using chrome/firefox inspector nor using curl.

The headers I get when using curl --insecure -i https://.... are: 

Date: Mon, 02 Jul 2018 07:27:31 GMT
Server: Apache
Last-Modified: Fri, 29 Jun 2018 08:54:36 GMT
Vary: Accept-Encoding
Content-Type: text/html
X-Varnish: 296609
Age: 0
Via: 1.1 varnish-v4
ETag: W/"962f-56fc3ff5ab00b-gzip"
Transfer-Encoding: chunked
Connection: close
Accept-Ranges: bytes
Set-Cookie: ServerID=A; path=/
Cache-control: private

How can I disable HSTS temporarily? How can I detect whet causes HSTS to be enable in the first place?

P.Péter
  • 569
  • 2
  • 6
  • 24
  • *"chrome and firefox tell me I have HSTS enabled."* Please do not paraphrase or summarize error messages. Quote them exactly. – Michael - sqlbot Jul 02 '18 at 12:48
  • Sorry, I cannot reproduce the error any more, as I managed to reset my browser in the `chrome://net-internals/#hsts`, _and_ managed to get new certificates. :( – P.Péter Jul 02 '18 at 15:02

1 Answers1

2

As we can see from your curl output, there's currently no Strict-Transport-Security header. In HAProxy, there would have been http-response set-header Strict-Transport-Security ... in the configuration.

It has been there before, possibly on times before you had the HAProxy in front of the web server. That's before HSTS is by design cached by the browser for max-age= seconds. If you had there there e.g. max-age=31536000, it was cached for a year counting from last presence of the header.

RFC 6797 6.1.1. The max-age Directive

The REQUIRED max-age directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host (from whom the message was received) as a Known HSTS Host.

You can't disable HSTS temporarily from server side by removing the header. You need to renew your certificates earlier so that the new certificate will arrive before the old expires. Even better: automate your renewing process, like the Certbot does for Let’s Encrypt certificates.

Community
  • 1
Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • I am quite sure there was no such header in the haproxy configuration anywhere in the past. But let's suppose there was. Is there a way to erase it from the browser's memory? – P.Péter Jul 02 '18 at 10:09
  • Not possible. It's designed to prevent some bad guy doing the same. – Esa Jokinen Jul 02 '18 at 10:14
  • 1
    The user can remove HSTS from their browser if they choose. There's a section in `chrome://net-internals/#hsts` in Chrome where you can purge all the remembered security settings for a site. That will also clear HSTS. But obviously this requires manual intervention by the user. – Mark Henderson Jul 02 '18 at 11:48
  • @MarkHenderson: Possible, but not very wise in this situation. a) For the user it's much easier to bypass the warning by clicking "Proceed to example.com (unsafe)". b) It's still way more secure than not using TLS at all, as suggested. If I'd have to inform customers anyway, I'd definitely choose to give this advice, instead. – Esa Jokinen Jul 02 '18 at 11:59
  • 2
    You cannot bypass HSTS by clicking through. Once you have a HSTS header set in your browser, the browser will refuse to visit the site if there is an invalid certificate. – Mark Henderson Jul 02 '18 at 12:03
  • My mistake. Luckily, I've never been there in the age of HSTS as I've got my certificate renewing processes in a good order, reminding me in advance. So, replacing the certificate with a temporary free Let’s Encrypt certificate while waiting might be the only practical solution to this. – Esa Jokinen Jul 02 '18 at 12:17