354654 - Firefox uses SSLv2 Client Hello even when setup to use TLS

Status: RESOLVED DUPLICATE of bug 148876

(Firefox :: Security, defect)

Description

[Richard]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

On the Tools->Options, then Security Tab. Tick off SSL v2 and SSL v3.
Connect to a TLS server, I have a test server written using OpenSSL and only setup to use TLS.

The Client Hello from Firefox is rejected by OpenSSL, looking at the Ethereal logs it picks it up as an SSLv2 packet. When doing the same with IE, it Ethereal picks up the packet as an TLS packet and the handshake is successful.

Reproducible: Always

Steps to Reproduce:
1. On the Tools->Options, then Security Tab. Tick off SSL v2 and SSL v3.
2. Connect to a TLS only server
3. Get error "SSL has been disabled".

Actual Results:  
Fails to perform TLS handshake.

Expected Results:  
Successful TLS handshake and then download webpages using TLS.

Comment 1

[Brian Polidoro]

The explanation for this is in bug 148876:

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.

Comment 2

[Brian Polidoro]

This basically says the same thing:

Appendix E of the TLS specifications states that all client applications that wish to remain backward compatible with SSLv2 have to send a SSLv2 client hello to the server with the protocol version 3.0 or 3.1. This is buried at the end of the RFC and it took me some time to realise that the garbled first message that the sniffer was receiving from browsers were actually SSLv2 packets. Once I discovered this, I ran my sniffer on a couple of sites to test their SSL versions and found to my dismay that Wells Fargo still used SSLv2 on their internet banking pages.
You can determine the version by running the sniffer and examining the packet contents. If the sniffer is unable to parse the messages properly and the first byte of the packets are -128 or some negative number followed by some set of numbers which includes the protocol version, then it is probably running SSLv2.
In OpenSSL, the right set of functions to use are found in ssl23.h for backward compatibility with SSLv2. 

http://crypto.stanford.edu/~eujin/sslsniffer/documentation.html

The first step seems to be disabling SSL2.  Firefox 2, IE7, and Opera 9 disable SSL2 by default.  

So perhaps a version or two later Firefox will remove SLL2 completely and thus not send the SSL2 hello.  

*** This bug has been marked as a duplicate of 148876 ***

Comment 3

[Brian Polidoro]

Oops I thought of duping but I wasn't sure about it. And I forgot to remove that change.  Because if SSL2 is disabled then you don't really need to be SSL2 backward compatible.  So asking why we need to send the SSL2 handshake when SSL2 is disabled should be a valid question.  I was just hoping to show from what I can tell why SSL2 hello was used to this point.  

Comment 4

[Brian Polidoro]

Drat Thinking about it some more, disabling SSL2 on the client doesn't change the fact that you may (unfortunately) still encounter an SSL2 host.  

*** This bug has been marked as a duplicate of 148876 ***

Comment 5

[Richard]

Agreed, considering the information given the client would need to send the hello in SSLv2 format so as not to hang up any host that doesn't support TLSv1.

However, this does indicate two things:
* There is a bug in the version of OpenSSL library used when only enabling TLS as it does not accept the SSLv2 Client Hello.
* IE will hang up non TLSv1 hosts as it is definately not sending a SSLv2 Client Hello when only TLS is enabled.

Comment 6

[Brian Polidoro]

(In reply to comment #5)
> * There is a bug in the version of OpenSSL library used when only enabling TLS
> as it does not accept the SSLv2 Client Hello.

That's one reason I had included comment #2 which says that OpenSSL does have SSL2 functions available.  But maybe they are not available with TLS only.  

> * IE will hang up non TLSv1 hosts as it is definately not sending a SSLv2
> Client Hello when only TLS is enabled.

It wouldn't hang an SSL3 host would it?  I would think that that would just fail quickly.  

I guess MS is taking a slightly different strategy with SSL2.  You could say that gives an incentive not to use an SSL2 server.