300045 - SSL client cache only works within a process

Status: NEW

(NSS :: Libraries, enhancement, P3)

Description

[Julien Pierre]

In a multi-process client application, NSS maintains separate client caches for
each process. Thus, the performance will be lower, and many more full handshakes
will occur than necessary, because new SSL connections made in one process will
not be able to reuse SSL sessions created with the same host in another process .

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Absurd.  What real-world scenario does this simulate?
If you're trying to do exclusive restart testing with multiple processes,
each process need do only one full handshake at the beginning.
The proposal would be a lot of work for no real payback that I can see.

Comment 2

[Julien Pierre]

Nelson,

A sample real-world scenario would be users of mozilla clients (Firefox,
Thunderbird, etc.) which now have a multi-process architecture, and thus no
longer benefit from the SSL session cache as much as when they were in a
single-process Mozilla suite process. They will cause unnecessary extra load on
servers which would not have happened with the mozilla suite, as well as some
degradation on the client side too.

I'm aware that implementing this RFE is a lot of work, and I agree that it
should be fairly low priority, but it was in no way absurd.

Comment 3

[Robert Relyea]

The likelihood of Firefox and Thunderbird accessing the same servers is fairly
low, certainly not high enough to have a real impact on the servers they are
using. If you are using authenticated access, then making the cache both
functional and secure becomes even more of an issue.

bob

Comment 4

[Wan-Teh Chang]

I agree that this RFE should be resolved WONTFIX.

A similar RFE would be to make the SSL client session
ID cache persistent so I can resume SSL sessions
established in a previous browser session.

We can brainstorm and come up with other related ideas,
but given that there are so many important tasks on our
plate now, it's wise to not let these things distract us.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Julien, If this bug is to remain open, there must be some concrete example
of a protocol that is implemented in multiple NSS clients that would share
a common NSS "token" (set of private keys), such that they could logically
share a client session cache, and that is used enough in more than one of 
those clients that the saving are worth the effort.  

Can you name such a protocol?  

It seems to me that the FF and TB products implement complementary protocol 
sets.  FF doesn't implement mail/news protocols, and TB doesn't do much 
secure web browsing.  Where's the high volume protocol case that benefits 
from this proposal? 

Comment 6

[Julien Pierre]

I believe currently the main protocol that is shared between Firefox and TB is
HTTPS . HTTPS is used by TB for rendering remote images in email documents.
These documents are likely to contain remote images living on the same HTTPS
sites that the user visits in Firefox, thus causing separate SSL sessions to be
created that would normally be shared in a single process Mozilla suite application.

There is now a separate calendar client (Sunbird?) which may use LDAPS. TB
currently can use LDAPS for recipients lookup. I'm not sure if Firefox ever uses
LDAPS currently.

libpkix will soon support the use of LDAP, and possibly LDAPS too, for looking
up CRLs and certs, so any application doing a cert verification could end up
doing LDAPS. This will need to be configured by the application, though, either
by configuring a fixed LDAPS server, or by using the content of AIA/SIA
extension to get LDAPS URLs . It may not be turned on by default.

OCSP can be run over SSL . NSS only currently supports it on plaintext
connections, but libpkix may also change this. Again, this would apply to cert
verifications in any of the client apps.

Regarding the question of volume, fixing this bug will prevent 
1 or 2 full handshakes (based on TB/FF or TB/FF/SB . This could increase if more
mozilla products come out)
* the average number of servers accessed by several of these processes
* the number of users of all those applications.

The main variable that will get very large is the number of users of the
applications. Next is the number of servers that are accessed by multiple
applications. Lastly, the number of application processes is not likely to grow
very large.

It doesn't matter very much if the protocol is high traffic per user once the
connection is established in a process, since the SSL session can remain valid
for a while (24 hours typically). What matters most is if the same SSL servers
are likely to be visited by the more than one application. Whether high traffic
happens within each process on the same server after the session(s) is/are
established is not relevant.