The False Start draft [1] aims to reduce the latency introduced by the use of TLS for application protocols in which the client sends data first.
Chrome 9 and Firefox 4(still in beta) support False Start(although it seems for compatibility issues that currently Firefox disabled it [3][5]).
To quickly picture this with Wireshark, here is a full (normal) TLS handshake(using RSA for authentication and key exchange), in the first image we see the encrypted version of the traffic flow and in the second one the decrypted version.
No False Start Encrypted traffic flow:
No False Start unencrypted traffic flow:
Note that the client can forward application data over the TLS tunnel after both sides had send their "ChangeCipherSpec" and "Finished" messages. Once both "Finished" messages have been received and successfully verified, this would validate the handshake.
Now let’s picture False Start in action, Chrome 9 on Windows 7 was used, in the first image we see the encrypted version of the traffic flow and in the second one the decrypted version.
False Start encrypted traffic flow:
False Start unencrypted traffic flow:
This time, as can be viewed, the client can forward application data over the TLS tunnel after it had send its "ChangeCipherSpec" and "Finished" messages but before it has received the server’s ones. Once both "Finished" messages have been received and verified, this retroactively validates the handshake.
If a side does not receive the other side's "Finished" message, or if the "Finished" message's contents are incorrect, the handshake will not be validated. This means that an attacker may have blocked or tampered handshake messages.
Incompatibility issues
There are some interoperability issues [7].
A False Start compatible TLS implementation does not have to be aware about False Start, if it tolerates receiving TLS records on the transport connection early(before the “Finished" message) as we saw above, these records with application data will simply remain buffered for later processing.
Theoretically, according to the draft, only a small percentage of the web server’s found in the wild will not be False Start compatible.
Google’s solution to this is not to fallback to a no False Start handshake, rather to create a blacklist of such sites [2].
It has been reported that some load balancers or outbound HTTPS inspection web proxies [6] may not be False Start compatible.
Security issues
Because the client sends its application layer data before receiving the “ChangeCipherSpec" and "Finished" messages, the client has not validated the handshake.
An attacker can modify on-the-fly the handshake messages, for example, change the cipher suite list sent by the client to the server and so influence the cipher suite selection in an attempt to downgrade the cipher suite strength.
To address such a case, clients should only use False Start with servers which choose a strong symmetric encryption algorithm, like AES128 or AES256 to mention a few.
Furthermore, the key exchange methods should be carefully selected, for example some servers are configured to use weak DHE exchanges(prime size less than 768-bits or so), having a cipher suites preferred order list which marks as the least preferred the DHE cipher suites(which normally would ensure that these cipher suites are not likely to be used with regular clients(browsers)). An attacker could force the use of a DHE cipher suite and due to the weak DHE exchange then compute the shared DH secret and read the client’s message.
Also clients must not use the False Start with a cipher suite which requires client certificate authentication unless the client certificate type has been whitelisted for False Start use.
Additionally TLS version rollbacks attacks have been mentioned [8]. This is somehow meaningless as writing, partially due to a couple of reasons.
First, False Start adopters: neither Chrome 9 nor Firefox 4 implement TLS 1.1 or higher.
Second: TLS version rollbacks outside the protection offered by TLS are common today, due to browsers’ fallback mechanisms to assure interoperability [9]. Such a rollback can be achieved with a MITM attack using a TCP RST for a Client Hello presenting TLS 1.1 as the highest TLS version supported by client. Upon receiving the TCP RST segment from the “server”, the client will automatically fallback to a Client Hello presenting TLS 1.0 as the highest TLS version supported, Client Hello which would be forwarded by the attacker to the real server and, unlike with False Start, due to the "Finish" messages being validated by both sides(the attacker has not tampered the handshake messages), a TLS 1.0 session will be successfully established.
For example, irrelevant in this case(since False Start is not used over SSL 3.0), with such an attack, on Windows 7, Chrome 9.0.597.949 (and Firefox 4.0 Beta 10), default settings, can fallback from TLS 1.0 to SSL 3.0.
References
[1] https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
[2] http://www.imperialviolet.org/2010/09/05/blacklisting.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=591523
[4] http://devcentral.f5.com/weblogs/david/archive/2011/02/08/mutations-in-the-tls-protocol-hsts-false-start-snap-start.aspx
[5] http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg09572.html
[6] http://forums.isaserver.org/fb.aspx?m=2002105806
[7] http://code.google.com/p/chromium/issues/detail?id=67565
[8] http://www.ietf.org/mail-archive/web/tls/current/msg06933.html
[9] http://www.ietf.org/mail-archive/web/tls/current/msg07281.html