A10 Networks, Brocade, and F5 (in some configurations) all had problems with False Start.
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.
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.
I said the following in email last night when explaining this to someone:
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.
The guessable primes were in routers sold to the general public, which as a rule are cheap and don't get any kind of security maintenance.
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).
False Start is conceptually somewhat similar to T/TCP, in that it allows data to be pipelined with control traffic.
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.
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.
oops, thought it might fetch all at once...a separate round trip wouldn't make sense. (Granted, you're maybe doing a smaller hop to local DNS than to overseas SSL.)
To be fair to herf, ANY queries might produce this information in one query. (Then again, they might silently omit all or part of the answer. Also, querying "bare" domains like example.org will produce unneeded records like SOA/NS/MX.)
oh they found it hard so gave up - as some one who used to work with OSI protocols ad having looked at some the google proposed standards it doesn't surprise me.
Why not accept a special header similar to "Strict-Transport-Security"? Let it be X-False-Start and for following requests False Start would be enabled for that site.
"Langley went on to say he has experienced similar problems getting manufacturers of SSL products to make changes that protect against an exploit demonstrated in September known as BEAST..."
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.
20 comments
[ 3.5 ms ] story [ 48.0 ms ] threadOn 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).
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.