The HTTP/2 transport converts the target hostname of a request to ASCII via simple Punycode translation without most validation. (It incorrectly uses idna.ToASCII instead of idna.Lookup.ToASCII) This permits invalid results, such as translating the Unicode name "a⒈com" ("a\u2488com") to the ASCII hostname "xn--acom-0w1b".
This affects direct use of "golang.org/x/net/http2".Transport.RoundTrip with pre-1.27 Go versions, and direct use of "golang.org/x/net/http2".Transport.NewClientConn with all Go versions.
This does not affect use of HTTP/2 via net/http, except for a corner case where a request for the ASCII version of the invalid name which succeeds can be followed by a request for the Unicode version which may reuse the cached connection from the prior attempt.
The practical impact of this is that under some scenarios, fetching a URL with a hostname containing non-ASCII characters can result in a request being sent to the Punycode-translated ASCII host.
This was reported to us as a potential vulnerability. We don't see a good way to exploit this.
It permits a request to "g\u200bo.dev" (non-breaking space, renders as "go.dev") to be sent to "xn--go-g1t.com", which is potentially surprising but TR #46 validation is not really intended to prevent confusables of this nature.
It does not permit a request to "xn-go-.dev" to be rewritten to "go.dev", since idna.ToASCII (after the fix for #78760) rejects xn- labels encoding ASCII-only strings.
Still a bug worth fixing.
The HTTP/2 transport converts the target hostname of a request to ASCII via simple Punycode translation without most validation. (It incorrectly uses idna.ToASCII instead of idna.Lookup.ToASCII) This permits invalid results, such as translating the Unicode name "a⒈com" ("a\u2488com") to the ASCII hostname "xn--acom-0w1b".
This affects direct use of
"golang.org/x/net/http2".Transport.RoundTripwith pre-1.27 Go versions, and direct use of"golang.org/x/net/http2".Transport.NewClientConnwith all Go versions.This does not affect use of HTTP/2 via net/http, except for a corner case where a request for the ASCII version of the invalid name which succeeds can be followed by a request for the Unicode version which may reuse the cached connection from the prior attempt.
The practical impact of this is that under some scenarios, fetching a URL with a hostname containing non-ASCII characters can result in a request being sent to the Punycode-translated ASCII host.
This was reported to us as a potential vulnerability. We don't see a good way to exploit this.
It permits a request to "g\u200bo.dev" (non-breaking space, renders as "go.dev") to be sent to "xn--go-g1t.com", which is potentially surprising but TR #46 validation is not really intended to prevent confusables of this nature.
It does not permit a request to "xn-go-.dev" to be rewritten to "go.dev", since idna.ToASCII (after the fix for #78760) rejects xn- labels encoding ASCII-only strings.
Still a bug worth fixing.