TLS False Start is dead

So for about a year and half, Chrome has been speeding up TLS / SSL connections by a mechanism called “TLS False Start.”  The performance improvements were impressive; False Start dropped connection times by 30% or just under 200 ms.  The details of TLS False start are described in this tech memo, but the basics are that the client starts sending application data immediately after the Change Cipher Spec and Finished messages, without waiting from the server.  This essentially removes one round trip across the network.  Actually, it’s quite clever since once the client has sent the Change Cipher Spec message, it has shifted over to the bulk encryption algorithm and finished the key exchange and doesn’t necessarily need to wait for the server to confirm.

However, the reasons for its demise are a bit comical and unfortunately False Start’s tragedy has much to do with a good protocol and restrictive implementations.   My favorite problem was that a major vendor of SSL Terminators (servers acting as the SSL / TLS endpoint, probably with hardware acceleration) has some sort of minor bug preventing the use of TLS False start.  The vendor refused to fix it.

One, fairly major, SSL terminator vendor refused to update to fix their False Start intolerance despite problems that their customers were having. I don’t believe that this was done in bad faith, but rather a case of something much more mundane along the lines of “the SSL guy left and nobody touches that code any more”. However, it did mean that there was no good answer for their customers who were experiencing problems.

I can see how this can happen and why the company wouldn’t want to fix it.  By the way, I’ll be returning to work in August… (no I don’t work for this vendor). 🙂

One of the frustrating aspect of protocol design is that there is a duality consisting of what the protocol says and the populous implementation.  Actually, its more of an oligarchy, where the most popular implementation sets the standard.

Well, you can still install HTTPS Everywhere in Chrome so that’s a good thing.  I highly recommend it.  Not only is supported by the EFF, a great organization, it’ll always attempt to use the https version of a website, making your web traffic more secure.

HTTPS Everywhere from the EFF

[UPDATE] For those with a Wireshark inclination, here are two captures of TLS False Start in action.

TLS False start in action on the client and server
False start on the client side only (chrome)
Advertisements

6 thoughts on “TLS False Start is dead

    1. Well… fortunately (for me) I’ve swapped most of my knowledge of the neutron life cycle for said topics above. However, at my current position, people kind of expect that I remember that stuff. In such cases, I quickly turn them over to the SQEng…

  1. I enjoyed your post Josh. And I also understood it! So your words have not been in vain. It’s pretty silly the Terminators are not supporting it so it’s essentially going away. 30% is a big increase in performance. I always remembered thinking the handshake took way too long.

    1. Thanks. It’s a great marketing statement for Google. With TLS False Start, google is faster in chrome than in other browsers (when using TLS). I haven’t read any detailed comments on an potential security implications though. My one concern is that the client could be sending application data before server has had one last chance to verify everything is good to go. Confidentiality wise, the data is wrapped in the agreed cipher specs, but I’m not sure about the case where the server rejects one of the client’s final messages (BAD_RECORD_MAC anyone?) but now has some application data.

  2. TLS False Start isn’t dead, it just won’t be supported on non-NPN-supporting servers. Which currently might not be as many, but OpenSSL 1.0 supports it so it will be in all the Linux distributions and so on soon enough. And it can still be used with SPDY as SPDY depends on NPN.

    1. Well, that’s good to hear. It’s a pretty significant boost to performance. I’ve been using the HTTPS Everywhere plugin and I notice the performance hit.

      Thanks for the correction.

Comments are closed.