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 Appl

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.