+++ This bug was initially created as a clone of Bug #754356 +++ I noticed when comparing our implementation of TLS intolerance to Google Chrome's that Chrome does not do TLS intolerance fallback on connection resets from TLS 1.0 to SSL 3.0. Today, Wan-Teh also pointed this out in a patch review. These are often false positives and such false positives are harmful because they prevent TLS extensions (SNI, OCSP stapling, and NPN/ALPN, in particular) from being communicated. Apparently the Googlers found that there are situations where a connection reset occurs due to TLS 1.1 intolerance, and so they do allow connection resets to trigger their TLS 1.1 -> TLS 1.0 fallback. Although TLS 1.1 -> TLS 1.0 isn't nearly as bad as TLS 1.0 -> SSL 3.0 (given that we don't have issues with BEAST or Lucky 13 in NSS), I think it is worth seeing if the situation has improved at all since Google's experiment. That is, first, let's try to just avoid the TLS intolerance fallback on connection reset at all; if we run into too much brokenness, we can do as Google has done. Also, we should check what MSIE is doing here; if they are being stricter, it will be easier for us to be stricter too.

I have also seen this reset in case of TLS > 1.0 intolerance, but I'm not sure I know any sites that still have that problem. If you intend to just retry with 1.1 again on reset, I suggest you limit the amount of times you do that, and then maybe still try to go to 1.0.

Just FYI, I've seen Chrome 27 downgrade all the way to SSL 3.0 in my tests. I have no knowledge of the implementation details.

Ivan: does your test use a TCP reset packet to abort the SSL/TLS handshake? ECONNRESET (connection reset by peer) is the connection error considered in this bug. An ECONNRESET error should not cause Chrome to downgrade from TLS 1.0 to SSL 3.0. If you see Chrome 27 do that in response to a TCP reset packet, it is either a Chrome bug, or the OS is reporting an error code other than ECONNRESET.

No, I setup all connection attempts to fail with a Handshake Failure alert. I now realize that that I misinterpreted the purpose of this bug. Sorry.

Ivan: no problem. Yes, a handshake_failure alert and a graceful TCP connection closure (a read/recv call that returns 0) cause Chrome to downgrade from TLS 1.0 to SSL 3.0.

Note that this patch is based on the patch for bug 707275 that refactors this code and adds telemetry. I don't want to block this on landing the changes to NSS that are required for the test, since it seems like those NSS changes are going to take a long time, so I am going to attach the test patch to bug 936818 so that this bug doesn't stay open forever.

Comment on attachment 831296 [details] [diff] [review] disable-tls-intolerance-fallback-to-SSL-3.0-for-RST-and-FIN.patch Review of attachment 831296 [details] [diff] [review]: ----------------------------------------------------------------- r=honzab except the discrepancies in the comment this is OK. ::: security/manager/ssl/src/nsNSSIOLayer.cpp @@ +948,5 @@ > // In addition check for some error codes where it is reasonable > // to retry without TLS. > > // Don't allow STARTTLS connections to fall back on connection resets or > + // EOF. Also, don't fall back from TLS 1.0 to SSL 3.0 on connection, "don't fall back [..] on connection" ? what that means?

https://hg.mozilla.org/integration/mozilla-inbound/rev/a8f5e75b8ed8 (In reply to Honza Bambas (:mayhemer) from comment #7) > "don't fall back [..] on connection" ? what that means? Thanks for catching that. I fixed that in this follow-up push: https://hg.mozilla.org/integration/mozilla-inbound/rev/78fd5daacc01

https://hg.mozilla.org/mozilla-central/rev/a8f5e75b8ed8 https://hg.mozilla.org/mozilla-central/rev/78fd5daacc01

This thread on Mozillazine has some sites that are not loading: http://forums.mozillazine.org/viewtopic.php?f=23&t=2778227 https://billingcp.us/clientarea.php give a 'connection interrupted' error page The above link loads in latest Chrome Dev, and IE11 Not totally clear I think from the discussion in the thread if its working as expected, or something is not working just right. There was also a regression range in that thread pointing back to this bug...

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #10) > Not totally clear I think from the discussion in the thread if its working > as expected, or something is not working just right. Thank you very much for alerting us to this, Jim. I filed bug 945195 to track this regression. If you are a mozillazine forum member, please share the link to bug 945195 to the people in the thread.

Can someone provide an site that I can use to verify this bug? Thanks

(In reply to Catalin Varga [QA][:VarCat] from comment #12) > Can someone provide an site that I can use to verify this bug? > Thanks Please contact dougt about this.

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #13) > (In reply to Catalin Varga [QA][:VarCat] from comment #12) > > Can someone provide an site that I can use to verify this bug? > > Thanks > > Please contact dougt about this. Doug, can you please answer this?

as of right now https://www.citibank.com/ requires ssl3 https://www.ssllabs.com/ssltest/analyze.html?d=citibank.com hth

I am using Firefox 28.0.(windows and linux) Here is a SSLv3 site: https://www.mahaconnect.com This site works in Firefox for windows. But it does not work on Firefox for Linux. It works if I change max tls version to 1. But in windows it works even if max tls version as 3. On Linux I am using OpenSSL v1.0.1e (but patched for heartbleed). I am not sure if Firefox uses system OpenSSL. What could be the reason?

Sorry site is: https://www.mahaconnect.in

(In reply to Amm from comment #16) Amm, could you please ask this on support.mozilla.org? This isn't really the best place to get that question answered.

Thanks Anthony, but I thought it was a bug. So reported the site here. But later on I found the reason. Not sure if its a bug or the expected behavior. But just reporting in case anyone else faces same. I have a squid proxy with sslbump set up, Which mimics certificate. (squid does not work with that site because squid tries TLS1.2 and site supports only SSLv3 and sends connection reset) FF -> transparent squid proxy -> try TLS1.2 to www.mahaconnect.in -> connection reset -> squid initiates TLS1.2 with FF -> reports error -> FF thinks site supports TLS 1.2 (caches this) Then I set "No proxy" in FF. But it still fails with "no_cypher_overlap" error. Because Firefox now believes site supports TLS 1.2 but notices the change and reports security error. Now I restart Firefox so it forgets that mahaconnect.in supports TLS1.2. I keep "no proxy" option in FF. And then if I access the site, it opened fine. May be we can blame squid here for not falling back on SSLv3.

Amm - let's make this the last entry in this closed bug. I believe what you are seeing is just the Firefox downgrade prevention code. The website was known to speak 1.2 and then suddenly it was speaking the less secure sslv3 - so firefox is concerned it could be a man in the middle attacker who downgraded you with the hope of making you more hackable. So it doesn't allow the connection.