Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

On Wed, 2021-03-24 at 14:10 -0400, Stephen Frost wrote:
> * Jacob Champion (pchampion@vmware.com) wrote:
> > I could see this being a problem if two client certificate nicknames
> > collide across multiple in-use databases, maybe?
> 
> Right, in such a case either cert might get returned and it's possible
> that the "wrong" one is returned and therefore the connection would end
> up failing, assuming that they aren't actually the same and just happen
> to be in both.
> 
> Seems like we could use SECMOD_OpenUserDB() and then pass the result
> from that into PK11_ListCertsInSlot() and scan through the certs in just
> the specified database to find the one we're looking for if we really
> feel compelled to try and address this risk.  I've reached out to the
> NSS folks to see if they have any thoughts about the best way to address
> this.

Some additional findings (NSS 3.63), please correct me if I've made any mistakes:

The very first NSSInitContext created is special. If it contains a database, that database will be considered part of
the"internal" slot and its certificates can be referenced directly by nickname. If it doesn't have a database, the
internalslot has no certificates, and it will continue to have zero certificates until NSS is completely shut down and
reinitializedwith a new "first" context.
 

Databases that are opened *after* the first one are given their own separate slots. Any certificates that are part of
thosedatabases seemingly can't be referenced directly by nickname. They have to be prefixed by their token name -- a
namewhich you don't have if you used NSS_InitContext() to create the database. You have to use SECMOD_OpenUserDB()
instead.This explains some strange failures I was seeing in local testing, where the order of InitContext determined
whetherour client certificate selection succeeded or failed.
 

If you SECMOD_OpenUserDB() a database that is identical to the first (internal) database, NSS deduplicates for you and
justreturns the internal slot. Which seems like it's helpful, except you're not allowed to close that database, and you
haveto know not to close it by checking to see whether that slot is the "internal key slot". It appears to remain open
untilNSS is shut down entirely.
 
But if you open a database that is *not* the magic internal database,
and then open a duplicate of that one, NSS creates yet another new slot
for the duplicate. So SECMOD_OpenUserDB() may or may not be a resource
hog, depending on the global state of the process at the time libpq
opens its first connection. We won't be able to control what the parent
application will do before loading us up.

It also doesn't look like any of the SECMOD_* machinery that we're
looking at is thread-safe, but I'd really like to be wrong...

--Jacob