On Fri, Oct 07, 2005 at 11:17:47AM +0200, Peter Sylvester wrote:
> In s23_srvr.c there is a length test
>
> if ((csl+sil+cl+11) != s->packet_length)
> {
> SSLerr(SSL_F_GET_CLIENT_HELLO,SSL_R_RECORD_LENGTH_MISMATCH)
>
> in case that the record contains a SSLV3 or TLSv1 header.
> IMO the != should be a > since tls allows additional
> data in extensions.
This length test occurs in the branch of ssl23_get_client_hello() that
is responsible for parsing a Client Hello sent in SSL 2.0 backwards
compatible format (where s23_srvr.c has to translate from SSL 2.0 into
SSL 3.0/TLS 1.0 format so that s3_srvr.c can continue processing the
handshake). Backwards compatible Client Hello messages can't include
additional data because this would confuse SSL 2.0 servers, they
strictly follow the format
char MSG-CLIENT-HELLO
char CLIENT-VERSION-MSB
char CLIENT-VERSION-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char SESSION-ID-LENGTH-MSB
char SESSION-ID-LENGTH-LSB
char CHALLENGE-LENGTH-MSB
char CHALLENGE-LENGTH-LSB
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
char SESSION-ID-DATA[(MSB<<8)|LSB]
char CHALLENGE-DATA[(MSB<<8)|LSB]
after the two-byte record header. I.e., a client that connects to a
server can *either* support SSL 2.0 servers *or* use TLS extensions,
but not both.
The SSL 3.0 and TLS 1.0 specifications have the forward compatibility
note about extra data at the end of the Client Hello, so s23_srvr.c
should tolerate always extra data in a Client Hello that does not use
the SSL 2.0 format.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
