From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "horikyota(dot)ntt(at)gmail(dot)com" <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Accept IP addresses in server certificate SANs |
Date: | 2022-03-22 20:42:37 |
Message-ID: | 5878cc4f261dfac70999be7c10d80e898449e388.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2022-03-22 at 13:32 +0900, Kyotaro Horiguchi wrote:
> At Fri, 18 Mar 2022 16:38:57 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> >
> > fe-secure-common.c doesn't need netinet/in.h.
> >
> >
> > +++ b/src/include/utils/inet.h
> > ..
> > +#include "common/inet-common.h"
> >
> > I'm not sure about the project policy on #include practice, but I
> > think it is the common practice not to include headers that are not
> > required by the file itself. In this case, fe-secure-common.h itself
> > doesn't need the include. Instead, fe-secure-openssl.c and
> > fe-secure-common.c needs the include.
Thanks, looks like I had some old header dependencies left over from
several versions ago. Fixed in v9.
> I noticed that this doesn't contain doc changes.
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postgresql.org%2Fdocs%2Fcurrent%2Flibpq-ssl.html&data=04%7C01%7Cpchampion%40vmware.com%7Cb25566c0f0124a30221908da0bbcec13%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637835203290105956%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sZuKc9UxmW1oZQij%2F%2F91rkEF57BZiQebkXtvEt%2FdROU%3D&reserved=0
>
> > In verify-full mode, the host name is matched against the
> > certificate's Subject Alternative Name attribute(s), or against the
> > Common Name attribute if no Subject Alternative Name of type dNSName
> > is present. If the certificate's name attribute starts with an
> > asterisk (*), the asterisk will be treated as a wildcard, which will
> > match all characters except a dot (.). This means the certificate will
> > not match subdomains. If the connection is made using an IP address
> > instead of a host name, the IP address will be matched (without doing
> > any DNS lookups).
>
> This refers to dNSName, so we should revise this so that it describes
> the new behavior.
v9 contains the bare minimum but I don't think it's quite enough. How
much of the behavior (and edge cases) do you think we should detail
here? All of it?
Thanks,
--Jacob
Attachment | Content-Type | Size |
---|---|---|
since-v8.diff.txt | text/plain | 2.3 KB |
v9-0001-Move-inet_net_pton-to-src-port.patch | text/x-patch | 4.5 KB |
v9-0002-libpq-allow-IP-address-SANs-in-server-certs.patch | text/x-patch | 48.5 KB |
v9-0003-squash-libpq-allow-IP-address-SANs-in-server-cert.patch | text/x-patch | 6.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-03-22 20:44:22 | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Previous Message | Andrew Dunstan | 2022-03-22 20:34:52 | Re: New Object Access Type hooks |