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

[Bodo Moeller <[e-mail]>]

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.  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.

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.

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.

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.)


>   - When configured in "TLS10 only" mode, sends {03,01} in both fields
> - Mozilla Firefox 1.5
>   - Seems to send V2 ClientHello no matter what the settings??
> - MS Internet Explorer 6.0
>   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
>     sends V3 ClientHello with {03,01} in both fields
> - SunJSSE (JDK 1.4.2)
>   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
>     sends V3 ClientHello with {03,01} in both fields
> - GnuTLS (10.0.20)
>   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
>     sends V3 ClientHello with {03,01} in both fields
>   - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode,
>     sends V3 ClientHello with {03,02} in both fields
> 
> In other words: All these implementation seem to follow the
> rule that TLSPlaintext.version==ClientHello.client_version, or
> use V2 ClientHellos...
> 
> 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.


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