💾 Archived View for gem.benscraft.info › mailing-list › messages › 255 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
- mbays <mbays at sdf.org>
@ Sun, 18 Apr 2021 13:17 +0200
Reply to nervuri <nervuri at 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
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.
════════════════════════════════════════════════════════════════════════════════