False Start's sad demise: Google abandons noble attempt to make SSL less painful
arstechnica.com
arstechnica.com
Specifically: False Start instructs clients to release data to the server before both sides of a TLS connection exchange FINISHED messages. Those FINISHED messages authenticate the control messages in the handshake, so the client is giving up some data without being sure that all the handshake messages were authentic.
A MITM attacker can in theory exploit this to get a client to cough up data under the rules & assumptions of earlier versions of the protocol or less secure / different ciphersuites. For instance, there was some question as to whether False Start would enable an attacker to knock a TLS session down to TLS 1.0 long enough for an attacker to get cookies with the BEAST CBC IV reuse problem.
As I understand it, there's no smoking-gun problem with False Start. I also don't think the security tradeoffs have anything to do with its market failure! But the performance win also might not have been worth the disruption. False Start gets TLS down to 1 RTT before data, but TLS resumed sessions are already 1 RTT before data.
http://rdist.root.org/2012/02/27/ssl-optimization-and-securi...
What's interesting to me about Adam's post is how fragile protocol implementations are in appliance-type devices. Of course, having seen the internals of other similar devices, I'm not surprised, but the parallels to consumer electronics are surprising, given the critical nature of these network appliances.
Not sure who he is referring to when he says "manufacturers of SSL products," but it seems damn near impossible to get everyone deploying SSL to fix mixed content vulnerabilities.
Maybe diverse markets with lots of players just can't do security.
On the other hand, these terminators also have problems with the split-first-record fix to the TLS 1.0 BEAST vulnerability, and that problem has to get fixed.
Do you know if Google is going back on that as well? Can't tell from the article.
Google postponed BEAST mitigation several times because of this issue. I'm asking if they're reigning back on that or only on false start.
False Start is controlled by the client. The client sends its Finished and first ApplicationData message instead of waiting for the server's Finished message. Adam thought that since they put the two client messages in a single packet, servers would either fail to handle it or succeed.
However, he found that some servers would fail inconsistently. His explanation for that has to do with internal synchronization of various tasks within the server process, although it's only a guess. Whatever the case, it means their efforts to test SSL servers to see if they can support False Start would have to be redone, and it's not clear how many times they'd have to test a server to be sure it could handle False Start since the failures are intermittent.
In short, the Internet is a messy place, and standards are only reliable to the extent that implementations are robustly tested for every corner case. See also the recent fiasco where embedded devices like home routers had guessable RSA primes.
It's rather shameful that vendors of expensive “SSL accelerators” aren't able to fix their problems. That inability to support the products they sell makes SSL slower (FalseStart) and less secure (TLS 1.1+ adoption, the BEAST attack).