💾 Archived View for rawtext.club › ~sloum › geminilist › 006369.gmi captured on 2024-02-05 at 11:00:36. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[tech] IPv6 addresses in URLs

nervuri nervuri at disroot.org

Thu Apr 15 21:51:33 BST 2021

- - - - - - - - - - - - - - - - - - -

On Thu, 2021-04-15, Alex // nytpu wrote:

The problem is that Gemini mandates Server Name Indication (SNI). It lets you

host multiple (sub)domains at one IP address.

Indeed, this might require clarification in the spec. There's no reasonto demand SNI if a raw IP address is used - as almaember points out, RFC6066 even forbids IP addresses in SNI. If a server has multiple IPaddresses, it can serve different certificates on each of them withouthaving to use SNI.

Also, there's no reason for Gemini to require paying the DNS tax.People should be able to host capsules without dealing with DNS.

the HostName field can be 0 characters. TLS 1.3 (and Gemini over TLS

1.2) mandates that the SNI extension /exists/ in the ClientHello, but

the hostname field itself can be empty, indicating to use some

"default" at the operators discresion. If anyone has a gitlab account,

this might be a good thing to open an issue to clarify.

Yes, if TLS 1.3 mandates it, then the answer is to send an empty SNIfield. But does it? Here's what it says at the start ofhttps://tools.ietf.org/html/rfc8446#section-9.2 :

In the absence of an application profile standard specifying otherwise,

a TLS-compliant application MUST implement the following TLS extensions

What does "application profile standard" mean? Can the Gemini"application profile standard" say that SNI is not required in thiscase? Or would this create problems with TLS libraries?

For what it's worth, the OpenSSL s_client manpage says:

Even though SNI should normally be a DNS name and not an IP

address, if -servername is provided then that name will be

sent, regardless of whether it is a DNS name or not.

No SNI vs empty SNI - we could test to see if servers have a problemwith either.

I'll open the issue on GitLab.