πŸ’Ύ Archived View for gemi.dev β€Ί gemini-mailing-list β€Ί 000870.gmi captured on 2024-03-21 at 18:10:02. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

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

[tech] IPv6 addresses in URLs

1. nervuri (nervuri (a) disroot.org)

@ Gemini client developers: both of these URLs should work (certificate
errors aside):

gemini://2a02:7b40:592f:a446::1/
gemini://[2a02:7b40:592f:a446::1]:1965/

The majority of clients can't open them.  I tested Amfora, AV-98,
Kristall, Lagrange, gmni, Agunua, Bombadillo and 5 web proxies.  Only
Amfora and AV-98 worked with both.

The address corresponds to gemini://purexo.mom/, which I used because it
is available by entering its IPv4 or IPv6 address directly:

gemini://purexo.mom/
gemini://89.47.164.70/
gemini://89.47.164.70:1965/
gemini://2a02:7b40:592f:a446::1/
gemini://[2a02:7b40:592f:a446::1]:1965/

You can also test with:

gemini://9til.de/
gemini://199.247.10.62/
gemini://199.247.10.62:1965/

gemini://tweek.zyxxyz.eu/
gemini://2001:470:b42d::46:1:144/
gemini://[2001:470:b42d::46:1:144]:1965/

If you get certificate validation errors, that's good: it means the
client made a connection.

As a side note, I also tested "gemini://gΓ©meaux.bortzmeyer.org/cafΓ©.gmi"
and it opened in all clients except for Bombadillo, gmni and the 5
proxies:
- https://proxy.vulpes.one/
- https://portal.mozz.us/
- kineto - https://portal.drewdevault.com/x/g%C3%A9meaux.bortzmeyer.org/caf%C3%A9.gmi
- gemini://celehner.com/proxy/ - https://celehner.com/gemini://
- https://gemini.susa.net:1993/proxy.html

Link to individual message.

2. Alex // nytpu (alex (a) nytpu.com)

The problem is that Gemini mandates Server Name Indication (SNI).  It lets you
host multiple (sub)domains at one IP address.

If you request gemini://173.230.145.243/index.gmi (flounder.online), how do you
know which subdomain it goes to?  flounder.online has like a hundred subdomains,
all of which have an index.gmi, all of which are hosted at the same IP address.

You could say "then it should just default to some specific domain," but then
that's a server issue and the client can't do anything about it since it doesn't
know what the "default" domain is.  Also servers are allowed to drop requests
that don't use SNI, so they're under no obligation to support using a raw IP
even though I personally do think it'd be a nice feature to have.

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/

Link to individual message.

3. Alex // nytpu (alex (a) nytpu.com)

On 2021-04-15 08:07PM, almaember wrote:
> Please excuse my lack of knowledge about SNI, but can't clients send
> the IP address as a host too?
RFC-6066 mandates the use of fully qualified domain names, but says:
> ...Currently, the only server names supported are DNS hostnames;
> however, this does not imply any dependency of TLS on DNS, and other
> name types may be added in the future...

It also says:
> Literal IPv4 and IPv6 addresses are not permitted in "HostName".
https://tools.ietf.org/html/rfc6066#section-3

TLS 1.3 simply says that it's mandatory to implement SNI as specified in
RFC6066 Β§3, so unfortunately no updates there
https://tools.ietf.org/html/rfc8446#section-9.2



However, right before sending this, I realized that there's a key point that I
didn't realize until reading the spec just now: 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.

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/

Link to individual message.

4. Tom (tgrom.automail (a) nuegia.net)

On Thu, 15 Apr 2021 20:51:33 +0000
nervuri <nervuri@disroot.org> wrote:

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

If we can going to mandate SNI can we at least mandate ESNI for
privacy? Maybe when we mandate TLS1.3 and drop 1.2.


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

OpenNIC still exists and I run my resolvers off them. No need to pay a
DNS tax.


-- 
 ______________________________________ 
/ <Sanaya> you guys are all sick! sick \
\ sick sick I tell ya ;)               /
 -------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

Link to individual message.

5. Stephane Bortzmeyer (stephane (a) sources.org)

On Thu, Apr 15, 2021 at 03:59:48PM +0000,
 nervuri <nervuri@disroot.org> wrote 
 a message of 40 lines which said:

> @ Gemini client developers: both of these URLs should work (certificate
> errors aside):
> 
> gemini://2a02:7b40:592f:a446::1/
> gemini://[2a02:7b40:592f:a446::1]:1965/

No. The first one is not a legal URL.

RFC 3986 :

3.2.2.  Host

   The host subcomponent of authority is identified by an IP literal
   encapsulated within square brackets, an IPv4 address in dotted-
   decimal form, or a registered name.

Link to individual message.

6. Stephane Bortzmeyer (stephane (a) sources.org)

On Thu, Apr 15, 2021 at 08:51:33PM +0000,
 nervuri <nervuri@disroot.org> wrote 
 a message of 40 lines which said:

> Also, there's no reason for Gemini to require paying the DNS tax.

What is "the DNS tax"? Using the DNS is gratis. Registering a name is
gratis in many registries (such as eu.org).

Link to individual message.

7. Stephane Bortzmeyer (stephane (a) sources.org)

On Thu, Apr 15, 2021 at 10:35:06PM -0700,
 Tom <tgrom.automail@nuegia.net> wrote 
 a message of 36 lines which said:

> If we can going to mandate SNI can we at least mandate ESNI for
> privacy?

There is no standard for encrypted SNI (and the problem is
complicated).

Link to individual message.

8. Anna β€œCyberTailor” (cyber (a) sysrq.in)

On 2021-04-15 22:35, Tom wrote:
> If we can going to mandate SNI can we at least mandate ESNI for
> privacy? Maybe when we mandate TLS1.3 and drop 1.2.

No stable TLS library supports ESNI/ECH and the standard is not final
either.

Link to individual message.

9. nervuri (nervuri (a) disroot.org)

https://gitlab.com/gemini-specification/protocol/-/issues/33

See makeworld's comments.  It looks like "no SNI" is the right answer
for IP addresses.


On Fri, 2021-04-16, Stephane Bortzmeyer wrote:
>> gemini://2a02:7b40:592f:a446::1/
>> gemini://[2a02:7b40:592f:a446::1]:1965/
> 
> No. The first one is not a legal URL.

Thanks, I stand corrected.  Indeed, Agunua points out that the first URL
is invalid, but connects to the second one.

The clients I tested which didn't accept the second URL are:
- Lagrange
- gmni
- bombadillo
- Mozz web proxy - https://portal.mozz.us/gemini/%5B2a02:7b40:592f:a446::1%5D:1965/
- gemini://celehner.com/proxy/ - 
https://celehner.com/gemini://[2a02:7b40:592f:a446::1]:1965/
- https://gemini.susa.net:1993/proxy.html

However, most clients accept the host without the scheme and behavior is
sometimes inconsistent.  For instance, in Amfora:
- "89.47.164.70" works
- "[2a02:7b40:592f:a446::1]" works if it is supplied from the
 command line, but not from within the program.
- "2a02:7b40:592f:a446::1" - same as the above

Agunua and Kristall adhere to the RFC, so they connect to the first two,
but not the third.

Link to individual message.

10. nervuri (nervuri (a) disroot.org)

On Fri, 2021-04-16, Stephane Bortzmeyer wrote:
>> Also, there's no reason for Gemini to require paying the DNS tax.
> 
> What is "the DNS tax"? Using the DNS is gratis. Registering a name is
> gratis in many registries (such as eu.org).

The DNS is a world of complexity which I prefer to avoid whenever using
raw IP addresses is feasible.

Still, it's good to know about gratis options.  Thanks for mentioning
https://nic.eu.org/.

Link to individual message.

11. Stephane Bortzmeyer (stephane (a) sources.org)

On Thu, Apr 15, 2021 at 08:51:33PM +0000,
 nervuri <nervuri@disroot.org> wrote 
 a message of 40 lines which said:

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

For instance, egsam.glv.one reacts badly when you don't send a SNI:

% gnutls-cli -p 1965 --disable-sni --insecure egsam.glv.one 
Processed 0 CA certificate(s).
Resolving 'egsam.glv.one:1965'...
Connecting to '52.51.189.88:1965'...


While it works otherwise.

Link to individual message.

12. Michael Lazar (lazar.michael22 (a) gmail.com)

On Fri, Apr 16, 2021 at 8:23 AM nervuri <nervuri@disroot.org> wrote:
> Thanks, I stand corrected.  Indeed, Agunua points out that the first URL
> is invalid, but connects to the second one.
>
> The clients I tested which didn't accept the second URL are:
> <snip>
> - Mozz web proxy - https://portal.mozz.us/gemini/%5B2a02:7b40:592f:a446::1%5D:1965/
> <snip>

For what it's worth, with my proxy this was an IPv6 networking problem
and not a URL parsing problem. Either way, it has now been fixed.

- Michael

Link to individual message.

13. nervuri (nervuri (a) disroot.org)

On Sat, 2021-04-17, Stephane Bortzmeyer wrote:
>> No SNI vs empty SNI - we could test to see if servers have a problem
>> with either.
> 
> For instance, egsam.glv.one reacts badly when you don't send a SNI:
> 
> % gnutls-cli -p 1965 --disable-sni --insecure egsam.glv.one

Sure, but I was only referring to capsules accessible using an IP
address instead of a DNS name.  Makeworld figured it out:

https://gitlab.com/gemini-specification/protocol/-/issues/33

Link to individual message.

14. mbays (mbays (a) sdf.org)



> On Sat, 2021-04-17, Stephane Bortzmeyer wrote:
> > > No SNI vs empty SNI - we could test to see if servers have a problem
> > > with either.
> > > For instance, egsam.glv.one reacts badly when you don't send a SNI:
> > > % gnutls-cli -p 1965 --disable-sni --insecure egsam.glv.one
> 
> Sure, but I was only referring to capsules accessible using an IP
> address instead of a DNS name.  Makeworld figured it out:
> 
> https://gitlab.com/gemini-specification/protocol/-/issues/33

For the benefit of those who don't want to fire up a javascript browser 
just to see this: I (grudgingly) did it for you, and here's Makeworld's comment.

> Ok, I figured it out.
> 
> I used Wireshark to analyze curl traffic to https://1.1.1.1 and 
https://example.com. curl only sends the SNI for the latter connection. 
For the former it omits it entirely. As further clarified in the OpenSSL wiki:
> 
>   SNI has been made mandatory to implement in TLS 1.3 but not mandatory to use.
> 
> I'm not sure if an empty SNI is valid or accepted by spec or existing 
code, but omitting it certainly is. Most of the TLS libraries geminauts 
are using would be doing all this by default, and so the spec should 
reflect that. SNI should be omitted for IP addresses.

Link to individual message.

---

Previous Thread: Re: Gemini Digest, Vol 21, Issue 21

Next Thread: [tech] tls user_canceled issue with Java server + Go client