Closed Bug 945195 Opened 6 years ago Closed 6 years ago

Gecko does not do insecure TLS intolerance fallback from TLS 1.0 to SSL 3.0 on FIN during handshake

Categories

(Core :: Security: PSM, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla28
Tracking Status
firefox27 --- unaffected
firefox28 + verified

People

(Reporter: briansmith, Assigned: briansmith)

References

()

Details

(Keywords: compat, regression)

Attachments

(1 file)

Broken page caused by this bug: https://billingcp.us/clientarea.php

This is a regression introduced by bug 901718.

That bug was filed based on a suggestion from Wan-Teh that we should not do TLS intolerance fallback from TLS 1.0 to SSL 3.0 when we receive a RST during the handshake. I over-generalized that suggestion and removed the TLS intolerance fallback from TLS 1.0 to SSL 3.0 on receipt of FIN too. I verified that Chrome 31, Chrome Canary, and Internet Explorer 11 on Windows all do this type of fallback.

In the MozillaZine forum thread, "trolly" wrote:

According to Wireshark the server terminates the connection immediately after receiving the "Client Hello".

15 3.988740000 192.168.0.102 198.23.156.12 TCP 66 ispipes > https [SYN] Seq=0 Win=65535 Len=0 MSS=1452 WS=4 SACK_PERM=1
16 4.100948000 198.23.156.12 192.168.0.102 TCP 66 https > ispipes [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1452 SACK_PERM=1 WS=128
17 4.100982000 192.168.0.102 198.23.156.12 TCP 54 ispipes > https [ACK] Seq=1 Ack=1 Win=261360 Len=0
18 4.102699000 192.168.0.102 198.23.156.12 SSL 207 Client Hello
19 4.213028000 198.23.156.12 192.168.0.102 TCP 60 https > ispipes [ACK] Seq=1 Ack=154 Win=15744 Len=0
20 4.214430000 198.23.156.12 192.168.0.102 TCP 60 https > ispipes [FIN, ACK] Seq=1 Ack=154 Win=15744 Len=0
21 4.214557000 192.168.0.102 198.23.156.12 TCP 54 ispipes > https [ACK] Seq=154 Ack=2 Win=261360 Len=0
22 4.215926000 192.168.0.102 198.23.156.12 TCP 54 ispipes > https [FIN, ACK] Seq=154 Ack=2 Win=261360 Len=0

Edit: Chrome succeeds with SSLv3 which Firefox does not even try. The server does not seem to understand TLS.
I verified that this patch fixes the issue, and  https://billingcp.us/clientarea.php loads in Firefox as it does with IE and Chrome.
Attachment #8341032 - Flags: review?(honzab.moz)
Attachment #8341032 - Flags: review?(honzab.moz) → review+
https://hg.mozilla.org/mozilla-central/rev/da83eb7cb686
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Prevents some pages from loading, we'll track in case this regresses.
I can verify this is fixed in

http://hg.mozilla.org/mozilla-central/rev/8648aa476eef
Status: RESOLVED → VERIFIED
I don't know if this is also a regression, but it's the same issue:

I'm behind a http proxy (which makes ff to use a http tunnel with CONNECT)
When I access https://wiki.gnome.org I get this connection interrupted error.
tcpdump shows that ff tries only tls 1.2 (doesn't fallback to ssl 3.0)

If I change the config "security.tls.version.max" to 0, forcing ff to use ssl, it works fine, the page is loaded correctly.
(In reply to David Keeler (:keeler) from comment #7)
> That looks like a problem with your proxy.
> https://www.ssllabs.com/ssltest/analyze.html?d=wiki.gnome.org says
> https://wiki.gnome.org supports TLS 1.2.

Please handle this in a new bug.
OK. just opened bug 969479.
You need to log in before you can comment on or make changes to this bug.