πŸ’Ύ Archived View for gem.benscraft.info β€Ί mailing-list β€Ί threads β€Ί 234 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

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

[tech] IPv6 addresses in URLs

- nervuri <nervuri at disroot.org>

@ Thu, 15 Apr 2021 15:59 +0000

In reply to

View Message

────────────────────────────────────────────────────────────────────────────────

@ 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

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Alex // nytpu <alex at nytpu.com>

@ Thu, 15 Apr 2021 10:38 -0600

In reply to nervuri <nervuri at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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/

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- almaember <almaember at disroot.org>

@ Thu, 15 Apr 2021 20:07 +0200

In reply to Alex // nytpu <alex at nytpu.com>

View Message

────────────────────────────────────────────────────────────────────────────────

On Thu, 15 Apr 2021 10:38:08 -0600

Alex // nytpu <alex@nytpu.com> wrote:

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.

Please excuse my lack of knowledge about SNI, but can't clients send

the IP address as a host too?

If they can, then the server operator could simply configure what they

want to send for plain IP addresses, like it's done already with

subdomains?

~almaember

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Alex // nytpu <alex at nytpu.com>

@ Thu, 15 Apr 2021 12:38 -0600

In reply to almaember <almaember at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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/

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- nervuri <nervuri at disroot.org>

@ Thu, 15 Apr 2021 20:51 +0000

In reply to Alex // nytpu <alex at nytpu.com>

View Message

────────────────────────────────────────────────────────────────────────────────

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 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.

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 SNI

field. But does it? Here's what it says at the start of

https://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 this

case? 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 problem

with either.

I'll open the issue on GitLab.

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Tom <tgrom.automail at nuegia.net>

@ Thu, 15 Apr 2021 22:35 -0700

In reply to nervuri <nervuri at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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/_/ [ ]

/ \_ [ /

\ \_ / /

[ [ / \/ _/

_[ [ \ /_/

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Stephane Bortzmeyer <stephane at sources.org>

@ Fri, 16 Apr 2021 09:03 +0200

In reply to nervuri <nervuri at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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.

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Stephane Bortzmeyer <stephane at sources.org>

@ Fri, 16 Apr 2021 09:07 +0200

In reply to nervuri <nervuri at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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).

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Stephane Bortzmeyer <stephane at sources.org>

@ Fri, 16 Apr 2021 09:07 +0200

In reply to Tom <tgrom.automail at nuegia.net>

View Message

────────────────────────────────────────────────────────────────────────────────

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).

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Anna β€œCyberTailor” <cyber at sysrq.in>

@ Fri, 16 Apr 2021 14:57 +0500

In reply to Tom <tgrom.automail at nuegia.net>

View Message

──────────────────────────────────────────────────────────────────────────────���─

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.

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- nervuri <nervuri at disroot.org>

@ Fri, 16 Apr 2021 12:23 +0000

In reply to Stephane Bortzmeyer <stephane at sources.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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.

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- nervuri <nervuri at disroot.org>

@ Fri, 16 Apr 2021 15:43 +0000

In reply to Stephane Bortzmeyer <stephane at sources.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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/.

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Stephane Bortzmeyer <stephane at sources.org>

@ Sat, 17 Apr 2021 12:26 +0200

In reply to nervuri <nervuri at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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.

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- Michael Lazar <lazar.michael22 at gmail.com>

@ Sat, 17 Apr 2021 23:59 -0400

In reply to nervuri <nervuri at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- nervuri <nervuri at disroot.org>

@ Sun, 18 Apr 2021 09:12 +0000

In reply to Stephane Bortzmeyer <stephane at sources.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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

════════════════════════════════════════════════════════════════════════════════

Re: [tech] IPv6 addresses in URLs

- mbays <mbays at sdf.org>

@ Sun, 18 Apr 2021 13:17 +0200

In reply to nervuri <nervuri at disroot.org>

View Message

────────────────────────────────────────────────────────────────────────────────

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.
════════════════════════════════════════════════════════════════════════════════