On Sat, May 18, 2024 at 10:47:55AM +0200, Andreas Metzler wrote: > On 2024-05-18 Elliott Mitchell <ehem+deb...@m5p.com> wrote: > > On Sat, May 18, 2024 at 08:16:25AM +0200, Andreas Metzler wrote: > [...] > > >> You seem to argue that it is major problem for a gnutls client to *send* > >> e.g. "127.0.0.1" as SNI. My point is that this is not a problem but at > >> most uncomely since client-side certificate verification will fail. > >> Even for a trusted certificate name checking is done (if gnutls is > >> correctly used). And this will not succeed if the CN or SAN is an IP > >> address. (I have tried with test certificates and gnutls-cli/-serv. My > >> testing might be flawed of course.) > > > This is purely hypothetical since this case isn't being observed. > > > What #1070033 is about is, a program was configured to directly connect > > to a server via IPv6. This address was provided to libgnutls. libgnutls > > sent the provided address to the server as SNI without verifying it was > > valid for SNI. > > > The usual approach is be conservative in what you send, but liberal in > > what you accept. This means libgnutls needs to check whether what is > > provided is acceptable before sending it, but the server side could > > allow an IP address which violates RFC 6066. > > > `gnutls-cli` is a very poor simulcrum for this case. `gnutls-cli` does > > lots of checking which specialized clients may skip. `gnutls-cli` also > > assumes name service is fully available. Whereas `nslcd` cannot rely on > > name service being operational as it may provide name service.
> Let's assume > a) _gnutls_server_name_send_params() was changed to reject > e.g. "127.0.0.1"[1] and > b) this stopped libgnutls from sending "127.0.0.1" to the server as SNI. > > How would this help you, or how is this related to this bug report? In > this bug report perhaps an IPv6 address was used which is already > rejected by _gnutls_server_name_send_params(). This is not something I proposed and indeed this wouldn't help me. _gnutls_server_name_recv_params() does some rough filtering which catches IPv6 addresses, but not IPv4 addresses. _gnutls_server_name_send_params() does NO filtering and thus sends both IPv4 and IPv6 addresses. libgnutls is being conservative in what it accepts, but liberal in what it sends. This breaks interoperability. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
