148876 - SSL fails with only TLS enabled.

Status: VERIFIED INVALID

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

Description

[Henrick Hellström]

After setting SSL 2 to disabled and SSL 3 and TLS 1 to enabled, Mozilla will
still initiate SSL sessions with a SSL 2 client hello handshake message. SSL 2
client hello handshake messages should only be sent by clients that support SSL
2. This bug may conflict with a recommendation made as early as in the 1996 SSL
3 draft that SSL 2 support should be dropped as soon as possible.

Furthermore Mozilla may occasionally send other types of SSL 2 handshake
messages wrapped in SSL 3 records. Such "SSL 23" behaviour should never occur.
Sending a SSL 2 client hello is acceptable, but that's it.

Lastly, Mozilla claims that SSL is disabled when SSL 2 & 3 are disabled but TLS
1 is enabled. In such situations Mozilla will refuse to connect to https
servers. The proper behaviour would be to send a SSL 3 / TLS 1 client hello with
version set to (3,1).

Comment 1

[John Unruh]

Confirming at least the last paragraph.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

This bug report attempts to report 3 separate problems.

The first part (paragraph) of this bug is invalid.  

An SSL client (especially an https client) does not, in general, know in
advance whether the server it is contacting is an SSL2 only server, or
is an SSL2/SSL3 (and possibly TLS) server.  If it sends an SSL3/TLS 
formatted client hello message to a server that happens to be an SSL2-only
server, the connection HANGS!!  This is because the SSL2 server interprets
the SSL3 client hello as a REALLY LONG SSL2 record (much longer than the
length of the SSL3 client hello), and the server simply keeps on trying 
to read data from the connection until it times out.

In recognition of this problem, the SSL3 and TLS specs specify that SSL3
and TLS client hello messages can be formatted in an SSL2-compatible 
format, so that an SSL2-only server will reject them quickly, rather than 
hanging on them.  SSL3/TLS servers are supposed to support this 
SSL2-compatible client hello format, especially if they are https servers, 
even if they do not actually support SSL2!

So, it is appropriate for an SSL3 client to send a client hello in SSL2
format to a server it has not previously contacted, even if the client
has SSL2 disabled.  After the initial contact, subsequent connections
to the same server typically use the SSL3/TLS format client hello, because
it is necessary to use that format to restart an SSL3/TLS session.

I'd insist on proof of the claim in the second paragraph of this bug report
before I'd accept it as a valid bug.  If the submittor can prove the claim
in the second paragraph, a separate bug should be submitted, along with 
an attachment that is proof.  

The last part of this bug seems valid.  The SSL/TLS library code (and PSM)
should work when only TLS is enabled.  I don't know if it's an NSS bug or
a PSM bug.   This bug should be interpreted as being only about the 
complaint in the third paragraph.  

Comment 3

[John Unruh]

Changing summary. Disable SSL2 and SSL3 in the prefs, and you cannot visit 
https://www.verisign.com

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Do we know for a fact that www.verisign.com's server supports TLS?

If you disable SSL2 and SSL 3.0, but enable TLS (which is SSL 3.1),
and you go and visit a server that does not support TLS, then it will
fail.  That is not an error in our client code.

IFF you know of a server that supports TLS, and you visit it with 
TLS enabled, but SSL2 and SSL3.0 disabled, and it fails, then this bug 
is valid.  Otherwise, this bug in invalid.

Comment 5

[John Unruh]

Good point. I can reach https://www.thawte.com/cgi/personal/cert/enroll.exe with 
only TLS enabled, as well as in-house TLS only server https://pki.mcom.com:5002

Comment 6

[John Unruh]

Verified.

Comment 7

[John Unruh]

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

Comment 8

[Cameron Rich]

I would argue that connecting to an SSLv2-only server should work with SSLv2 disabled. With SSLv2 disabled, a connection to an SSL2 server should FAIL (with a timeout, or whatever).

Since SSLv2 is far less secure than SSLv3/TLSv1, this is a security deficiency - and a serious one. The point to disabling SSLv2 is to improve the user's security options.

Ignore it and you do so at your peril. Even Microsoft's IE6 agrees (ie with SSLv2 disabled it sends a proper SSLv3/TLSv1 client hello message).

Comment 9

[Brian Polidoro]

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

Comment 10

[Brian Polidoro]

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