💾 Archived View for gemi.dev › gemini-mailing-list › 000867.gmi captured on 2023-11-04 at 13:09:58. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
@ 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
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 at 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/
On Thu, 15 Apr 2021 10:38:08 -0600 Alex // nytpu <alex at 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
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
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.
On Thu, 15 Apr 2021 20:51:33 +0000
nervuri <nervuri at 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/_/ [ ]
/ \_ [ /
\ \_ / /
[ [ / \/ _/
_[ [ \ /_/
On Thu, Apr 15, 2021 at 03:59:48PM +0000, nervuri <nervuri at 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.
On Thu, Apr 15, 2021 at 08:51:33PM +0000, nervuri <nervuri at 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).
On Thu, Apr 15, 2021 at 10:35:06PM -0700, Tom <tgrom.automail at 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).
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.
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.
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/.
On Thu, Apr 15, 2021 at 08:51:33PM +0000, nervuri <nervuri at 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'...
On Fri, Apr 16, 2021 at 8:23 AM nervuri <nervuri at 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
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
---
Previous Thread: Gemini Digest, Vol 21, Issue 21
Next Thread: [tech] tls user_canceled issue with Java server + Go client