Hi Dave,
----- Original Message -----
> > [ ... ]
> For the NSS/NSPR/SSL layers, I think that the main complication, for
> servers, is that, at the time a socket is created for accepting a
> connection, it isn't known whether that socket will need to be secure.
Yep.
> However, it may end up being just an extra step in the connection
> process at the end of the day. We already have connections which are
> upgradable from insecure to secure from a protocol point of view. It
> could be as easy as upgrading a native socket to NSPR before doing that.
>
> The API
>
> https://developer.mozilla.org/en-US/docs/PR_ImportTCPSocket
>
> seems to be available for this purpose, although there are some caveats
> expressed there. Despite those caveats, they (Mozilla) seem to be
> promoting the use of this function.
Sounds worth a closer look. The other bonus there is both code paths
get more exercised (instead of a build time choice excluding one).
> If we were to go this route, then the native socket handle and APIs
> would be used for sockets on both the client and server side under
> normal circumstances. When an operation requiring a secure socket is
> attempted, then libpcp could automatically import the handle into NSPR.
> I believe that this could be done automagically without the knowledge of
> the caller by simply adding the NSPR bits to the handle's entry in the
> IPC table. The caller would continue to use the same handle, but the
> operations would be automatically mapped to NSPR calls. I can see this
> potentially eliminating the current native/NSPR division in the IPC table.
*nod* ... it also paves the way for alternate SSL implementations to
be optionally plugged in (ISTR some people expressing reservations re
use of NSS way back now - but tis a vague memory at this point).
>
> The dynamic loading NSPR/NSS/SSL libraries would be done the first time
> they are needed, if ever.
>
*nod*, sounds good in theory. ;)
> I just had the thought that, unless we get into the game of unloading
> these libraries when no longer in use (i.e. dlcose(3)), then after the
> first secure connection is made, the RSS will be permanently increased
> anyway.
That's OK, the typical case is the one to optimise for - i.e. "no secure
connections requested, ever". Definitely we need to look more into the
root cause of the blowout as Frank suggested (though from a quick hopeful
peek, that NSS space optimise flag appears to get set by default for the
API calls we're making - both client & server cases).
I'll keep digging & send out some more details.
cheers.
--
Nathan
|