💾 Archived View for rawtext.club › ~sloum › geminilist › 006385.gmi captured on 2023-11-14 at 09:24:57. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
mbays mbays at sdf.org
Sun Apr 18 12:17:14 BST 2021
- - - - - - - - - - - - - - - - - - -
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.-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 195 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210418/f5aad62e/attachment.sig>