Even the average Joe is starting to understand that encryption is important. If Joe doesn’t use HTTPS, an attacker can see or hijack his browser session. Session hijacking isn’t a theoretical threat: Over 5 years ago (an eternity in the #infosec world), Eric Butler released the Firesheep session hijacking tool and used Facebook as a target example. Sitting in a coffee shop, an attacker could use Firesheep to steal Joe’s Facebook session cookie and then “own” Joe’s account. Butler’s Firesheep website makes it clear: “On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.”
Network administrators and architects certainly got the hint. Facebook went all-HTTPS shortly after. So did Twitter. Netflix is even talking about going all-HTTPS. Yay for encryption! Instagram made the mistake of initially encrypting only their login page. When talk of an “Instasheep” tool surfaced they, too, switched to all-HTTPS.
That’s why it’s so puzzling that adoption rate of HTTP Strict Transport Security (HSTS) remains so low at only 4.7 percent. HSTS plugs one of the security holes left behind when a site accepts both unencrypted (HTTP) and encrypted (HTTPS) requests.
What happens when Joe forgets to use HTTPS and visits a site that offers both? An attacker sitting between Joe and his target site could intercept his session and ensure that his browser never received any HTTPS redirects. Joe would continue his unencrypted browsing over HTTP and the attacker would hijack his session.
HSTS closes this security hole with one of the easiest, most elegant little fixes in recent memory: a simple HTTP header in the server response. When a site implements HSTS, the first time the user visits the site it will send back a header that looks like this:
HTTP/1.1 302 Found
Content-Length: 667
Location: https://www.example.com
Server: Microsoft IIS/7.1
Strict-Transport-Security: max-age=31536000; includeSubdomains
X-Frame-Options: SAMEORIGIN
The HSTS RFC requires that browsers interpret the Strict Transport Security header to mean that from now until “max-age” (usually 6 months or greater in the future) the browser should only use encryption (SSL) when connecting to the site.
This means that as long as Joe has visited the site at least once before and received the HSTS header, he can just type the site name in his browser address bar and the browser will automatically use SSL to protect the session.
Super cool and easy-peasy.
But if it’s so easy, why isn’t HSTS being used?
According to Ivan Ristic’s SSL Pulse database, HSTS adoption has been stuck at less than 5 percent since its inception over three years ago. There may be a few legitimate reasons not to use HSTS but honestly, one would be hard pressed to think of many. Certainly there aren’t enough reasons such that 95 percent of the Internet isn’t using this easy fix.
Perhaps it is an awareness issue. Now that average Joe is starting to get the message about encryption, and IT administrators have transitioned their sessions to HTTPS, maybe the next step is education. The Open Web Application Security Project (OWASP) has promoted insecure session management to number two in their OWASP Top Ten project. That’s a good start.
There is some good news in the statistics. A quick check of the busiest sites in the world shows that six of the top sites have adopted it. This is way up from a year ago, when it was less than half that.
Perhaps the uptick in the adoption of HSTS among the world’s busiest sites foreshadows a broader adoption of this handy security technique.
Administrators can read more about HSTS at the OWASP HSTS page, and can learn how to test their site for STS usage at the OWASP HSTS Test page
