[LINK] HTTPS and HSTS

[stephen at melbpc.org.au]

HTTP Strict Transport Security becomes Internet standard

 http://tools.ietf.org/html/rfc6797

By Lucian Constantin (IDG News Service) 22nd November, 2012


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 adoption 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.

--
Cheers,
Stephen Loosley