<<
Currently OpenSSL always uses the values in client hello and server
hello to negotiate compression even for a resumed session. So provided
the client includes the compression method from the original method in
client hello (as required by standards) the server should end up using
compression again.
>>
Interesting; that's not what I'm seeing with the version of OpenSSL I'm testing
with: 'OpenSSL 0.9.8h 28 May 2008'. The system seems to be using the
compression type that is provided by the session returned from the user defined
session cache, not what was negotiated during client hello/server hello.
Not sure if the resumed session should be using the newly negotiated
compression algorithm regardless. RFC 3749 has the following clause:
<<
1. The compression algorithm MUST be retained when resuming a
session.
2. The compression state/history MUST be cleared when resuming a
session.
>>
So in the case where, for whatever reason, the cilent and server negotiate a
different compression type, it appears that the connection should revert to the
original comp type RE: RFC 3749.
Regards,
Sean
Sean Cunningham
MANDIANT
Software Engineer
675 North Washington Street
Suite 210
Alexandria, VA 22314
703.683.3141 t
703.683.2891 f
sean.cunning...@mandiant.com
www.mandiant.com
________________________________________
From: Stephen Henson via RT [...@openssl.org]
Sent: Sunday, June 28, 2009 6:31 PM
To: Sean Cunningham
Cc: openssl-dev@openssl.org
Subject: [openssl.org #1960] i2d_SSL_SESSION/d2i_SSL_SESSION does not persist
session compress_meth
> [sean.cunning...@mandiant.com - Thu Jun 25 08:23:49 2009]:
>
>
> This bug is not platform specific.
>
> Some proxies, such as nginx, implement custom session caches via the
> openssl callback API's. This implementation makes use of the
> i2d_SSL_SESSION API to copy the session into a contiguous block of
> memory. When the next session matches, the cache calls
> d2i_SSL_SESSION to transform the block of memory back into a
> session object, which it then returns to OpenSSL. However, the
> session's compress_meth is not persisted i2d_SSL_SESSION, so if the
> compress_meth is non-zero, it is not properly restored. The SSL
> connection then fails with a 'error:1408F06B:SSL
> routines:SSL3_GET_RECORD:bad decompression' on the client side.
>
While I agree that OpenSSL doesn't include the compression method in
SSL_SESSION, I'm trying to see how this could happen in practice.
Currently OpenSSL always uses the values in client hello and server
hello to negotiate compression even for a resumed session. So provided
the client includes the compression method from the original method in
client hello (as required by standards) the server should end up using
compression again.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
