51468 - Stan: Support for multiple client caches

Status: RESOLVED WORKSFORME

(NSS :: Libraries, enhancement, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

The following request for enhancement was originally bugsplat bug
396234 filed by [e-mail] on 2000-5-30.

Currently, for a client application, NSS keeps a process-wide SSL session 
cache.  The SSL session is reused if it is a connection to the same server 
in the same process.

This works transparently in some client applications, but it is a 
limitation for our multi-threaded SSL test program for NES, httptest, 
which tests the server using client authentication and multiple threads.
Each thread is running a different test, possibly with a different 
certificate.  If the session cache is enabled, then the threads start 
reusing connections from previous tests, which were not initiated with 
the same client certificate presented. This causes the tests to fail.

For now, the workaround has been to forcibly disable the session cache 
for all client cert connections in our tests. Only the normal SSL tests - 
which may run in parallel in other threads within the same process - can 
have sockets with session reuse.

It would be very desirable to be able to test client certs with session 
reuse, given that we have major customers that rely on client certs.
Accomplishing this would require some enhanced support within NSS.

Some possibilities :
1) new calls to explicitly save/restore the session . This would allow 
the session cache to be bypassed.
2) ability to partition the cache into several independent compartments. 
The client program would then be able to use different cache compartments 
for each client auth test than for the rest of the tests.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Change target fix version for all "stan" RFEs to "Future".

Comment 2

[Julien Pierre]

Nelson,

This is the enhancement request I was talking about today in the meeting with
the Sun folks.

Basically we would need a call to save the session information from a
PRFileDesc* on the client side. Then, upon creating a new socket and importing
it to SSL, we would need a way to restore the session into that socket, without
forcing a new handshake. That would take care of the problem of creating a
multithreaded SSL client having different identities.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

This RFE requests multiple client caches.
In today's meeting, as I understood it, you asked for the ability 
for an SSL client application to request that a specific SSL session
(that should already be in the cache) be reused, instead of the latest
one (which is what is normally used.  That request could be implemented
with FAR less work than muliple client caches. 

Comment 4

[Julien Pierre]

Nelson,

If you reread the original bug, notably the end of it, possibility 1) is exactly
what was being requested in the meeting today.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

The session cache doesn't need to be bypassed.
A function already exists to get the session id of the session 
currently associated with an SSL socket.  SSL_GetSessionID().
What's needed is a way to pass that session ID back in and say
"use this one, please"

Comment 6

[Julien Pierre]

Nelson,

What I meant by "bypassing the session cache" was from the client perspective.
The client cache currently reuses SSL sessions automatically based on the
hostname:port of the server it's connecting to. That's the process in the cache
that needs to be bypassed, so that the application developer can decide which
session gets reused as opposed to it happening automatically.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

This capability already exists in NSS, and has for many years.  
The function SSL_SetPeerID allows the caller to specify a string that 
identifies a separate session cache name.  The feature was originally
envisioned for use in separating caches for different servers when 
multiple servers appear behind a firewall.  For that purpose, the
string often consists of a server hostname and port number.  But the
string can be any string value.  It is possible to use a local user 
identity name as that string, or to use a combination of local user 
identity and remote server hostname and port number.  

This string is used by libSSL in two ways:
1. When a new SSL session is cached, it is cached with that string, and 
2. When looking for a pre-existing SSL session in the cache, we only 
examine entries whose strings match the string currently set in the 
SSL socket by the call to SSL_SetPeerID.  

So, each unique string value essentially becomes a separate client 
session cache.  This feature is already present and tested in NSS 3.x.

Marking WorksForMe.

Comment 8

[Julien Pierre]

Thanks. This will allow httptest to reuse sessions.