Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
New patch picked in Debian and side-effect to switch to gnutls
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Carlos Henrique Lima Melara via curl-distros <curl-distros_at_lists.haxx.se>
Date: Sat, 6 Jul 2024 17:06:46 -0300
Hi,
We've received to new bug reports #1075747 [1] and #1075796 [2]
recently. Daniel has replied [1] pointing to 9aa1d41 [3]. We have cherry
picked that commit and will be shipping in the next Debian release of
curl (probably this weekend).
We also noticed something new with gnutls backend. Stenographer [4]
tests started to fail with this new curl version so we went thorugh a
debug session on thursday and the cause is Stenographer is using curl to
fetch some data on a server running on localhost (127.0.0.1) with TLS.
It provides some certificates but sets 127.0.0.1 in certificates' CN but
not on subjectAltName.
Digging through gnutls code (thanks to sergiodj) we found this comment:
* IPv4 addresses are accepted by this function in the dotted-decimal
* format (e.g, ddd.ddd.ddd.ddd), and IPv6 addresses in the hexadecimal
* x:x:x:x:x:x:x:x format. For them the IPAddress subject alternative
* name extension is consulted. Previous versions to 3.6.0 of GnuTLS
* in case of a non-match would consult (in a non-standard extension)
* the DNSname and CN fields. This is no longer the case.
And checking RFC2818:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
[...]
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
So it appears gnutls is more strict than openssl regarding this point.
Well, this is more of trivia for you :-) But we filled #1075859 [5].
Cheers,
Charles
[1] https://bugs.debian.org/1075747
[2] https://bugs.debian.org/1075796
[3] https://github.com/curl/curl/commit/9aa1d412b814a40868558da51a6ab28ce1384a58
[4] https://tracker.debian.org/pkg/stenographer
[5] https://bugs.debian.org/1075859
Received on 2024-07-06
Date: Sat, 6 Jul 2024 17:06:46 -0300
Hi,
We've received to new bug reports #1075747 [1] and #1075796 [2]
recently. Daniel has replied [1] pointing to 9aa1d41 [3]. We have cherry
picked that commit and will be shipping in the next Debian release of
curl (probably this weekend).
We also noticed something new with gnutls backend. Stenographer [4]
tests started to fail with this new curl version so we went thorugh a
debug session on thursday and the cause is Stenographer is using curl to
fetch some data on a server running on localhost (127.0.0.1) with TLS.
It provides some certificates but sets 127.0.0.1 in certificates' CN but
not on subjectAltName.
Digging through gnutls code (thanks to sergiodj) we found this comment:
* IPv4 addresses are accepted by this function in the dotted-decimal
* format (e.g, ddd.ddd.ddd.ddd), and IPv6 addresses in the hexadecimal
* x:x:x:x:x:x:x:x format. For them the IPAddress subject alternative
* name extension is consulted. Previous versions to 3.6.0 of GnuTLS
* in case of a non-match would consult (in a non-standard extension)
* the DNSname and CN fields. This is no longer the case.
And checking RFC2818:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
[...]
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
So it appears gnutls is more strict than openssl regarding this point.
Well, this is more of trivia for you :-) But we filled #1075859 [5].
Cheers,
Charles
[1] https://bugs.debian.org/1075747
[2] https://bugs.debian.org/1075796
[3] https://github.com/curl/curl/commit/9aa1d412b814a40868558da51a6ab28ce1384a58
[4] https://tracker.debian.org/pkg/stenographer
[5] https://bugs.debian.org/1075859
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-distros Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: signature.asc