Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt

[Bodo Moeller <[e-mail]>]

On Wed, Jul 05, 2006 at 07:32:09AM -0400, Rob Dugal wrote:
> Bodo Moeller <[e-mail]> wrote on 07/04/2006 05:41:06 AM:
>> On Mon, Jul 03, 2006 at 07:14:15PM +0300, [e-mail] wrote:

>>> A quick and totally unscientific survey of what some widely used
>>> SSL/TLS implementations do:
>>> 
>>> - OpenSSL (0.9.8)
>>>   - When configured in "both SSLv3 and TLSv10 allowed" mode,
>>>     sends V2 ClientHello.

>> This is the behavior of OpenSSL versions up to 0.9.7g.  Versions
>> 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3
>> format Client Hello message with version number {03,01} in both
>> fields. 

> The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour 
> would be to encode the minimum protocol {03,00} in the record's protocol 
> field and the highest protocol {03,01} in the client_hello message's 
> protocol field. A server that understands only SSLv3 could reject a client 
> hello message that uses a record protocol of TLSv1. To negotiate with an 
> SSLv2 server the client must send an SSLv2 client hello so why would the 
> situation be any different for SSLv3/TLSv1? 

Using {03,00} for the record protocol field certainly would make the
most sense, when you're trying to follow the protocol specification.
However, the RFCs aren't totally clear about the situation: RFC 2246
only requests that "a TLS server which wishes to interoperate with SSL
3.0 clients should accept SSL 3.0 client hello messages", but it does
not demand that TLS-1.0-*only* servers (with no intention to
interoperate with SSL 3.0 clients) tolerate a {03,00} version in the
record header.  On the other hand, RFC 2246 only says that "TLS
clients who wish to negotiate with SSL 3.0 servers should send client
hello messages using the SSL 3.0 record format and client hello
structure" and does not makes this a "must".  The language in RFC 4346
(with another minor protocol version to take into account) does not
clear this up, in fact if you try to take it literally it makes
matters worse since the backwards compatibility section only mentions
SSL 2.0 and SSL 3.0 client hello messages, but no TLS 1.0 client hello
messages (which would make a lot of sense for the TLS1.0 + TLS1.1
case).

Essentially, OpenSSL 0.9.7h is following a trend set by other client
implementations.  If everyone was using {03,00} version records to
encapsulate TLS 1.0 Client Hellos, then OpenSSL probably would do this
too.  But there are plenty of broken servers out there, and the
experience is that some of these will mistakenly use {03,00} as the
client's maximum protocol version, even if this really is higher (and
correctly sent in the actual content of the Client Hello message).
This means that an obsolete protocol version will be negotiated
(SSL 3.0 when both parties actually do support TLS 1.0 or later), and
in the case of an RSA key exchange, it may lead to an aborted
handshake (since client_version is duplicated in the encrypted
premaster secret).  Heuristically, sending {03,01} in the record header
appears to be less problematic since typical SSL 3.0-only servers will
accept this Client Hello without complaining.  (Some very broken SSL 3.0
servers used to of problems even with this, but we can't accommodate
everything.)

I'm not saying that SSL3.0 + TLS1.0 clients *should* use {03,01} for
the record protocol field, though.  They are absolutely welcome to use
{03,00}, and similarly, it is perfect for TLS1.0 + TLS1.1 clients to
use {03,01} (TLS 1.0) rather than {03,02} (TLS 1.1), and for future
TLS1.1 + TLS 1.2 clients to use {03,02} rather than {03,03}.  Sending
any value {03,xx} where the respective protocol version is supported
by the client looks OK to me, and should be tolerated by servers, even
if the server does not know about said protocol version.  (If the
handshake attempt fails since the server has to downgrade from a
protocol {03,xx} supported by the client to {03,yy}, yy < xx, where
{03,yy} is not supported by the client, then at least the client will
learn about the highest version supported by the server, providing for
an informative error message.)

This, of course, assumes that the Client Hello format is not actually
changed between minor protocol versions.  If there were actual
significant differences (apart from hello extensions, which rely on a
forward compatilibity provision in the original SSL 3.0 and TLS 1.0
specifications), there was bound to be chaos.  However, given the
current state and the unclear language in RFC 2246 and RFC 4346, we
can conclude that it would be utter madness to ever change the Client
Hello structure in an incompatible way without changing the major
protocol version: If such a change was ever considered necessary, then
we'd again have a situation like the current SSL2.0 / SSL3.0+TLS1.x
interoperability situation on a higher level, i.e. the Client Hello
message would be sent in SSL3.0+TLS1.x format (using the current
structure definition) and the Client Hello message would name some
version {04,xx}, without being able to use any new features requiring
the new native Client Hello format (like we currently can't use
Client Hello extensions in SSL 2.0 backwards compatible mode).



_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls