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

Andreas Metzler ametzler at bebt.de
Sat May 18 07:16:25 BST 2024


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

Hello,


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

cu Andreas



More information about the Pkg-gnutls-maint mailing list