On Wed, 18 Sep 2002, Howard Chu wrote:
> 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.
That's helpful. We're still using 2.0.2 but I will keep this in
mind. We are seeing the "hangs" described in earlier messages on this
thread with any OpenSSL other than 0.9.6c (actually have not tried
anything less than "b", to be precise).
> 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.
What loglevel shows the SSL exchanges? We generally don't have
problems connecting, disconnecting, and reconnecting. We do see the
hanging connection when we try to establish more than one connection
(e.g. creating the connection pool: the first connection is fine,
subsequent connections hang). I'm not actually developing the Java
side but that's what's being reported to me.
> At this point I don't see any bug of the nature being discussed in
> this thread. No hangs, anyway.
Earlier messages on this thread discussed both a JSSE bug and hanging
connections. I actually just heard last night from one of our Java
developers that the 1.4.1 SDK seems to have addressed this bug,
finally. We're not prepared to move to that immediately here, but
perhaps it bodes well for the long term.
The whole reason we're using SSL is to protect the password on simple
binds. We were never able to get SASL/GSSAPI working with the 1.3
SDK. That should be easier with 1.4 also, and we're experimenting
with that as well.