There's no security benefit to requiring the NPN extension for False Start, AFAICT. We do it only because Chromium reported that this restriction was helpful for preventing hangs when connecting to false-start-intolerant servers, which just refuse to reply when we false start. Some conservative proxy for false start tolerance, in addition to NPN, might be AES-GCM, TLS 1.2, the ALPN extension, the original OCSP stapling extension, the multi-stapling extension. Additionally, talking with some people at MS indicated that they have some trick for reducing false start intolerance. It is worth investigating if changing the way we send ClientKeyExchange + ChangeCipherSpec + Finished + application data during false start helps with false start tolerance. For example, maybe it is better to send ClientKeyExchange + ChangeCipherSpec in one packet, and Finished in a second packet, and/or to combine the Finished and application data records into one packet.

See http://support.microsoft.com/kb/2592456 where an incompatibility with Microsoft TMG 2010 prior is fixed in MS TMG 2010 SP2.

From https://technotes.googlecode.com/git/falsestart.html: " The following TLS implementations are know to be False Start incompatible: Brocade load-balancers with firmware prior to 10.2.01s A10 load-balancers with firmware prior to 2.4.3-p4 F5 products configures with the `compat' SSL stack. (Not the default.) Threat Management Gateway (fix available from vendor) Some Cisco ASA products" Microsoft TMG's fix is: http://support.microsoft.com/kb/2592456 which is part of TMG 2010 SP2: http://support.microsoft.com/kb/2555840 I wrote, in bug 658222 comment 4: "So far, an incomplete list of products that are known to have current or previous compatibility problems with False Start include (AFAICT): F5, A10, Microsoft TMG, Cisco ASA, ServerIron ADX, ESET, NetNanny, some configurations of Java's SSL server implementation. Most, perhaps all, of these vendors have either released patches or are working on patches. In many cases, new deployments of these products will be shipping with the False Start compatibility fixes applied. This is why Google feels a black list is acceptable. "Restricting False Start to work only for certs that chain to a built-in root would, according to Wan-Teh, eliminate the known antivirus-/LSP/intercepting-proxy- incompatibilities." We need to also investigate how IE11 on Windows 8.1 splits the ClientKeyExchange+ChangeCipherSpec+Finished+initial application data. My understanding is that the way they split the data enables them to avoid most or all of the leftover incompatible sites. My understanding is that they also decided to intentionally stop working for the remaining incompatible websites not on their blacklist (which they seeded from Google's original blacklist).

Here is Microsoft's explanation of Windows 8.1 SChannel/IE11 behavior: http://blogs.msdn.com/b/ieinternals/archive/2012/08/01/internet-explorer-10-network-performance-improvements-first-available-pre-resolve-pre-connect-caching.aspx > With our implementation, we see a lower compatibility > impact than Google reported for their browser when > the feature was enabled. Internet Explorer does not > send application data in the same TCP packet as the > TLS Client Finished message; instead it is sent in > a new TCP packet. The following data describes the > compatibility impact of both implementations: > > Google’s implementation: 423 out of 2000 sites hang > when sending application data on the same TCP packet > as the TLS Client Finished message. > > Our implementation: 23 out of 2000 sites hang when > sending application data in a separate TCP packet. > > To minimize compatibility issues, we added the > following to our TLS False Start feature: > > * A blocklist that is populated with the sites known > to hang. Currently the list has the 23 sites > mentioned above. > * Logic to detect if a site hangs for longer than a > given threshold, which is currently 4 seconds. If > this happens, the next time the user navigates to > the site, we will not attempt TLS False Start. > This information is persisted only in memory to > allow a site to benefit from the improvement after > they update their servers to be standards-compliant. I think it is worth trying out an approach like Microsoft's. I think we may also be able to narrow down the compatibility impact further with some heuristics based on what the server returns in its ServerHello...ServerHelloDone, like the selected cipher suite. Here are the current numbers from Aurora regarding false start: chose to false start 13% RC4/3DES 0% RSA 0% RSA + RC4/3DES 0% No NPN 12% No NPN + RC4/3DES 0% No NPN + SSL 3.0 0% No NPN + RC4/3DES + SSL 3.0 0% No NPN + RSA 3,626,131 29% No NPN + RSA + RC4/3DES 45% Lack of NPN: 86% RSA key exchange: 74% RC4/3DES: 46% Thus lack of NPN is the biggest factor. But, the other factors are big factors too.

after talking with brian f2f the plan here as I understand it is to flip security.ssl.false_start.require-forward-secrecy and security.ssl.false_start.require-npn to false in firefox 30 while also bringing back the tls-intolerance code (this time to perform the timedout connection without false start) that sounds good to me. brian, please confirm that I've got this right.. and do you want to do the patch or do you want me to cobble one together?

(In reply to Patrick McManus [:mcmanus] from comment #4) > after talking with brian f2f the plan here as I understand it is to flip > security.ssl.false_start.require-forward-secrecy and > security.ssl.false_start.require-npn to false in firefox 30 while also > bringing back the tls-intolerance code (this time to perform the timedout > connection without false start) > > that sounds good to me. > > brian, please confirm that I've got this right.. and do you want to do the > patch or do you want me to cobble one together? We should work on flipping require-npn to false separately before we consider flipping require-forward-secrecy, to minimize compat risk, and since HTTP/2 seems to be headed down the "require forward secrecy" path anyway. The forward secrecy bit should be discussed in another bug, if you are still interested in doing it. Besides adding the timeout logic, we need to have a dynamic in-memory blacklist of domains to avoid false start on. The blacklist should be built based on the timeout logic and based on whether we've done a renegotiation on the connection. Also, we should find out what static blacklist Microsoft is using; we might just start with Google's old blacklist. We should also observe what MSIE11 on Windows 8.1 is doing w.r.t how the handshake messages are split up and how handshake records are split up, and make sure libssl is working like that. We also need to consider what to do about bug 589047 since MSIE11 is doing the opposite of that. At least we would need to comment in bug 589047 asking for that behavior to be made optional and off-by-default. We may also need to make changes to libssl to ensure a more MSIE11-like behavior. Finally, we should work with Matt Wobensmith to extend the compatibility tests he did for TLS 1.2 to test this and to expand the static blacklist of sites.

(In reply to Patrick McManus [:mcmanus] from comment #4) > do you want to do the patch or do you want me to > cobble one together? I would love to work on this but it will be a while before I get to it. If somebody else can get to it first, that would be great.

Comment on attachment 8534505 [details] [diff] [review] Stop requiring ALPN/NPN for False Start Review of attachment 8534505 [details] [diff] [review]: ----------------------------------------------------------------- Once all of the current dependency bugs are resolved, will all of the issues in comment 6 have been addressed?

(In reply to David Keeler (:keeler) [use needinfo?] from comment #9) > Once all of the current dependency bugs are resolved, will all of the issues > in comment 6 have been addressed? I hope so. We won't know for sure without having lots of users try it, because a lot of the issues are caused by virus scanners and similar things. Luckily, according to Google, at least some of those vendors have changed their software to work with False Start.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ed5fa69e3fdf Thanks for the quick review. I checked this in without waiting for bug 952863, because I don't think bug 952863 matters that much as far as these issues are concerned, and I want to get as much testing on this as possible.