167227 - TLS intolerant https pages don't load

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P3)

Description

[ltskinol]

Version: 6 Sep 2002 nightly binary
OS: Linux, 2.4.19 kernel, glibc 2.2.5

To reproduce:

1. Load the listed URL.
2. Click on any of the "Buy" images.

Results: Throbber throbs for a half second, then nothing.  Page
doesn't load.

Expected: item gets added to shopping cart and page renders.

This has regressed since 1.1 release, and also worked in 1.0.

Comment 1

[Andrew Schultz]

confirmed with linux trunk build 20020906
regression between linux trunk builds 2002081104 and 2002081304
disabling pipelining or http/1.1 does not help.

server is Stronghold/2.1.1 Apache/1.2.4

==> Http

Comment 2

[cindy]

confirmed windows98 trunk 2002090608
had no problem loading other https sites

Comment 3

[tenthumbs]

Server is TLS1 intolerant.

Comment 4

[ltskinol]

... and thus un-checking "Enable TLS" "fixes" the problem.

Comment 5

[Darin Fisher]

-> PSM (though perhaps this is just an evangelism bug?)

Comment 6

[John Unruh]

TLS intolerant, nelsonb's Flavor A. Here is the SSLtap output, 9/9 WinXP trunk 
build, new profile (with TLS enabled).
# ./ssltap -x -s hercules.smart.net:443
Looking up "hercules.smart.net"...
Proxy socket ready and listening
Connected to hercules.smart.net:443
--> [
alloclen = 72 bytes
(72 bytes of 72)
 [Mon Sep  9 08:59:23 2002] [ssl2]  ClientHelloV2 {
           version = {0x03, 0x01}
           cipher-specs-length = 45 (0x2d)
           sid-length = 0 (0x00)
           challenge-length = 16 (0x10)
           cipher-suites = { 
                (0x010080) SSL2/RSA/RC4-128/MD5
                (0x030080) SSL2/RSA/RC2CBC128/MD5
                (0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5
                (0x060040) SSL2/RSA/DES56-CBC/MD5
                (0x020080) SSL2/RSA/RC4-40/MD5
                (0x040080) SSL2/RSA/RC2CBC40/MD5
                (0x000004) SSL3/RSA/RC4-128/MD5
                (0x00feff) SSL3/RSA-FIPS/3DES192EDE-CBC/SHA
                (0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA
                (0x00fefe) SSL3/RSA-FIPS/DES56-CBC/SHA
                (0x000009) SSL3/RSA/DES56-CBC/SHA
                (0x000064) TLS/RSA_EXPORT1024/RC4-56/SHA
                (0x000062) TLS/RSA_EXPORT1024/DES56_CBC/SHA
                (0x000003) SSL3/RSA/RC4-40/MD5
                (0x000006) SSL3/RSA/RC2CBC40/MD5
                }
           session-id = { }
           challenge = { 0x3d53 0x2b59 0x319f 0x30f8 0x84db 0xd8fd 0x6e05 0xb6d1 
}
}
]
Read EOF on Server socket. [Mon Sep  9 08:59:23 2002]
Read EOF on Client socket. [Mon Sep  9 08:59:23 2002]
Connection 1 Complete [Mon Sep  9 08:59:23 2002]

Comment 7

[Kai Engert (:KaiE:)]

possibly a dupe of 162752, 166931

Comment 8

[John Unruh]

*** Bug 168473 has been marked as a duplicate of this bug. ***

Comment 9

[John Unruh]

*** Bug 169141 has been marked as a duplicate of this bug. ***

Comment 10

[Stephane Saux]

TLS intolerant sites are disappearing. Severity minor.

Comment 11

[Kai Engert (:KaiE:)]

This bug is possibly a consequence of our change, to go away to assume TLS
intolerance for all kinds of failures, to only assume intolerance when seeing an
error in our positive list.

Actually, the failure we see here is PR_END_OF_FILE_ERROR. This bug was not yet
in the general positive list. (Only when talking with proxies this failure was
assumed to be tls intolernace).

I have also checked that the tentative patch from bug 163605 doesn't make the
situation worse. But it doesn't.

So the solution is simple, we need to assume TLS intolerance when
PR_END_OF_FILE_ERROR, regardless whether we are using a proxy or not.

I'm updating the patch in bug 163605 to generally turn off TLS when this error
is seen, and my testing showed it fixes this bug.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Kai wrote:

> So the solution is simple, we need to assume TLS intolerance when
> PR_END_OF_FILE_ERROR, regardless whether we are using a proxy or not.

As discussed in http://bugzilla.mozilla.org/show_bug.cgi?id=106865#c32 
(comments 32 and later) PR_END_OF_FILE_ERROR reports an condition that
may be a "truncation attack" on SSL/TLS.  It has a different meaning
than EOF (e.g. read returning zero bytes).  

If no data has been sent, and PR_END_OF_FILE_ERROR is received, then
that could be a sign of TLS intolerance.

If the http request has already been sent, and PR_END_OF_FILE_ERROR is 
received, the client should NOT automatically retry.  In fact, the 
client should probably not retry at all, but instead an error dialog
should be displayed.  

So, the proper interpretation and handling of PR_END_OF_FILE_ERROR 
depends on knowledge of whether or not any data has been succesfully 
read from or written to the socket.

Comment 13

[Kai Engert (:KaiE:)]

Nelson, please see my answer to your comment in bug 163605 (where you added the
same comment). I believe you wanted to reconfirm I'm not doing the wrong thing,
but I believe I'm following your recommendation.

Comment 14

[Kai Engert (:KaiE:)]

If you have time today and want to help test the fix for this bug, please grab a
build from http://www.kuix.de/mozilla/163605/ and test whether it works, and
there are no regressions in SSL functionality. Please give feedback today or
early tomorrow. Thanks!

Comment 15

[Kai Engert (:KaiE:)]

This should be fixed starting with tomorrow's build, by the patch for bug
163605. Please reopen if you still can reproduce the problem.

Comment 16

[ltskinol]

I tested the fix in comment #14.  Looks good to me.  Thanks!

Comment 17

[John Unruh]

Verified. Please open new bugs for individual sites that cannot be reached.