485690 - LDAP SSL connections with clientauth sometimes use wrong credentials

Assignee

Description

•

15 years ago

Attached patch Patch v1 for LDAP C SDK (obsolete) — Details — Splinter Review

This problem is seen in client programs that use SSL clientauth and that
use different credentials (client certificates) on different connections
to the same server during the same process lifetime. It is also seen in
programs that use clientauth on some connections to a server, but not on
other connections to the same server during the same process lifetime.

This is seen most commonly is test clients that are trying to simulate
different users, but it may also be seen in servers that are trying to
replicate different data sets to a remote server with a different client
credential for each different data set.

The problem is that after one connection has been established between
the client and the server using some (or no) credential, all subsequent
connections to the same server may use the same credential (or same absent
credential) even if the client has called ldapssl_enable_clientauth
specifying different credentials to be used for each subsequent connection.

Here is an explanation. SSL remembers ("caches") information about
previously established sessions with "remote" clients and servers, and
reuses that information from old sessions whenever possible to minimize the
expensive computational overhead of establishing new sessions with each new
connection. When a new connection is made, if the server says "Let's reuse
the session we last used", then the most recent session from that socket's
cache will be used, even if that previous session was established using
different credentials than the client now wishes to use.

NSS's SSL client library supports the use of multiple separate named caches,
to allow the sessions associated with one set of credentials to be remembered
separately from the sessions associated with other sets of credentials.
So a client program that uses credentials for "Alice" with some sockets, and
uses credentials for "Bob" with other sockets, can have separate caches for Alice and Bob. If the connections for Alice are configured to use Alice's
cache, and Bob's connections use Bob's cache, all confusion over different
credentials can be eliminated.

When a program (or thread) uses a socket for which it has not configured an explicitly named socket, then NSS uses a default unnamed cache for that
socket. There is only one default unnamed cache. If multiple threads,
trying to act as separate users, do not specify explicitly named caches for
their respective users' identities, then the separate users will end up
using a common set of credentials from the common cache, resulting in
confusion.

It may be reasonable for all LDAP connections that do NOT use client auth
to share a common cache, because each connections that uses no client auth
typically is (re)authenticated using some other method, such as simple name
and password authentication. But it is not reasonable for client auth
connections to share a cache with connections that use no client auth.

That is the problem experienced with the LDAP C SDK. The LDAP C SDK never
explicitly names a cache to be used with any SSL socket, so all SSL sockets
share the common unnamed cache, with the resulting identity confusion.

A named cache is implicitly created the first time its name is configured
to be used by a socket. Cache entries have a lifetime after which they
expire. When all the cache entries for a named cache have expired, the
cache disappears. So, it's very easy to use named caches. You just give
the name to the SSL socket before doing the first handshake on that socket,
and SSL does the rest.

I have attempted to modify the LDAP C SDK to do that, to configure each
SSL socket that will be used with a client certificate to use a cache with
the same name as the "nickname" of the cert to be used. I have attached
to this bug an untested patch that I believe will solve the problem.

I would like one of the LDAP C SDK cognoscenti (you know who you are :) to
test this patch and see if it does indeed satisfactorily solve the problem
for them.

Attachment #369808 - Flags: review?

Patch v1 for LDAP C SDK 15 years ago Nelson Bolyard (seldom reads bugmail) 2.09 KB, patch		Details \| Diff \| Splinter Review
alternative patch v1 15 years ago Nelson Bolyard (seldom reads bugmail) 2.09 KB, patch		Details \| Diff \| Splinter Review
Patch v2 for LDAP C SDK 15 years ago Nelson Bolyard (seldom reads bugmail) 1.88 KB, patch	mcs : review+	Details \| Diff \| Splinter Review
patch as committed to CVS trunk 15 years ago Nelson Bolyard (seldom reads bugmail) 2.10 KB, patch		Details \| Diff \| Splinter Review