I didn't use the code below verbatim, as I already had my own, but I've
finally tracked down why I wasn't getting the performance/session reuse
I expected, and I think the same bug is in this example code (which is
otherwise very clear and useful). So I'm posting a fix in case anyone
does use this as a reference, and also to check that it is correct.
All that is wrong is that you must call SSL_shutdown(ssl) before calling
SSL_free. Otherwise the session is invalidated by the SSL_free call.
This may be obvious if you're controlling memory yourself. It drove me
nuts because SSL_free was being called when the Java GC cleaned up Java
objects that shadowed C objects. Since these persisted for random times
before GC, I was getting sporadic session re-use....
Phew!
Andrew
PS There's a performance hack in s_server that suggests SSL_shutdown may
be slow.
Geoff Thorpe wrote:
> On Thu, 24 Feb 2000, Andrew Cooke wrote:
[...]
> > Looking at the code, it seems that SSL_free only deletes the session if
> > the reference count is zero. So can I keep an SSL_SESSION simply by
> > incrementing the reference count and saving a pointer? Obviously this
> > won't work if the program exits, but would (should) it still work after
> > all connections with the client had been closed?
[...]
> The technique I prefer;
>
> SSL_SESSION *to_resume = NULL;
> app_start:
> /* <insert code> ... Get the SSL structure ready to connect */
> if(to_resume)
> SSL_set_session(ssl, to_resume);
> /* <insert code> ... Connect */
> if( /* handshake complete */ )
> {
> /* <insert code> ... Grab peer certificate and other details */
> /* Choose the just-agreed session for resuming next time */
> if(to_resume)
> SSL_SESSION_free(to_resume);
> to_resume = SSL_get1_session(ssl);
> }
> /* <insert code> ... Use the SSL */
SSL_shutdown(ssl) ; /* Need this, I think */
> SSL_free(ssl);
> if( /* want to keep going */ )
> goto app_start;
> if(to_resume)
> SSL_SESSION_free(to_resume);
>
> That psuedo-code hopefully illustrates the picture. The alternative is to
> just use SSL_get_session (equivalent to SSL_get0_session) and serialise
> the session to an ASN encoded blob. This (obviously) doesn't involve any
> reference counts, and when it comes time to try and resume the session
> (using SSL_set_session) you can deserialise the ASN blob into a new
> SSL_SESSION, set the SSL's session to it, and free the SSL_SESSION you
> just created (which won't deallocate it, but leave the SSL with the only
> remaining reference). This is exactly how SSL session caches work on
> servers, except that they index the sessions in the cache so that they can
> do lookups when a client requests a resume. NB: I haven't tried this
> myself, but in theory it should be fine. This uses i2d_SSL_SESSION and
> d2i_SSL_SESSION (i=internal, d=DER - which gives your ASN1 blob).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
