Message-ID: <370ea6d1-b500-113e-ef41-d4fa892a8a59@dunslane.net>
Date: Thu, 16 Dec 2021 10:50:28 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [PATCH] Accept IP addresses in server certificate SANs
Content-Language: en-US
To: Jacob Champion <pchampion@vmware.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <9f5f20974cd3a4091a788cf7f00ab663d5fcdffe.camel@vmware.com>
From: Andrew Dunstan <andrew@dunslane.net>
In-Reply-To: <9f5f20974cd3a4091a788cf7f00ab663d5fcdffe.camel@vmware.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/370ea6d1-b500-113e-ef41-d4fa892a8a59%40dunslane.net>
Precedence: bulk


On 12/15/21 20:13, Jacob Champion wrote:
> Hello all,
>
> libpq currently supports server certificates with a single IP address
> in the Common Name. It's fairly brittle; as far as I can tell, the
> single name you choose has to match the client's address exactly.
>
> Attached is a patch for libpq to support IP addresses in the server's
> Subject Alternative Names, which would allow admins to issue certs for
> multiple IP addresses, both IPv4 and IPv6, and mix them with
> alternative DNS hostnames. These addresses are compared bytewise
> instead of stringwise, so the client can contact the server via
> alternative spellings of the same IP address.


Good job, this is certainly going to be useful.


>
> This patch arose because I was writing tests for the NSS implementation
> that used a server cert with both DNS names and IP addresses, and then
> they failed when I ran those tests against the OpenSSL implementation.
> NSS supports this functionality natively. Anecdotally, I've heard from
> at least one client group who is utilizing IP-based certificates in
> their cloud deployments. It seems uncommon but still useful.
>
> There are two open questions I have; they're based on NSS
> implementation details that I did not port here:
>
> - NSS allows an IPv4 SAN to match an IPv6 mapping of that same address,
>   and vice-versa. I chose not to implement that behavior, figuring it
>   is easy enough for people to issue a certificate with both addresses.
>   Is that okay?


Sure.


>
> - If a certificate contains only iPAddress SANs, and none of them
>   match, I fall back to check the certificate Common Name. OpenSSL will
>   not do this (its X509_check_ip considers only SANs). NSS will only do
>   this if the client's address is itself a DNS name. The spec says that
>   we can't fall back to Common Name if the SANs contain any DNS
>   entries, but it's silent on the subject of IP addresses. What should
>   the behavior be?


I don't think we should fall back on the CN. It would seem quite odd to
do so for IP addresses but not for DNS names.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com