[openssl.org #1960] i2d_SSL_SESSION/d2i_SSL_SESSION does not persist session compress_meth
[sean.cunning...@mandiant.com - Tue Jun 30 02:22:28 2009]: 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. Can you find a way to reproduce this behaviour with s_client/s_server or does it only happen with external session caches? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #1960] i2d_SSL_SESSION/d2i_SSL_SESSION does not persist session compress_meth
Can you find a way to reproduce this behaviour with s_client/s_server or does it only happen with external session caches? I took a look at s_server. It uses openssl's default session cache, which does not flatten the session objects with i2d_SSL_SESSION/d2i_SSL_SESSION. The default cache just ref counts the session object and keeps it in memory, so the compression method within that object is retained when subsequent sessions pull the object out of the cache. You can emulate the problem by hacking the session cache code. Try the following: # add the following patch to the source for openssl-0.9.8k: diff ./ssl/ssl_sess.c.orig ./ssl/ssl_sess.c -U 2 --- ./ssl/ssl_sess.c.orig 2009-06-30 14:41:28.0 + +++ ./ssl/ssl_sess.c2009-06-30 15:50:24.0 + @@ -453,4 +453,13 @@ if (s-session != NULL) SSL_SESSION_free(s-session); + // demonstrate Bug #1960; flatten then reload and return (yes it leaks) +int xlen = i2d_SSL_SESSION(ret, NULL); +unsigned char* xbuf = (unsigned char*)malloc(xlen); +unsigned char* p = xbuf; +i2d_SSL_SESSION(ret, p); +p = xbuf; +SSL_SESSION *xret = d2i_SSL_SESSION(NULL, p, xlen); +free(xbuf); +ret-compress_meth = xret-compress_meth; s-session=ret; s-verify_result = s-session-verify_result; # rebuild opensssl cd openssl-0.9.8k ./config zlib make clean; make # create a cert ./apps/openssl req \ -x509 -nodes -days 365 \ -subj '/C=US/ST=VIRGINIA/L=Alexandria/CN=www.testy.com' \ -newkey rsa:1024 -keyout /tmp/mycert.pem -out /tmp/mycert.pem # start the server ./apps/openssl s_server -cert /tmp/mycert.pem -www -context testy # start the client ./apps/openssl s_client -cert /tmp/mycert.pem -reconnect -ssl3 When running the above the result will be an error that looks like: CONNECTED(0003) 9806:error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression:s3_pkt.c:438: 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: Tuesday, June 30, 2009 7:05 AM 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 - Tue Jun 30 02:22:28 2009]: 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. Can you find a way to reproduce this behaviour with s_client/s_server or does it only happen with external session caches? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1960] i2d_SSL_SESSION/d2i_SSL_SESSION does not persist session compress_meth
[sean.cunning...@mandiant.com - Tue Jun 30 17:06:26 2009]: Can you find a way to reproduce this behaviour with s_client/s_server or does it only happen with external session caches? I took a look at s_server. It uses openssl's default session cache, which does not flatten the session objects with i2d_SSL_SESSION/d2i_SSL_SESSION. The default cache just ref counts the session object and keeps it in memory, so the compression method within that object is retained when subsequent sessions pull the object out of the cache. You can emulate the problem by hacking the session cache code. Try the following: [snip] Interesting, the problem doesn't appear during session resumption over a new connection, it only seems to happen when a session is renegotiated. Which was why I couldn't reproduce it using -sess_out and -sess_in . I've committed a fix for this now, let me know of any issues. Thanks for the report. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #1960] i2d_SSL_SESSION/d2i_SSL_SESSION does not persist session compress_meth
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
[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
