So I would have to recompile the OpenSSL and link against "my" version. Would it be possible in a future version to make SSL3_RT_MAX_EXTRA a runtime-settable parameter? As it's now it's a constant, but it's used only dynamically (no static buffer is allocated through it).
________________________________ From: Stephen Henson via RT <r...@openssl.org> To: xana...@geocities.com Cc: openssl-dev@openssl.org Sent: Friday, February 10, 2012 3:10 PM Subject: [openssl.org #2715] Interoperability of SSL communication on Windows XP between .NET and OpenSSL 1.0.0e > [xana...@geocities.com - Fri Feb 10 10:54:26 2012]: > > I'm writing an OpenSSL client program. It must interoperate with some > .NET code that uses the SslStream classes. The .NET code is > correct. If I create a .NET client it connects correctly. If I run > the .NET server on Windows 7 it works correctly (with .NET client > and with C plus OpenSSL client). If I run the .NET server code on > Windows XP only the .NET client code works correctly. The OpenSSL > code doesn't work. It returns > > 5760:error:1408F0C6:SSL > routines:SSL3_GET_RECORD:packet length too long:.\ssl\s3_pkt.c:357 > > I've read this request > http://comments.gmane.org/gmane.comp.encryption.openssl.user/28201 > but the solution doesn't solve my problem (the suggestion is to use > the SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER option) > > > read from 0xa73e98 [0xa79648] (7 bytes => 7 (0x7)) > 0000 - 16 03 01 86 f4 02 ...... > 0007 - <SPACES/NULS> Translating the above. Handshake protocol, TLS 1.0 and length of 0x86f4 whereas RFC2246 states a maximum of 2^14 == 0x4000. The big buffer workaround adds another 0x4000 but that still isn't enough. The server is fairly clearly violating the specs here. You could try upping the value of SSL3_RT_MAX_EXTRA and also using the big buffer flag to see if that helps. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org
