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

Reply via email to