[Date Prev][Date Next] [Chronological] [Thread] [Top]

SSL sessions

So after reading up on this a bit more, it looks like caching sessions at the
client side isn't so tough. You need a method for matching sessions to
connections, of course. OpenSSL's internal session cache hangs off the
SSL_CTX. Generally there's only the single tls_def_ctx in libldap to worry
about (although someone could always create their own if they wanted to) and
it hangs around until explicitly destroyed by ldap_pvt_tls_destroy().

There are functions to attach arbitrary app data to many of the OpenSSL data
structures. Probably the easiest start would be to hang a linked list of
{socket address,session} pairs off the SSL_CTX. (Socket address for IP would
consist of the IP address and port #.) We'd need two LDAP_OPT_X_TLS_ options
for this:

The first one to enable client session caching - take the address of an int
as an argument. Pass an int of 1 to enable, 0 to disable caching. On enable,
the argument value will be overwritten with the index key used to identify
the app-specific data. (I.e., the return value of
SSL_CTX_get_ex_new_index().)

When enabled, libldap will handle the session cache transparently - it will
search and/or add to the list of {address,session} pairs whenever it creates
a new connection.

The second option is to pass back in the SSL_CTX index key. Since the SSL
session cache lives longer than an LDAP session handle, libldap can't
remember the index key between unbinds, it's up to the application to save it
and pass it back in when creating a new LDAP session.

A setup like this would be immediately usable by something like back-ldap, or
some other long-lived LDAP client. For frequent-use short-lived clients like
pam_ldap or nss_ldap we'd need something more; the SSL internal session cache
only lives as long as the invoking process. An approach here would be to use
an external session cache instead, perhaps a SysV shared memory segment.

Or we could avoid the issue by recommending that pam_ldap/nss_ldap/et.al.
always talk to a local slapd via ldapi:// and use back-ldap to proxy the SSL
sessions to where they need to go. I like this idea a lot more because it
means you can also use client certificates for mutual authentication without
having to make your private key world-readable, it only needs to be
accessible to the proxy.

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