Re: Support for NSS as a libpq TLS backend

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Jacob Champion <pchampion(at)vmware(dot)com>
Cc: "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "andrew(dot)dunstan(at)2ndquadrant(dot)com" <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "thomas(dot)munro(at)gmail(dot)com" <thomas(dot)munro(at)gmail(dot)com>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>
Subject: Re: Support for NSS as a libpq TLS backend
Date: 2021-02-01 20:49:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 20 Jan 2021, at 18:07, Jacob Champion <pchampion(at)vmware(dot)com> wrote:

> To continue the Subject Common Name discussion [1] from a different
> part of the thread:
> Attached is a v23 version of the patchset that peels the raw Common
> Name out from a client cert's Subject. This allows the following cases
> that the OpenSSL implementation currently handles:
> - subjects that don't begin with a CN
> - subjects with quotable characters
> - subjects that have no CN at all

Nice, thanks for fixing this!

> 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?

> For easier review of just the parts I've changed, I've also attached a
> since-v22.diff, which is part of the 0001 patch.

I confused my dev trees and missed to include this in the v23 that I sent out
(which should've been v24), sorry about that. Attached is a v24 which is
rebased on top of todays --with-ssl commit, and now includes your changes.

Additionally I've added a shutdown callback such that we close the connection
immediately if NSS is shutting down from underneath us. I can't imagine a
scenario in which that's benign, so let's take whatever precautions we can.

I've also changed the NSS initialization in the cryptohash code to closer match
what the NSS documentation recommends for similar scenarios, but more on that
downthread where that's discussed.

Daniel Gustafsson

Attachment Content-Type Size
v24-0006-NSS-cryptohash-support.patch application/octet-stream 6.6 KB
v24-0005-NSS-contrib-modules.patch application/octet-stream 29.6 KB
v24-0004-NSS-Documentation.patch application/octet-stream 19.8 KB
v24-0003-NSS-pg_strong_random-support.patch application/octet-stream 3.1 KB
v24-0002-NSS-Testharness-updates.patch application/octet-stream 54.9 KB
v24-0001-NSS-Frontend-Backend-and-build-infrastructure.patch application/octet-stream 108.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-02-01 20:49:26 Re: Support for NSS as a libpq TLS backend
Previous Message Tom Lane 2021-02-01 20:23:48 Re: Should we make Bitmapsets a kind of Node?