Fencing Your SSL Errors With HSTS : ScanToSecure

Posted by David Blake, Thursday, January 10, 2013

Back in the 1990s—that’s ages ago in tech years—developers created the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) to secure Internet communication, adding a layer to the inherently nonsecure HTTP protocol. But some HTTP users remained vulnerable even with SSL. This was disastrously shown when thousands of users downloaded Firesheep to spy on others (and, in some cases, to do much worse). What Firesheep showed is that, when SSL isn’t executed correctly, users get burned. (Good thing it wasn’t Nuclear-fission-sheep.)

As developers, we can make implementation mistakes (using mixed content or a partially applied SSL) that grant attackers access to otherwise secure information. And users, who often have little knowledge about security procedure, frequently ignore valid certificate warnings. But HSTS (HTTP Strict Transport Security) technology can bring you additional protection, forcing the use of secure communication and creating a safety net where any errors in executing your SSL has created a gateway for attack.

The ABC’s of HSTS

HSTS was first proposed in 2008 and named ForceHTTPS. What it does is help you define a policy that (aptly) forces users to connect with the web resource via a secure connection—no exceptions. HSTS can be declared for the entire domain, including any subdomains.

With HSTS, there are primarily two actors: the HTTP host and the user agent, such as a web browser like Firefox or Chrome. When you define the HSTS policy on the host, you ensure that the host sends the policy in a response header field over a secure connection. (Keep in mind that the browser must be capable of reading the HSTS directives.) On receiving this header field, the browser ensures that all communication with the website complies with this policy, which is saved with the browser for a certain time period that you define. The browser then ensures that all the user’s subsequent sessions use a secure connection for that period — even if he or she types http://www.example.com in the web browser.

Now take a look at the diagram below. In this example, the user requests a webpage from an HSTS host over HTTP. Then the HSTS host automatically redirects the user to the secure page, communicating the HSTS policy to the browser after a secure connection is established.

In the real-world example shown below, a user attempts to access Paypal, an HSTS-enabled website, by typing “http://www.paypal.com” in the browser. (For a straightforward way to view HTTP-level traffic, you can use http://web-sniffer.net or, even better, a tool like Fiddler.) The response header indicates that the nonsecure link (highlighted in yellow) is permanently moved to a secure location and that the HSTS host has not yet communicated the HSTS policy.

After the user is redirected to a secure connection, the host sends the HSTS policy to the browser in the response header, as shown below.

But while HSTS is certainly effective, it does not safeguard the user from all types of attacks.

Security Four Ways

When a website doesn’t employ or partially employs SSL, or serves mixed content to the users, you’ve got entry points for attacks. With HSTS, you not only have extra security but also a safety net, protecting your website from attacks caused by errors in applying the SSL. HSTS accomplishes this by doing the following:

• Redirecting All HTTP Links to HTTPS: The “include subdomains” directive ensures that the browser requests all links to the website, including those on different subdomains, as secured. This blanket policy covers problems that arise from a partially implemented SSL and from mixed content that uses HTTP links to your CSS and JavaScript files.
• Terminating Nonsecure Connections: Users often have the tendency to click through and ignore browser warnings. With HSTS, the browser automatically terminates the communication if the user ignores the warnings, therefore reducing the chances of an attack.
• Transforming Nonsecure URI References: In other words, replacing HTTP with HTTPS in any URIs.
• Enabling Restriction to Secure Mode: Website owners and developers can declare that the website is available only in a secure mode.

Who’s Doing It?

(More than you would think.) Some websites have already adopted the HSTS policy, requiring their users to use a secure connection. Take a look at a couple examples.

Twitter

LastPass (A password management service provider)

Getting Up and Running

So we have rules defined on the host and rules defined for browsers by Mozilla, Google, etcetera. The rules you need to define on the host include those for handling page requests over both a secure and nonsecure connection.

If the user requests a page over a secure connection, the host should respond with the HSTS header field. A typical syntax for this is:

Strict-transport-security: max-age=12355000; includesubdomains

When a user requests a page over a nonsecure connection, you should define the rules to redirect the user to a secure version of the same page and then send the HSTS header information once the secure connection is established.

To handle communication over a secure connection, the browser, on receiving the header, updates its information and identifies the host as a Known HSTS Host for all communication thereafter, for the specified max-age value (in seconds). However, if the communication is over a nonsecure channel, the browser ignores the HSTS header.

Browsers That Cooperate

Although you can define and enforce rules to ensure that the user connects to your website over a secure connection, his or her browser must be compatible so that it can read the HSTS header and identify the website and known HSTS host. Version 4 of both Firefox and Google Chrome support HSTS. So does Opera’s version 12 Beta.

SSL Is Not Enough

Whether by the developer’s human error (fairly common) or by simple oversight, whether it’s due to use of mixed content or the user’s ignoring the (often anaesthetizing) browser security warnings, there are many potential security vulnerabilities for would-be attackers to exploit.

Using HSTS covers any areas where your security comes up short and ensures that your users don’t unwittingly endanger their private information, like thousands of Internet denizens have, unfortunately, done so already.

Keep in mind that HSTS doesn’t mean forgetting all about SSL. In our next post we’ll dig a bit deeper into how you should execute SSL in your development environment.