The IETF has received a proposal to modify the Transport Layer Security (TLS) from Google. The company believes that an abbreviated handshake in a client-server connection could speed up Internet connections.

Google claims that, with relatively little effort, the encrypted connection to some websites could be accelerated by about 150 ms. The company estimates that about 5% of all websites would need modifications to support the technique. Otherwise they cannot be reached anymore.

The draft proposes that some application data can be sent to the client before the full handshake between the server and client, four communication steps in total, has taken place. Typically, there is a 2-step “hello” handshake (initiated and accepted), as well as a 2-step certificate verification process, which are required to be completed before actually requested content is sent to the user (or server).

Google says that data could be sent before all four steps are finalized, if certain conditions are met.  According to Google, a client may send data earlier if

-          The application layer has requested the TLS False Start option.

-          The symmetric cipher defined by the cipher suite negotiated in this handshake has been whitelisted for use with False Start according to the Security Considerations in Section 6.1.

-          The key exchange method defined by the cipher suite negotiated in this handshake, has been whitelisted for use with False Start according to [defined] Security Considerations.

A server may send data earlier if:

-          The application layer has requested the TLS False Start option.

-          The symmetric cipher defined by the cipher suite of the session being resumed has been whitelisted for use with False Start according to [defined] Security Considerations.

Securtity is, of course  concern, but Google believes that it has taken care of those:

“The security goal is to ensure that if anyone at all can decrypt the application data sent in a False Start, this must be the legitimate peer: while an attacker could be influencing the handshake (restricting cipher suite selection, modifying key exchange messages, etc.), the attacker should not be able to benefit from this.  The TLS protocol already relies on such a security property for authentication — with False Start, the same is needed for encryption.” Google suggests to not support a symmetric cipher in False Start as well as whitelists for the key exchange and client certificate type to meet security requirements.

Chrome already supports False Start by default.Users who want to disable the feature have to start Chrome with the switch -disable-ssl-false-start (which works in both SSL and TLS connections.)

We are not convinced that the impact of the integration of False Start will be measurable in user perception. We recently began testing web browsers not just through publicly available benchmarks, but also with our custom-built CT Mark, which measures the pure offline page loading performance of web browsers. The table below shows that the performance varies quite a bit across different browsers, and some popular web pages can take more than 4000 ms to load. A 150 ms improvement may not matter in such cases. However, in Chrome’s case, the improvement may account for up to 10% of the page load performance.

Mozilla said that it activated False Start support in its nightly builds of Firefox 4 , but started receiving reports about broken websites almost immediately and decided to disable this feature again.

You can leave a response, or trackback from your own site.