RE: Session Resumption problems with JSSE-OpenLDAP

["Howard Chu" <hyc@symas.com>]

> -----Original Message-----
> From: Allan Streib [mailto:astreib@indiana.edu]

> 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.

Just to clarify the above, setting the session ID context is only needed on
the server side. The modification to ldapsearch that I alluded to above was
purely for testing purposes. libldap doesn't provide a mechanism for clients
to reuse SSL sessions, so I needed to hack something together to conduct the
test. The modifications are not relevant to this thread since JNDI/JSSE is
handling the client side in this discussion.
>
> That's helpful.  We're still using 2.0.2[13] 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).

If the behavior is actually dependent on the version of OpenSSL being used,
there may be a workaround. If you're using OpenSSL 0.9.6e or newer then try
adding a call to
	SSL_CTX_set_options(tls_def_ctx, SSL_OP_ALL);
in libldap/tls.c:ldap_pvt_tls_init_def_ctx() (after the call to SSL_CTX_new)
and see if the behavior changes at all. Note that this option turns on some
bug compatibility features and disables some security features, which might
make your life easier but will also make an attack easier as well. In
particular there was a countermeasure added in OpenSSL 0.9.6d that was not
present in 0.9.6c. The feature is always enabled  in 0.9.6d, and you need
0.9.6e or higher to be able to turn it off. See the OpenSSL man page for
SSL_CTX_set_options for details.

> > 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.

See slapd.conf(5), all the loglevels are spelled out there. Level 2 gives
packet logs, I usually test with level 7.

> > 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.

If security matters to you then you should look into whatever fix is in the
1.4.1 SDK and get more details on it. Turning on bug-compatibility modes in
OpenSSL only weakens your security; if it fixes the problem you may be OK in
the short-term but short-term workarounds have a tendency to become
permanent. If the 1.4.1 JDK fixes the problem, you should update as soon as
feasible.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support