Google recently announced false start in Chrome browsers which increased TLS performance by 30% http://news.softpedia.com/news/Google-Chrome-s-SSL-False-Start-201253.shtml

I know TLS has been poked and studied by many people for years but you can still get the implementation wrong. Is anyone aware of research into any security weaknesses or possible vulnerabilities with how Google is achieving this performance gain (even if no exploit code written yet)? I am suspicious of a free lunch when it comes to security and crypto in particular.


The gist of "TLS false start" is that, at the end of a normal TLS handshake, each party sends a Finished message to the peer, and should wait from the Finished from that peer before sending application data. "False start" removes that "should wait". Each party may then send application data right away. This implies a lower latency if the party which sends the Finished first is also the one who would send applicative data first.

Note that there are two kinds of TLS handshakes, the "full" and the "abbreviated" handshakes. The latter is used to "resume" a TLS session, namely to recompute a new session key over an already exchanged master key; the abbreviated handshake uses only symmetric cryptography and requires less network exchanges. A point which is worth noting is that in a full handshake, the client sends its Finished message first, whereas in an abbreviated handshake, the server sends its Finished message first.

In the context of HTTPS and Web sites, the client (a web browser) normally initiates a single full TLS handshake. Then the client may also open a few other parallel connections, this time using abbreviated handshakes. Each connection will be used to send several HTTP requests. If a connection timeouts, the browser will open a new one using yet again an abbreviated handshake. Since HTTPS is HTTP-within-TLS and HTTP begins by a request from the client, the "false start" optimization yields any improvement only for the very first HTTP request within the very first TLS connection to the server. This is not really a free lunch, rather a free appetizer, at most.

Cryptographically speaking, what happens with false start is that the client accepts to send its data (the HTTP request) before having confirmation that it really talked to the true server: at that point, from the client point of view, the server is implicitly authenticated. The applicative data is encrypted with a session key derived from a key exchange which used the authenticated server public key (the one from the server certificate) so there is no real risk that an impersonating attacker could gain information that way, at least as long as the key exchange algorithm and symmetric encryption algorithm are secure. However, the client does not have any proof, when it sends its request, that the intended server is really aware of the connection attempt. This is harmless in the context of HTTPS. It would be bold to assume that there is no harm in it generically.

  • @Thomas-pornin great answer and not so technical that even I could follow along! So is this correct: the client has verified the server cert (or have thrown an warning), the session key is agreed and the client starts to send data before the servers sends the "Finished" ? Because the server cert has been verified there is no risk here of a man in the middle or other attack e.g. DNS hijack when client sends finished? – Rakkhi May 23 '11 at 14:00
  • 1
    @Rakkhi: yes, that's it. Cryptographically, the data sent by the client is safe. By using false start, the client just accepts sending its request before being sure that the server is really there; but it makes no difference since the client will wait for the HTTP response, at which point the client has confirmation that the true server is talking. – Thomas Pornin May 23 '11 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.