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

[<[e-mail]>]

Bodo Moeller wrote:
> > - 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.  How did you run the test?  If you really used OpenSSL 0.9.8
> and really disabled SSL 2.0, then the library shouldn't have used
> the V2 Client Hello message format.

Hmm... I rechecked everything, and it turns out that I had
accidentally used an older version of OpenSSL installed from RPM
instead of the latest version I compiled myself.

When I re-ran the test using the latest version, it does indeed
behave the way you described.

Two additional data points: The Mozilla NSS library also sends
TLS/SSL3 format ClientHello with {03,01} in both fields if you set the
"SSL_V2_COMPATIBLE_HELLO" option to FALSE, and allow both SSLv3 and
TLSv10 (but apparently in Firefox this flag is TRUE even when
you disable SSL2 from the GUI).

PureTLS 0.9b5 also sends TLS/SSL3 format ClientHello with {03,01} in
both fields (when configured in "both SSLv3 and TLSv10 allowed" mode).

> The code used by OpenSSL to create the TLS/SSL3 record header
> for the Client Hello message is as follows:
> 
> 			/* fill in 5-byte record header */
> 			d=buf;
> 			*(d++) = SSL3_RT_HANDSHAKE;
> 			*(d++) = version_major;
> 			*(d++) = version_minor; /* arguably we 
> should send the *lowest* suported version here
> 			                         * (indicating, 
> e.g., TLS 1.0 in "SSL 3.0 format") */
> 			s2n((int)l,d);
> 
> The specification specifically demands the "SSL 3.0 record
> format and client hello structure", which is essentially the
> same as the TLS 1.0 record format and client hello structure,
> with the notable exception of the version number field.  So it's
> quite clear that you should put {03,00} into the record header
> version field, since this is the only way you can actually avoid
> the "TLS 1.0 record format" and use the "SSL 3.0 record format".
> On the other hand, this could trigger some bugs in thoughtlessly
> done server implementations, which are avoided by sending
> {03,01} in the record version field.

Yes; it seems that most other implementations also do this (and thus
servers also work with this, at least when the version is 03,01).

> In contrast, sending too large a minor version number (such as {03,01}
> for a record supposed to be in "SSL 3.0 record format") can be
> expected to work well with thoughfully done server implementations:
> If a server obtains a {03,xx} format Client Hello where the version
> number specified by the client is larger than the highest protocol
> version supported by the server ({03,yy}, say), then the best the
> server can do is try its highest protocol version, and send an
> according Server Hello message.  Either this will work since the
> client does support {03,yy}, too; or otherwise the protocol mismatch
> is unavoidable, and will be detected by the client.

Yes; and also it's quite likely that the format of ClientHello will
remain backwards-compatible in future versions of TLS, since
otherwise we'd lose the ability to gracefully negotiate older
versions. 
> 
> So if a TLS 1.0 or TLS 1.1 server receives a Client Hello contained in
> a record of protocol version number {03,2A} or whatever, it should
> just try to parse this in its own native format, and negotiate the
> protocol version accordingly.  Things can't get worse than triggering
> a protocol_version alert from the client, and this is not very likely
> to happen.  (If the *major* protocol version number is unknown, such
> as {04,00}, then it certainly makes sense to abort the handshake
> immediately.)

The TLS specification does not actually say what meaning the "major"
and "minor" version numbers have. But your intepretation -- that an
implementation should attempt to parse ClientHellos with the same
major version it supports, but not with different major versions --
certainly sounds reasonable. 

<snip>

> > Given that Yngve's interoperability draft suggests that some
> > servers incorrectly use the record layer version number for
> > negotiation, I think the safest clarification would be to 
> > say that the two version numbers must be equal.
> 
> The experiment that we'd really have to run is to test various servers
> out there with Client Hello messages where the record protocol version
> and the Client Hello protocol version differ, to see what protocol
> version the servers will negotiate:
> 
> - Send a Client Hello with a client_version of {03,2A} (say) in a
>   record with version {03,00} and see if the server picks SSL 3.0
>   ({03,00}) or some version of TLS.
> 
> - Then, unless the server picked the highest protocol number defined
>   at this time, try again using a uniform-version Client Hello naming
>   a protocol version higher than the one from the first experiment.
>   (E.g., if the server picked SSL 3.0 in the first test, check if it
>   does support TLS 1.0 after all.)
> 
> - Finally, send a Client Hello with both version field set to
>   {03,2A} (say) to see if the server handles unknown protocol versions
>   properly and gracefully falls back to an existing protocol version.

I've been working on a testing tool what would allow running tests
exactly like this. It's not quite finished yet, but some preliminary
data points:

- OpenSSL 0.9.8: 
  - With ClientHello version {03,01}, succesfully negotiates TLS1.0 as
    long as the record version is {03,something}. Closes connection
    if record version is not {03,something}.
- GnuTLS 1.0.20:
  - With ClientHello version {03,01}, succesfully negotiates TLS1.0
    no matter what the record version is (i.e., record version seems
    to be ignored)

More data will come once I get SSL3 and TLS1.1 handshakes implemented,
and get time to set up more servers for testing...

Best regards,
Pasi

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