On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote: > > On 21 Sep 2021, at 02:06, Jacob Champion <pchamp...@vmware.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
