Overview
For good reasons, regulations and privacy good practices require the usage of an encryption layer between end-user browsers and web servers the user is performing a transaction with (e.g. online shop purchase, online banking transaction). This encryption layer is commonly recognized by the ‘https://’ prefix of a URL, along with the lock symbol in the address bar of the browser. It represents an implementation of X.509 based SSL/TLS encryption, which is an extension to the HTTP protocol the world wide web is based on. Basically all end-systems and servers are technically capable of understanding this protocol.
While the encrypted communication channel is considered secure, the plain text variant (http://) is not: an attacker in the same network or in a transit network could snoop the credentials (or other content) of the web traffic, inject malicious code, or redirect the victim to other places.
Some web sites are not available on the unencrypted HTTP port (the user or the browser have to add https:// in front of the URL), others redirect from the unencrypted to the encrypted scheme (from http:// to https://).
The later case contains a weakness. If an attacker is in the same network as the victim who tries to access an HTTPS website, but entering the HTTP URL and relying on the redirect, the attacker would be able to modify the communication between the two end-points. He is technically able to redirect the victim to a malicious/fraudulent web site. Technically, this would be achieved with a combination of a man-in-the-middle attack (possible for instance if attacker and victim are in the same network) and a downgrade attack (from HTTPS to HTTP).
One possible solution
This weakness can be addressed with almost no effort. If the administrators of a server set the HSTS (HTTP Strict Transport Security) response header correctly, the following happens:
- On first request of the HTTPS enabled website, the server sends out a header to the browser telling that all subsequent connections to the defined domains (and subdomains if applicable - this is often forgotten) must be handled in a secure way via HTTPS. After this trust-on-first-use (TOFU) connection, the browser will turn all insecure URLs into secure URLs before doing a connection attempt.
- If the secure server is not reachable, the connection must be terminated by the browser.
Who should implement HSTS?
It should be in the interest of every server admin or organization who maintains an HTTPS enabled server to raise the bar against attacks to a maximum. In contrast to other technologies like certificate pinning, defining and enabling HSTS header has minimum operational impact, but large positive influence on user security.
Example
The following example enforces HTTPS on this domain and their subdomains for one year. Accessing websites in HTTP on these domains with this browser will be blocked.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Common implementation mistakes
- HSTS header is only set on a specific subdomain. Attackers would be able to redirect traffic earlier. HSTS header should be set on all domains and subdomains.
Supported Browsers
- Chromium and Google Chrome since version 4.0.211.0
- Firefox since version 4
- Opera since version 12
- Safari as of OS X Mavericks
- Internet Explorer 11 on Windows 8.1 and Windows 7 when KB 3058515 is installed (Released on Windows Update in June 2015)
- Microsoft Edge and Internet Explorer 11 on Windows 10
- BlackBerry 10 Browser and WebView (since BlackBerry OS 10.3.3)
List of supported browsers collected from Wikipedia. Additional details regarding browser support is described on caniuse website.
Drawbacks
Currently, we cannot identify any real drawbacks for usage of HSTS. The web server would transfer a marginal amount of bytes more if enabled. If a user uses a non-supported browser, the additional headers will just not be evaluated and discarded. While there is no security gain in this scenario, the situtation with enabled HSTS headers is not making it worse.
References
Classification of this document
TLP:WHITE information may be distributed without restriction, subject to copyright controls.
Revision
- Version 1.0 - TLP:WHITE - First version - 19 Mar 2019