On Mar 30, 2010, at 3:04 PM, Adam Langley wrote:
On Tue, Mar 30, 2010 at 7:35 AM, Thomas Jarosch
<thomas.jaro...@intra2net.com> wrote:
28141:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad packet
length:s3_clnt.c:878:
openssl is compiled with the "no-tlsext" option. no-tlsext was
added back
in 2009 as openssl 0.9.8j had trouble connecting to a Centos 3
based server.
(http://marc.info/?l=openssl-dev&m=123192990505188)
openssl-0.9.8m is also affected. Any idea what might be going on?
A tcpdump would be very helpful.
Or just add the "-msg" option to the command line.
I can see what is happening, though: as of RFC 5746, disabling TLS
extensions isn't really tenable because you can't do secure
renegotiation without those, and can't even quite do a secure
*initial* negotiation because that requires at least sending the
pseudo-ciphersuite number 0x00 0xFF -- which to current servers is
equivalent to a TLS extension.
So client-side OpenSSL is buggy if compiled with no-tlsext (in 0.9.8m
and 0.9.8n) because it sends that pseudo-ciphersuite number without
being able to handle the TLS extension then expected in the server's
response. So the no-tlsext build shouldn't be sending the pseudo-
ciphersuite number. However, then you'd soon have problems connecting
to some updated servers, as these may start to *demand* confirmation
that clients are updated to support RFC 5746. So the fix won't help
you in the long run.
Bodo
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org