crypto/tls: SNI name with trailing dot (absolute name) fails tls handshake #63117
Description
Note: I don't think this is a bug in Go crypto/tls, but its strict handling may cause interoperability issues.
Go version
go1.21.1, probably earlier too.
What did you do?
Start a crypto/tls-based webserver. Browse to it with a popular browser (firefox, chromium, safari) with a URL that has a trailing dot, e.g. https://www.xmox.nl./
What did you expect to see?
You may expect to see a website.
What did you see instead?
A TLS handshake error.
It looks like the popular browsers do not remove the trailing dot from the SNI name used in their TLS handshake. Crypto/tls correctly (according to the TLS RFC) refuses the connection. See https://github.com/golang/go/blob/go1.21.1/src/crypto/tls/handshake_messages.go#L447
For firefox, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1008120
For chromium, see: https://bugs.chromium.org/p/chromium/issues/detail?id=593952
Curl does strip the trailing dot from SNI, so curl https://www.xmox.nl./ can get to the HTTP response (though in this case the domain with trailing dot is not configured).
For most websites I tried to access with an absolute domain name (that are likely not running a crypto/tls-based HTTPS-webserver) the connections do work, e.g.: https://www.google.com./ https://www.amazon.com./
Some more examples that don't work: https://caddyserver.com./, https://nu.nl./ (appears to use skipper).
From memory (about 6 months ago), I first ran into this when using a crypto/tls-based webserver to offer email account autodiscovery to Microsoft Outlook. The incoming autodiscovery HTTPS connections had a trailing dot in the SNI name, so autodiscovery failed. Outlook seems to have made up the absolute URL itself.
To summarize: I don't think this is a bug in crypto/tls, and I like its correct/strict behaviour, but that may cause interoperability issues. I'm mostly filing this bug for future reference and possible discussion and after a hint from @FiloSottile.