compatible "with well over 99 percent" and Google is bailing because of the remaining incompatible sites????
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).