Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection
Andreas Metzler
ametzler at bebt.de
Sat May 18 06:40:13 BST 2024
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.
Hello,
which is totally irrelevant if my reading (quoted below) that this is
not a policy check but a performance optimization is correct.
> > 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.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
More information about the Pkg-gnutls-maint
mailing list