Comment by 🚀 stack
Re: "The Mercury Protocol - Gemini without TLS"
Other than link and query syntax, pretty much all of gemtext is kind of optional. In the sense that if you do nothing, it still kind of makes sense. > for instance, works, even if indents are not enforced. ``` works as long as you don't render links inside. But if you do, little harm done. #Headers, do not matter. Am I missing anything?
I see that Mercury also assumes UTF8 as standard character set, which is pretty much expected anyway.
Do any existing Gemini servers serve Gemini without TLS? What does that even mean -- what do the URLs look like?
Jan 08 · 4 months ago
14 Later Comments ↓
Spartan comes to mind. close?
Spartan uses the same file format as Gemini (with one difference, which is only relevant for dynamic files and not for static files), although the protocol has some significant differences (other than just not using TLS). These differences are probably not significant for static files, but can be significant for dynamic files.
There were (and still are, to a lesser degree) attempts to fix Gopher to use TLS, and it's from that that Solderpunk started designed Gemini---as a newer gopher with TLS, and from the beginning, TLS was non-negotiable.
His change was due to demands from uers who wanted a way to protect pages within a Gemini site, and it was I who thought to use client certificates to do so (at the time because the TLS library I was using made it trivial, but it wasn't a popular TLS library). I think Solderpunk got overwhelmed with the discussions at the time due to the affordances that different TLS libraries had (most were both hard to use, and the most popular ones were all hard to use, go figure). Do note that Solderpunk never bothered actually implementing Mercury and in fact, went out of his way to make it different enough from Gemini minus TLS so as not to confuse things any more.
Next up, no one is stopping anyone from making Gemini sans TLS, except for a backlash from the community for breaking Gemini. The specification demands TLS, so TLS it is. Yes, I agree, it would be trivial to make TLS optional, but no, it is not that simple to just accept TLS and non-TLS on the same port. If it's that simple, it should be trivial to take an existing Gemini server and patch it in, right? So ... do it, make it available for people to experiment with (but I won't hold my breath on seeing it any time soon).
Also, there was a decent sized minority that wanted TLS eliminated from Gemini, but for two conflicting reasons. The first group wanted it optional with various hacks to make it work (gemini: defaults to TLS, how do you signal not to use TLS with a link?) and the second group wanted to replace TLS with some theoretical better and yet simpler scheme they just read about but didn't want to do the work of implementing it. I do talk about the silliness of adding optional TLS support to gopher:
— Why adding crypto to gopher isn't that easy
But as I said, do a proof-of-concept. Show us something. Stop talking, and Just Do It!
🚀 stack [OP] · Jan 09 at 18:38:
I do like Spartan! The query protocol is different and I can't quite remember what it would take to do a simple game like Wordle. But yes, for gemlogs -- or is it spartalogs -- it is perfect.
🚀 stack [OP] · Jan 09 at 18:43:
@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.
+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]