Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Elliott Mitchell]

On Sat, May 18, 2024 at 08:16:25AM +0200, Andreas Metzler wrote:
> On 2024-05-18 Elliott Mitchell <ehem+debian at m5p.com> wrote:
> > On Sat, May 18, 2024 at 07:40:13AM +0200, Andreas Metzler wrote:
> >> On 2024-05-18 Elliott Mitchell <ehem+debian at m5p.com> wrote:
> >>> On Sat, May 18, 2024 at 06:55:06AM +0200, Andreas Metzler wrote:
> [...]
> >>>> Afaict it is a short-cut to save more expensive processing for obvious
> >>>> errors. gnutls_session_get_verify_cert_status() (with
> >>>> gnutls_session_set_verify_cert() set correctly) or
> >>>> gnutls_x509_crt_check_hostname()/gnutls_certificate_verify_peers3()
> >>>> does more elaborate stuff on the data,
> >>>> gnutls_certificate_verify_peers2() requires a separate
> >>>> gnutls_x509_crt_check_hostname().
> 
> >>> Which seems to argue the more urgent issue is
> >>> _gnutls_server_name_send_params() needs to do checking of the provided
> >>> server hostname before sending it as SNI.
> 
> >> Why is this urgent or even relevant? Certificate checking (client-side)
> >> will not accept IP adresses as SNI field.
> 
> > Not relevant.  If the certificate comes from a local file, it is assumed
> > trusted.  If the certificate comes from the server, then it is only
> > available *after* connection and the SNI has already been sent.
> [...]

> 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.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445