πΎ 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
β¬ οΈ Previous capture (2023-12-28)
-=-=-=-=-=-=-
@ 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@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 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, 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/_/ [ ] / \_ [ / \ \_ / / [ [ / \/ _/ _[ [ \ /_/
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.
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).
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).
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@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@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: Re: Gemini Digest, Vol 21, Issue 21
Next Thread: [tech] tls user_canceled issue with Java server + Go client