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

[Elliott Mitchell]

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:
> [...]
> > > > > I notice the `_gnutls_dnsname_is_valid()` function in
> > > > > gnutls28-3.8.5/lib/str.h accepts IPv4 addresses (which are NOT valid in
> > > > > DNS), but rejects IPv6 addresses.
> 
> > > At a very bare level an IPv4 address is a valid DNS name (alnum, dashes,
> > > and dots), an IPv6 adress is not. That is what gnutls is checking here.
> 
> > No, there isn't any IPv4 address which is a valid DNS name.  No top-level
> > domain consists purely of decimal digits, whereas IPv4 addresses consist
> > of purely decimal digits.  In fact I don't believe there are any
> > top-level domains which have even a single decimal digit in them.

> which is totally irrelevant if my reading (quoted below) that this is
> not a policy check but a performance optimization is correct.

Most recent change to the line, commit 71d921edc4:

  Add GNUTLS_E_RECEIVED_DISALLOWED_NAME for illegal SNI names

  An illegal/disallowed SNI server name previously generated
  the misleading message "An illegal parameter has been received.".

  This commit changes it to
    "A disallowed SNI server name has been received.".

That commit message clearly indicates the author was thinking of it as a
policy check.

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

The issue is libgnutls's API requires providing the library with the
server being connected to.  libgnutls then assumes the provided server
can be used for SNI, which is untrue (in this case IP addresses violate
RFC 6066).


-- 
(\___(\___(\______          --=> 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