4 ms·

compatible "with well over 99 percent" and Google is bailing because of the remaining incompatible sites????

jrabone 14y ago
Well, if that 1% happens to be "all the banking websites in the world" I can imagine why they would bail.
tptacek 14y ago
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.
- gcp 14y ago
  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.
  - tptacek 14y ago
    Not sure how you'd "go back on that". It's a vulnerability; it needs to be addressed.
    - gcp 14y ago
      If it breaks websites that your users require to work, like their bank, of course you can and must go back, security issues be damned. 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.
NateLawson 14y ago
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.
- obtu 14y ago
  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).

Well, if that 1% happens to be "all the banking websites in the world" I can imagine why they would bail.

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.

gcp 14y ago
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.
- tptacek 14y ago
  Not sure how you'd "go back on that". It's a vulnerability; it needs to be addressed.
  - gcp 14y ago
    If it breaks websites that your users require to work, like their bank, of course you can and must go back, security issues be damned. 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.

NateLawson 14y ago

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.

obtu 14y ago
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).