[Date Prev][Date Next]
RE: Session Resumption problems with JSSE-OpenLDAP
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Allan Streib
> We are encountering what I believe is the "session resumption" problem
> that has been described on this thread. I notice that there is an ITS
> entry (1895) which is closed with the comment that it is a bug in
> Sun's JSSE and the workaround referenced is to use the JSSE from IBM's
This thread has been around for a while, and it's not clear what versions of
all the relevant software are being used in each case.
> We are finding that IBM's JSSE does not resolve the problem. We have
> noted that the problem (hanging SSL connections) does not seem to
> occur when the slapd (2.0.21) server loads the OpenSSL 0.9.6c libs,
> but it does occur with any later version of OpenSSL. Has anyone else
> experienced this and if so do you know why this is?
In my own testing I found that SSL session resumption using OpenSSL 0.9.6d
worked fine with (a modified) ldapsearch and (unmodified) slapd. When I
upgraded to OpenSSL 0.9.6g it failed with an error code but I never saw a
hang. The failure was because libldap never initialized OpenSSL's session ID
context; this seemed to work fine with a NULL context in OpenSSL 0.9.6d. A
patch has been applied to libldap/tls.c in CVS to set the session ID. This
patch will be in OpenLDAP 2.1.5.
> Evidently (from reading other posts on this thread) this problem is
> not fixed in Sun's jdk 1.4. I'm not well versed in the details of how
> SSL/TLS works, so can anyone clarify the nature of the "bug" in JSSE?
> >From Kurt's comment above, it sounds like SSL/TLS session resumption
> is not supported in slapd. Is the problem then that JSSE is trying to
> resume the session but not correctly detecting that the session was
I try to touch Java as little as possible, but just for curiosity's sake I
fired up my copy of Jarek Gawor's ldapbrowser 2.8.2 again, with Sun's
Java2SDK1.4.0 on my Windows box. After it told me my CA cert was
unrecognized, it connected fine using ldaps://. I then disconnected and
reconnected without any problems. Watching the slapd debug log I can see that
it's resuming the session as there is no exchange of client or server
certificates on the reconnect.
> Even if this is Sun's bug, since they have not fixed it is there a
> workaround on the server side? I don't really want to say "sorry, you
> can't do SSL" to Java clients, particularly since that is the primary
> enterprise development environment used here. Staying with OpenSSL
> 0.9.6c is not an option for security reasons.
At this point I don't see any bug of the nature being discussed in this
thread. No hangs, anyway. When slapd failed to accept a connection due to the
uninitialized session ID context, it simply aborted and closed the socket and
both client and server proceeded with no noticable delay. Now that libldap is
initializing things, I've encountered no problems at all.
> Another question regarding Kurt't comment about abrupt session closure
> -- we have been attempting to pool SSL LDAP connections on the client
> side. Does this "abrupt closure" behavior mean that this is not a
> good idea, and that each client process/thread should open, use, and
> close its own connection to slapd?
Pooling SSL connections sounds like a good idea to me. The handshake overhead
is ridiculous otherwise, especially when you only have one-shot queries being
issued on each connection.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support