901718 - Remove TLS intolerance fallback from TLS 1.0 -> SSL 3.0 for connection resets

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ 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.

Comment 1

[Kurt Roeckx]

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.

Comment 2

[Ivan Ristic]

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.

Comment 3

[Wan-Teh Chang]

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.

Comment 4

[Ivan Ristic]

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.

Comment 5

[Wan-Teh Chang]

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.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: disable-tls-intolerance-fallback-to-SSL-3.0-for-RST-and-FIN.patch

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 7

[Honza Bambas (:mayhemer)]

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?

Comment 8

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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

Comment 9

[Ed Morley [:emorley]]

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

Comment 10

[Jim Jeffery not reading bug-mail 1/2/11]

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...

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(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.

Comment 12

[Catalin Varga [QA][:VarCat]]

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

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(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.

Comment 14

[u279076]

(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?

Comment 15

[Patrick McManus [:mcmanus]]

as of right now https://www.citibank.com/ requires ssl3

https://www.ssllabs.com/ssltest/analyze.html?d=citibank.com

hth

Comment 16

[Amm]

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?

Comment 17

[Amm]

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

Comment 18

[u279076]

(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.

Comment 19

[Amm]

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.

Comment 20

[Patrick McManus [:mcmanus]]

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.