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

<Pasi.Eronen@nokia.com> Wed, 05 July 2006 11:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5MF-0005ZX-7B; Wed, 05 Jul 2006 07:15:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5ME-0005WR-6E for tls@ietf.org; Wed, 05 Jul 2006 07:15:50 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5MD-0002X5-Js for tls@ietf.org; Wed, 05 Jul 2006 07:15:50 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65BFita009825; Wed, 5 Jul 2006 14:15:45 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:15:38 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:15:38 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Date: Wed, 5 Jul 2006 14:15:37 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402DDC53F@esebe105.NOE.Nokia.com>
In-Reply-To: <20060704094106.GA22002@iota.site>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Thread-Index: AcafTlF4iji2uzmBQgWFMr/FjKjq0wA0YzQQ
From: <Pasi.Eronen@nokia.com>
To: <bmoeller@acm.org>
X-OriginalArrivalTime: 05 Jul 2006 11:15:38.0296 (UTC) FILETIME=[580A1380:01C6A024]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls