Fetching any plain ip address over https fails due to rustls error

[junlarsen]

Related to #7660 and #7789

If we attempt to send a http request to any plain ip over https we receive an 'invalid dnsname' error, this can be demonstrated by running

deno eval "await fetch('https://8.8.8.8')"

which returns the following error

error: Uncaught Http: error sending request for url (https://8.8.8.8/): error trying to connect: invalid dnsname
    at Object.jsonOpAsync (core.js:236:13)
    at async fetch (deno:op_crates/fetch/26_fetch.js:1272:29)
    at async file:///C:/home/$deno$eval.ts:1:1

Deno's fetch implementation uses reqwest to send the http requests, which has been configured to use rustls for the TLS implementation.

This error seems to be a common issue when using rustls as it doesn't want to resolve plain ip addresses over https.

From #7660:

There is currently a limitation using Rustls when sending http requests to plain ip addresses (see rustls/rustls#281) which seems to stem from briansmith/webpki#54

This most likely means the issue stems from a dependency of a dependency of Deno which could take some time to fix as briansmith/webpki#54 hasn't seen any changes for the 3 years the issue has been alive.

Should this be fixed/resolved?

I think this a valid concern and should be discussed because the rfc for X.509 certificates state that ip addresses are valid identifiers plus there are multiple reasons to send requests over https to ip addresses.

RFC 5280, 5.2.2 (https://tools.ietf.org/html/rfc5280#section-5.2.2)

The issuer alternative name extension allows additional identities to be associated with the issuer of the CRL. Defined options include an electronic mail address (rfc822Name), a DNS name, an IP address, and a URI. Multiple instances of a name form and multiple name forms may be included.

Possible Fixes

• Moving away from Rustls: As seen and tested in fix #7660 #7789 this issue seems to be resolved if we move away from rustls, but that's a fairly large change which as mentioned in above thread, needs to be discussed first and we would have to look at possible regressions between different TLS implementations.
• Fork and patch reqwest/rustls/webpki: There are some proposed solutions if we look into these threads (Can't send request to 1.1.1.1 rustls/rustls#281, invalid dnsname rustls/hyper-rustls#84, webpki/cert: extend verify_is_valid_for to iPAddress SAN briansmith/webpki#54) but there has been little activity recently from the maintainers of the webpki repository and I think patching a dependency of a dependency of a dependency is less optimal.

[kitsonk]

Duplicate of #7660

Let's keep the discussion to one issue. That issue is still open.