Comment by 🚬 sy
+1 for security-by-default. I hope a gemini protocol update mandates TLS1.3 with ECH, too.
It took some time for me to notice that @clseibold’s server was not down on the server side, but was actively being blocked by my ISP on TCP level. I had to special-case it in my client to use IP and avoid sending SNI. That workaround won’t work for multiple servers on the same IP with the current specification.
2025-01-25 · 1 year ago
2 Later Comments ↓
🚀 clseibold [🛂] · 2025-01-25 at 13:54:
@sy Oh, weird! I wonder what is getting it blocked. I use ALPN (Application-Layer Protocol Negotiation), so maybe it's that. Or maybe it's something with my certificate? Does the non-tls (nex, gopher, or spartan) sites work for you?
@clseibold Sorry for being not specific enough.
The whole ddns.net is being blocked, for unrelated reasons. HTTP is redirected to some other domain, and connection is reset for other protocols (by SNI sniffing if on TLS).
Edit: nex, gopher etc. plain protocols seems to work now. Previous problems probably were indeed server side. But I prefer eavesdropping- and tampering-resistant protocols nonetheless.
Original Post
Thoughts on geminict:// — My personal philosophy, is that protcols in the application layer shouldn’t implement encryption. I think encryption should be the job of the underlying network that the protocols run on. Take Yggdrasil or I2P for example, where addresses are cryptographic public keys and all traffic is encrypted. Running Gemini on such a network would mean encrypting traffic twice, which seems a bit unnecessary to me. If you simply implement encryption once, in the underlying network,...