Skip to content

Conversation

@icing
Copy link
Contributor

@icing icing commented Oct 27, 2025

Change the test certificate to carry a altname 'dns:127.0.0.1' which should not match in test_17_05_bad_ip_addr.

wolfSSL: since wolfSSL_check_domain_name() does not differentiate between DNS and IP names, use if only for DNS names. For IP addresses, get the peer certificate after the handshake and check that using wolfSSL_X509_check_ip_asc().

Unfortunately, this succeeds where it should not, as wolfSSL internally used the same check code for both cases. So, skip the test case until wolfSSL fixes that.

Change the test certificate to carry a altname 'dns:127.0.0.1' which
should *not* match in test_17_05_bad_ip_addr.

wolfSSL: since `wolfSSL_check_domain_name()` does not differentiate
between DNS and IP names, use if only for DNS names. For IP addresses,
get the peer certificate after the handshake and check that using
wolfSSL_X509_check_ip_asc().

Unfortunately, this succeeds where it should not, as wolfSSL internally
used the same check code for both cases. So, skip the test case until
wolfSSL fixes that.
@icing
Copy link
Contributor Author

icing commented Oct 27, 2025

Opened wolfSSL/wolfssl#9351 at the wolfSSL project.

wolfssl+mbedtls work on "normal" not-matching ip addresses.
@MegaManSec
Copy link
Contributor

Thanks for this! Any chance to add an ipv6 test too?

Add macos skips on wolfssl early data tests which are not reliable
@curl curl deleted a comment from testclutch Oct 27, 2025
@icing
Copy link
Contributor Author

icing commented Oct 27, 2025

Thanks for this! Any chance to add an ipv6 test too?

Not easily. We'd need a dynamic check if ipv6 is working on the platform.

Also: thinking some more about this test, it seems highly theoretical. If someone gets a CA to sign a cert with an ip address in a DNS alt name, they can probably trick other things in there as well. It's then a broken CA we would be dealing with, or?

@MegaManSec
Copy link
Contributor

We'd need a dynamic check if ipv6 is working on the platform.

Understood.

it seems highly theoretical

Yup, I agree,that's it is even untested from that other PR; it was just an idea I had about what this code could theoretically break.

By the way, I think there is another case in `lib/vquic/vquic-tls.c. Here's an ad-hoc patch which shows the issue:

diff --git a/lib/vquic/vquic-tls.c b/lib/vquic/vquic-tls.c
index fa89c0b80..3b6f2124d 100644
--- a/lib/vquic/vquic-tls.c
+++ b/lib/vquic/vquic-tls.c
@@ -178,12 +178,21 @@ CURLcode Curl_vquic_tls_verify_peer(struct curl_tls_ctx *ctx,
 #elif defined(USE_WOLFSSL)
   (void)data;
   if(conn_config->verifyhost) {
-    char *snihost = peer->sni ? peer->sni : peer->hostname;
-    WOLFSSL_X509* cert = wolfSSL_get_peer_certificate(ctx->wssl.ssl);
-    if(wolfSSL_X509_check_host(cert, snihost, strlen(snihost), 0, NULL)
-          == WOLFSSL_FAILURE) {
-      result = CURLE_PEER_FAILED_VERIFICATION;
+    const char *host = peer->sni ? peer->sni : peer->hostname;
+    WOLFSSL_X509 *cert = wolfSSL_get_peer_certificate(ctx->wssl.ssl);
+    int ok = 0;
+
+    if(host) {
+      if(Curl_host_is_ipnum(host)) {
+        ok = (wolfSSL_X509_check_ip_asc(cert, host, 0) == WOLFSSL_SUCCESS);
+      }
+      else {
+        ok = (wolfSSL_X509_check_host(cert, host, strlen(host), 0, NULL)
+              == WOLFSSL_SUCCESS);
+      }
     }
+    if(!ok)
+      result = CURLE_PEER_FAILED_VERIFICATION;
     wolfSSL_X509_free(cert);
   }
   if(!result)

@icing
Copy link
Contributor Author

icing commented Oct 27, 2025

@MegaManSec good catch.

@icing icing requested a review from bagder October 27, 2025 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

3 participants