HTTP Strict Transport Security becomes Internet standard

A Web security policy mechanism that promises to make HTTPS-enabled websites more resilient to various types of attacks has been approved and released as an Internet standard -- but despite support from some high-profile websites, adoption elsewhere is still low.

HTTP Strict Transport Security (HSTS) allows websites to declare themselves accessible only over HTTPS (HTTP Secure) and was designed to prevent hackers from forcing user connections over HTTP or abusing mistakes in HTTPS implementations to compromise content integrity.

The Internet Engineering Task Force (IETF), the body responsible for developing and promoting Internet standards, published the HSTS specification as an official standards document, RFC 6797, on Monday. IETF's Web Security Working Group had been working on it since 2010, when it was first submitted as a draft by Jeff Hodges from PayPal, Collin Jackson from Carnegie Mellon University and Adam Barth from Google.

HSTS prevents so-called mixed content issues from affecting the security and integrity of HTTPS websites. Mixed content situations occur when scripts or other resources embedded into an HTTPS-enabled website are loaded from a third-party location over an insecure connection. This can be the result of a development error or it can be intentional.

When the browser loads the insecure resource it makes a request over plain HTTP and can also send the user's session cookie along with it. An attacker that can intercept the request using networking sniffing techniques can use the cookie to hijack the user's account.

The HSTS mechanism also prevents man-in-the-middle attacks, where the attacker is in a position to intercept a user's connection with a website and force his browser to access the site's HTTP version instead of HTTPS. This technique is known as HTTPS or SSL stripping, and there are tools available to automate it.

When the browser connects over HTTPS to a website that supports HSTS, the site's strict transport security policy is saved and remembered for a specified amount of time. From that point forward, as long as the cached policy doesn't expire, the browser will refuse to initiate insecure connections with that website.

The HSTS policy is transmitted through an HTTP response header field called Strict-Transport-Security. The same header can be used to update and renew the policy.

HSTS is one of the best things to have happened to SSL because it fixes some of the mistakes made when originally designing the protocol 18 years ago, Ivan Ristic, director of engineering at security firm Qualys, said on Thursday. It also addresses the changes that have occurred since then in how Web browsers operate today, he said.

For example, relying on certificate warnings was a big mistake because users developed a habit of ignoring and overriding them, Ristic said. In the majority of situations that's not a big issue, but in 1 percent of cases it can be dangerous, he said.

HSTS does not rely on certificate warnings. If a problem is detected with the HTTPS implementation, the browser will simply refuse the connection and won't offer users the opportunity to override the decision, Ristic said.

Even with HSTS enabled on a website, there is still a small opportunity for attacks when the browser visits the website for the first time and doesn't have an HSTS policy saved for it . At that point an attacker could block it from reaching the HTTPS version of the site and could force the connection to use HTTP.

In order to address this, browsers such as Chrome and Firefox come with pre-loaded lists of popular websites for which HSTS is enforced by default.

According to SSL Pulse, a project that monitors HTTPS implementations on the world's most visited websites, only around 1,700 out of the top 180,000 HTTPS-enabled websites support HSTS.

In addition to the overall HSTS adoption rate being low, some of the websites that do support the feature have implementation issues, Ristic said.

For example, some of them specify a very short validity period -- also known as the time to live -- for their HSTS policies. For HSTS to be useful these records should be valid for days, if not months, he said.

Ristic doesn't believe that HSTS becoming an official standard will necessarily drive adoption numbers up. Website operators have traditionally been opportunistic and have implemented whatever worked for them, regardless of whether it was a standard or not, he said.

"I think the biggest problem with HSTS is education," Ristic said. "People need to learn that it exists."

Popular websites that support HSTS at the moment include PayPal, Twitter and various Google services. Facebook is in the process of deploying always-on HTTPS across its website, but doesn't support HSTS yet.