On Sun, Apr 01, 2012 at 12:17:19PM +0200, Andy Polyakov wrote:
> > It's empirically found that SSL 2.0 and TLS 1.0
> > ClientHellos larger than 256 bytes *are* accepted, while TLS 1.1 and 1.2
> > have to be shorter to be accepted.
>
> TLS version in ClientHello *message* is denoted by corresponding field.
> But then the *message* is placed to TLS *record*, which is denoted with
> own protocol version. Quoting RFC5246, appendix E.1.
>
> Earlier versions of the TLS specification were not fully clear on
> what the record layer version number (TLSPlaintext.version) should
> contain when sending ClientHello (i.e., before it is known which
> version of the protocol will be employed). Thus, TLS servers
> compliant with this specification MUST accept any value {03,XX} as
> the record layer version number for ClientHello.
>
> TLS clients that wish to negotiate with older servers MAY send any
> value {03,XX} as the record layer version number. Typical values
> would be {03,00}, the lowest version number supported by the client,
> and the value of ClientHello.client_version. No single value will
> guarantee interoperability with all old servers, but this is a
> complex topic beyond the scope of this document.
>
> Yes, it's beyond document scope, but it seems that it's acceptable to
> send TLS 1.2 ClientHello *message* in TLS 1.0 *record*. I.e. initial
> record version would denote minimal TLS version, while message version -
> maximal version.
And they now both contain 0x03,0x03. At least gnutls is sending
0x03,0x00 with 0x03,0x03.
I already wondered about this before, but I assumed it didn't
matter.
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
