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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]