<<
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.000000000 +0000
+++ ./ssl/ssl_sess.c 2009-06-30 15:50:24.000000000 +0000
@@ -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(00000003)
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
