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

From Jacob Champion
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id ca450cb8a74de3dcc753386f57a5f1d5221d6916.camel@vmware.com
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
Responses Re: Support for NSS as a libpq TLS backend  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, 2021-02-02 at 00:55 +0000, Jacob Champion wrote:
> On Mon, 2021-02-01 at 21:49 +0100, Daniel Gustafsson wrote:
> > > Embedded NULLs are now handled in a similar manner to the OpenSSL side,
> > > though because this failure happens during the certificate
> > > authentication callback, it results in a TLS alert rather than simply
> > > closing the connection.
> > 
> > But returning SECFailure from the cert callback force NSS to terminate the
> > connection immediately doesn't it?
> 
> IIRC NSS will send the alert first, whereas our OpenSSL implementation
> will complete the handshake and then drop the connection. I'll rebuild
> with the latest and confirm.

I wasn't able to reproduce the behavior I thought I saw before. In any
case I think the current NSS implementation for embedded NULLs will
work correctly.

> > Attached is a v24 which is
> > rebased on top of todays --with-ssl commit, and now includes your changes.

I have a v25 attached which fixes and re-enables the skipped/todo'd
client certificate and SCRAM tests. (Changes between v24 and v25 are in
since-v24.diff.) The server-cn-only database didn't have the root CA
installed to be able to verify client certificates, so I've added it.

Note that this changes the error message printed during the invalid-
root tests, because NSS is now sending the root of the chain. So the
server's issuer is considered untrusted rather than unrecognized.

--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Custom compression methods