Comment by 🚀 stack
Re: "The Mercury Protocol - Gemini without TLS"
@spc476: Thanks, and keep in mind that this is more theoretical bitching than a call to action...
Gemini is fine the way it is, and it is not likely to change, which is good.
I cannot help but scratch my head about TLS sometimes, as it accomplishes next to nothing. Why were neo-Gopherites even interested in Gopher with TLS? It adds pretty much zero with a rounding error of security or privacy.
Now, client certificates are pretty convenient to track games. But it is an overkill as it saves passing around a couple of dozen bytes of a session token -- since we have no cookies. But a convenience nontheless -- thanks for that.
Jan 09 · 4 months ago
9 Later Comments ↓
+1 for tls client certs
You can easily indicate TLS or not by the URI scheme in a link. This would work for Gemini, but for Gopher it would not work as well because of the way Gopher menus are working do not use URLs (for Gopher and some other protocols such as Telnet and CSO/PH); however, DNS records might be used for this purpose.
TLS does have some benefits, especially if client certificates are used. It can mitigate external spying and tampering (not from the server operator though) if you trust the server's certificate for this purpose (what and how much is required will will depend on your use), and client certificates are useful for authentication (and are more secure and more versatile than other methods, including possibility of partial delegation of authorization, and many more things). Using server certificates and client certificates together can improve security.
However, to allow working without the complexity of TLS (and other reasons mentioned in the linked articles), the TLS should be optional rather than mandatory. TLS especially should not be mandatory for public data (especially if it is read-only access), since anyone can read it anyways. You might also use a proxy, without needing to decrypt and encrypt the data multiple times.
For many types of games, it is probably better to use a interactive session (such as Telnet or SSH, or the I type request in Scorpion) rather than using Gemini with client certificates, although not all of them (in some cases you should use client certificates as well as an interactive session; this depends on the type of game); as you mention, session tokens in the URL would also help and may be a better way. For example, with correspondence play you might use a protocol to download files such as Gemini and use client certificates to keep track of who it is for multiple requests on different days.
And as I said, just do it. Put up a proof-of-concept and let's see it in action. I would especially like to see how you handle TLS and non-TLS on the same port. But overall, I think you are battling an uphill battle against TLS on the general Internet, and especially for a non-TLS version of Gemini.
You might use MSG_PEEK to check if the first byte received from the client is 0x16; if so then it is TLS, otherwise it is not TLS.
Nothing stopping you from doing that. I'd like to see it.
🚀 stack [OP] · Jan 11 at 18:28:
I am not sure it's worth the effort, given the size of our community. I can only commit to so many 'products' with 1-10 users:)
I wasn't necessarilly replying to you. I might have been replying to zzo38.
🚀 stack [OP] · Jan 12 at 03:00:
@spc476: which is it? You don't seem certain. :)
zzo38.
Original Post
The Mercury Protocol - Gemini without TLS — [gemini link]