Re: Support for NSS as a libpq TLS backend

On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > On 21 Sep 2021, at 02:06, Jacob Champion <pchampion(at)vmware(dot)com> wrote:
> > but I'm not sure that would be
> > correct either. If the user has the default sslsni="1" and supplies an
> > IP address for the host parameter, I don't think we should fail the
> > connection.
>
> Maybe not, but doing so is at least in line with how the OpenSSL support will
> handle the same config AFAICT. Or am I missing something?

With OpenSSL, I don't see a connection failure when using sslsni=1 with
IP addresses. (verify-full can't work, but that's a separate problem.)

> > > + if (host && host[0] &&
> > > + !(strspn(host, "0123456789.") == strlen(host) ||
> > > + strchr(host, ':')))
> > > + SSL_SetURL(conn->pr_fd, host);
> >
> > It looks like NSS may already have some code that prevents SNI from
> > being sent for IP addresses, so that part of the guard might not be
> > necessary. (And potentially counterproductive, because it looks like
> > NSS can perform verification against the certificate's SANs if you pass
> > an IP address to SSL_SetURL().)
>
> Skimming the NSS code I wasn't able find the countermeasures, can you provide a
> reference to where I should look?

I see the check in ssl_ShouldSendSNIExtension(), in ssl3exthandle.c.

> Feel free to post a new version of the NSS patch with these changes if you want.

Will do!

Thanks,
--Jacob