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 f8cf1c75cb694744ab6ef5c9a7eb2b53b4c5a540.camel@vmware.com
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Support for NSS as a libpq TLS backend
List pgsql-hackers
On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > Speaking of IP addresses in SANs, it doesn't look like our OpenSSL
> > backend can handle those. That's a separate conversation, but I might
> > take a look at a patch for next commitfest.
> 
> Please do.

Didn't get around to it for November, but I'm putting the finishing
touches on that now.

While I was looking at the new SAN code (in fe-secure-nss.c,
pgtls_verify_peer_name_matches_certificate_guts()), I noticed that code
coverage never seemed to touch a good chunk of it:

> +        for (cn = san_list; cn != san_list; cn = CERT_GetNextGeneralName(cn))
> +        {
> +            char       *alt_name;
> +            int         rv;
> +            char        tmp[512];

That loop can never execute. But I wonder if all of that extra SAN code
should be removed anyway? There's this comment above it:

> +    /*
> +     * CERT_VerifyCertName will internally perform RFC 2818 SubjectAltName
> +     * verification.
> +     */

and it seems like SAN verification is working in my testing, despite
the dead loop.

--Jacob

pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: pg_replslotdata - a tool for displaying replication slot information
Next
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Don't block HOT update by BRIN index