Mutations in the TLS Protocol: HSTS, False Start, Snap Start

The release of the FireSheep add-on last year demonstrated the fundamental weakness of unsecured wireless networks. The traditional technique of securing only the authentication phase of a web session cannot work in such an environment, since other members of the network can simply grab your cookie and pretend to be you.

Partially in reaction to FireSheep, many providers have decided to secure the entire session with TLS. This evolution to “All-TLS-all-the-Time” places a greater importance on TLS-terminating devices (such as your friendly ADC, BIG-IP) and on the protocol itself. TLS is our last line of defense out there on the wild, wooly internet.

Enter HSTS – HTTP Strict Transport Security

One point of vulnerability in a session is still the transition from HTTP to HTTPS. For example, if you type in www.yourbank.com to your IE8 browser, it attempts to contact your bank’s server using HTTP. The server (or often BIG-IP) responds with a redirect prefixed with https:// and your browser reconnects using TLS and your session is secure.

But what if the redirect, which is not secure, was tampered with? And instead of your HTTP request going to your bank, it gets intercepted and delivered to a malicious server. The malicious server sends back a page that looks like your bank. You type in your password reflexively and oops, you are owned.

It is to counter this problem of the initial transition that a HTTP Strict Transport Security (HSTS) was proposed and is quickly being adopted by the various browsers and early-adopters like PayPal. HSTS instructs the client browser to follow two rules:

1. Automatically convert any HTTP links for that site into HTTPS links
2. If there’s a problem with the site certificate (for example it’s self-signed), then do not allow a connection to the site.

Jason Rahm wrote an excellent Tech Tip on implementing HSTS via an iRule on BIG-IP.

Implementing HTTP Strict Transport Security in iRules

Reading his post is highly encouraged, but here’s the juicy iRule itself.  Note the two HSTS components – the initial redirect (the 301 “Moved Permanently”) and the header insert for “Strict-Transport-Security”.

   ### iRule for HSTS HTTP Virtuals ###
   when HTTP_REQUEST {
       HTTP::respond 301 Location "https://[HTTP::host][HTTP::uri]"
   }

   ### iRule for HSTS HTTPS Virtuals ###
   when RULE_INIT {
      set static::expires [clock scan 20110926]
   }

   when HTTP_RESPONSE {
      HTTP::header insert Strict-Transport-Security "max-age=[expr {$static::expires - [clock seconds]}]; \
               includeSubDomains"
   }

False Start

Google has proposed an interesting mutation in TLS called False Start.  During the handshake phase of TLS a certain number of “setup” packets are sent between the client and the server.  The False Start modification allows the client or server to piggyback the initial application data on the last setup packets to reduce the number of round-trips by one.

Specifically, the client and server exchange three things during the setup: a session key, their certificates and the cipher specification (which encryption type they are going to use).  After they have exchanged those items, they compute a hash of the messages they just exchanged, sign them and exchange those.  The signed hashes (called the Finished messages) should be the same.  If they are not, then someone has tampered with the conversation and the session should be aborted.

False Start suggests that either side could start sending their application data (for example “GET / HTTP/1.0\r\n\r\n”) BEFORE receiving the other side’s Finished message.  It should not act on the data until it the handshake is complete.  When done properly and with no attack in place, everything works out and the data was exchanged with one less flight of data.

The main theoretical attack vector opened up by sending the application data before processing the Finished message is a possible down-grading of the chosen cipher suite.  That is, a man-in-the-middle could try to convince the sending side to send that initial data using an old, broken cipher like RC2.  The False Start proposal mitigates that by insisting that you use ONLY the more secure ciphers such as AES128 or AES256 when processing False Start transactions.

So for you BIG-IP users, be sure that you set your clientssl profile strings correctly on HIGH.

 

Snap Start

Google has also authored a proposal for something called “snap-start” which would RADICALLY speed-up TLS handshakes (specifically for HTTPS) by combining the data and the handshake messages immediately.  Its a very bold proposal and in theory, it would work (at least for RSA and HTTPS; it is not applicable to ephemeral asymmetric keys or protocols where the server speaks first).  Unlike False Start, Snap Start is a radical departure from TLS and is more like a protocol rewrite.

Mutations?

Why am I calling these Mutations? They are not necessarily solutions to weaknesses in TLS itself. They are almost tangential to the security of the protocol. Clearly, HSTS can only tighten web security. It’s not so clear with False Start and Snap Start: they provide performance increases with no additional security measures.  It appears that the authors have done their homework and peer review; even running their changes by Eric Rescorla, who reminded them of the importance of the Finished message and its prevention of cipher downgrades).  But False Start feels like the blending of TLS and non-TLS data that caused the whole renegotiation ruckus last year.  It's in that class of problem.  Just sayin’.

Whatever baggage that the word mutation carries around with it, its important to remember that, everywhere outside of Kansas, mutation is how evolution works.