Re: [TLS] Prohibiting SSL 3.0

[[e-mail] (Martin Rex)]

Manuel Pégourié-Gonnard wrote:
> On 29/10/2014 12:18, Florian Weimer wrote:
>> 
>> I think the SSLv2 compatible client hello is unrelated to the protocol
>> version advertised by the client, but I might be mistaken about that.

Correct.  You can negotiate TLSv1.2 on a connection that is started
with a SSL VERSION 2.0 CLIENT-HELLO.


>
> Unless I'm mistaken, there is no point for a client to send a SSLv2
> compatible ClientHello unless the client is prepared to actually
> negotiate SSLv2. If think if fair to say that client MUST NOT do that.

You might be surprised just how much crap (as servers) got shipped into
the installed base, and what turns out to be the most suitable workaround
to interop with those.

The problem with SSLv3 & ClientHello protocol version negotiation is
that a number of servers totally goofed the implementation, and a number
of clients (pretty much all browsers) followed suit.

The issue with TLS protocol version negotiation is that the SSLv3&TLS record
layer uses a "protocol_version" tag in the record layer PDU that indicates
_the_record_layer_PDU_encoding_, and when an initial ClientHello
is received on a new connection, there is also a ClientHello.client_version
field included.  A number of broken servers screwed up the protocol
version negotiation (which is performed EXCLUSIVELY through
ClientHello.client_version) by choking on the record layer PDU encoding
protocol_version when it differs from ClientHello.client_version.

Now the advantage of the SSL VERSION 2.0 CLIENT-HELLO is that it comes
with only a single protocol version -- and it seems that less server
implementors got that wrong.



> 
> OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
> server will never negotiate SSLv2. So I guess the MAY here is ok.

We already settled the SSLv2 ClientHello issues.

http://tools.ietf.org/html/rfc6176#section-3


-Martin