Are HTTP request headers protectable prior to a redirect to HTTPS?

Question

I am trying to operate an HTTPS site while accounting for the probability that some requests will initially attempt a non-secure connection over plain HTTP. I can successfully redirect http:// to https:// , but this approach appears to expose the casual user to an unacceptable vulnerability: because the URI and host address must be transmitted prior to the server knowing whether/where to (re)direct the request, an eavesdropper can view the initial HTTP request/response headers. The user can be duped by an eavesdropper who, for instance, reads the http:// request header and serves a page that looks similar enough to the page the user expects to see.

Can a server take an intermediate action, like moving a HTTP connection over to HTTPS prior to the client sending a request header, so that the transmission of the request/response headers is as protected as the transmission of the content itself? Is it impossible to protect the headers transmission between client and server if the connection is originally non-secure?

Answer 1

You should look at HTTP Strict Transport Security ( HSTS ). This will allow your site to indicate to modern browsers that it should only be loaded over HTTPS.

This will still leave your users vulnerable to man-in-the-middle attacks the very first time they visit your site ( TOFU ). You can only mitigate this by getting your site on the preloaded HSTS list .

Answer 2

Yes this is a risk and this is a vulnerability that HTTP Strict Transport Protocol (HSTS) was created to solve.

The idea is that once you connect to the HTTPS site, the server sends back a HTTP Header like the following:

Strict-Transport-Security "max-age=2592000;"

This tells the browser: "for the next 30 days (60 * 60 * 24 * 30 = 2592000) do NOT connect via HTTP but instead upgrade any HTTP request to HTTPS automatically before you send the request." In Chrome you see a 307 internet redirect in developer tools.

Why 30 days? Well it has to be cachable for browsers to be useful and you can decide how long for. Some people recommend 1 or even 2 years (31536000 or 63072000 seconds respectively).

You can also specify a includeSubDomains header so subdomains are automatically protected too (though they should obviously return the header too in case someone visits the subdomain directly):

Strict-Transport-Security "max-age=2592000; includeSubDomains"

This is necessary for better protection for cookies as a fake subdomain could get or set cookies for the parent domain and hijack a session. However this has dangers if a subdomain is not on HTTPS - which might not always be apparent. Eg If you use your main domain name internally and have a site at http://intranet.example.com then it might stop working until you upgrade it to HTTPS or change the policy and wait for the previous max-age time to expire.

This still leaves a risk as the first connection needs to be made to get this header to add this policy to your browser cache. It's a trust on first use (TOFU) policy. Similarly if visiting a long time after getting the policy you're in the same situation. For this reason you can submit your site to a preload list so the browser has your site hardcoded into it so it always assumes HSTS is set. Use this site to do that: https://hstspreload.appspot.com . This sounds great but is not without risks. Once you submit your site to this list it's pretty much impossible to remove it so it's basically a permanent commitment to HTTPS. Maybe no bad thing but you also need to have a long expiry, includeSubDomains setting and also add the preload setting:

Strict-Transport-Security "max-age=2592000; includeSubDomains; preload"

Personally I think this is overkill and potentially quite dangerous due to the fact it's out of your control and not easy to reverse. IMHO only high profile sites (online banking, ecommerce sites, Google, Facebook, Twitter... Etc.) should bother with preloading but that's your own choice.

More info on my blog posts: https://www.tunetheweb.com/security/http-security-headers/hsts/ https://www.tunetheweb.com/blog/dangerous-web-security-features/