In reading about the security enhancement Twitter recently deployed, I saw many experts now recommend not only default HTTPS, but also HTTP Strict Transport Security (HSTS). What's the difference between the two, and how does HSTS further enhance application security?
Ask the Expert
SearchSecurity expert Michael Cobb is ready to answer your security questions -- submit them now! (All questions are anonymous)
Most websites only use Hypertext Transfer Protocol Secure (HTTPS) for pages containing sensitive information, such as login credentials or payment card data, while the rest of the site's content is sent via HTTP. This practice stems from the days when computers were nowhere near as powerful as they are today, and sending a page over HTTPS increased the time it took for it to appear on a user's screen -- something Web designers always try to avoid. However, with the speed of today's network connections and devices, that is generally no longer an issue, and there is a growing trend toward delivering the entire contents of a site via HTTPS as a means of improving security. Google, for example, is making HTTPS the default for its online applications, and PayPal is already an HTTPS-only website.
However, creating an HTTPS-only website can be challenging. Many sites pull content from several different sources, and developers often forget to ensure all of these resources are sent to the client via HTTPS. Oftentimes, developers reference media elements, such as style sheets and scripts located on other servers, which are fetched via HTTP. This creates a situation where although the main page load is protected against active and passive network attacks, other resources and pages may leave the user exposed to attacks such as HTTPS stripping and session hijacking.
To overcome this problem and enforce an HTTPS-only policy, sites can use HTTP Strict Transport Security (HSTS) to notify browsers and other agents accessing the site that they are to interact with it using only secure HTTPS connections. HSTS is an Internet Engineering Task Force (IETF) standards track protocol and is specified in RFC 6797. An HSTS policy is communicated by the server to the user agent via an HTTP response header field named "Strict-Transport-Security", and is currently supported by major browsers, including Firefox, Chrome and Opera, but not Internet Explorer.
Using HSTS mitigates any errors that may arise from partially implemented SSL or content referenced using HTTP by redirecting all HTTP links to HTTPS; in other words, all HTTP URLs are replaced with HTTPS URLs. This also includes subdomain directives to ensure links to resources on different subdomains are also secured.
Performance-wise, HSTS eliminates unnecessary HTTP to HTTPS redirects by shifting the responsibility to the browser, which rewrites all links to HTTPS. Additional protection is provided for the user as the browser will automatically refuse connection with a site if it detects a problem with the HTTPS implementation. Users will receive an error message that they will not be able to override, denying them access the site. This greatly reduces the chances of a user being compromised by attacks using malicious redirects or certificates.
One word of caution: There is a brief window of attack that hackers can take advantage of against sites supporting HSTS. When a browser visits a website for the first time, it doesn't have an HSTS policy saved for it. An attack during this first visit could potentially block the browser from reaching the HTTPS version of the site, forcing it to use an HTTP connection. To address this weakness, browsers, including Chrome and Firefox, have pre-loaded lists of popular websites for which HSTS is enforced by default.
Overall, HSTS definitely improves the security of a website's interaction with its users and, based on Google's experience when moving applications over to HSTS, will only result in a negligible increase in CPU usage. While today only a small number of the top HTTPS-enabled websites support HSTS -- and even though it is not yet a full standard -- webmasters would be wise to look into taking advantage of the extra security it provides sooner rather than later.
This was first published in February 2014