> 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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
