Closed Bug 945195 Opened 7 years ago Closed 7 years ago
Gecko does not do insecure TLS intolerance fallback from TLS 1
.0 to SSL 3 .0 on FIN during handshake
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 184.108.40.206 TCP 66 ispipes > https [SYN] Seq=0 Win=65535 Len=0 MSS=1452 WS=4 SACK_PERM=1 16 4.100948000 220.127.116.11 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 18.104.22.168 TCP 54 ispipes > https [ACK] Seq=1 Ack=1 Win=261360 Len=0 18 4.102699000 192.168.0.102 22.214.171.124 SSL 207 Client Hello 19 4.213028000 126.96.36.199 192.168.0.102 TCP 60 https > ispipes [ACK] Seq=1 Ack=154 Win=15744 Len=0 20 4.214430000 188.8.131.52 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 184.108.40.206 TCP 54 ispipes > https [ACK] Seq=154 Ack=2 Win=261360 Len=0 22 4.215926000 192.168.0.102 220.127.116.11 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+
Priority: -- → P2
Status: ASSIGNED → RESOLVED
Closed: 7 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.
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.
(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.