💾 Archived View for station.martinrue.com › gnuserland › 8336e4db19bd4279a1231fe174cf11dd captured on 2023-04-26 at 14:26:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
-=-=-=-=-=-=-
Our dear #stack or #stacksmith just dropped a bombshell about Gemini and TLS. He is very detailed about his points hence I would take it seriously. However, even though I am the least expert, I still see some advantages using TLS rather plain communication.
-Client like Lagrange makes create an identity (if identity is equal to a certificate) a breeze.
-If the communication is plain and clear, stealing an identity even using "digital signatures" or PGP would be easier.
-PGP doesn't seem more intuitive than TLS Certificates.
-With TLS and CA you can create a restricted access even in Gemini.
By the way having encryption is fine.
gemini://gemini.ctrl-c.club/~stack/gemlog/2022-02-13.notls.gmi
1 year ago · 👍 nightreader, justyb
[1] gemini://gemini.ctrl-c.club/~stack/gemlog/2022-02-13.notls.gmi
@stacksmith: I believe that if you make it optional, a lot of people will not use crypto, not by choice, but by ignorance. In my opinion, it is better to have someone poorly handling crypto vs not handling it at all. I also do believe in choice, but then the choice would need to be 'Do you want to NOT use crypto' (even if I don't see a single reason to disable it) · 1 year ago
There is no value in removing TLS from Gemini. If a client developer is offended by TLS, they can use Gopher/Spartan. Cool thought experiment though I guess. · 1 year ago
@axion: why do you think optional crypto is no crypto at all? I am genuinly interested in your opinion - not just sparring. It seems to me that those who need and understand enough would use it when needed. Those who don't understand - well, all bets are off. And those who specifically don't want it, have the option of not using it when that's possible. If it is optional but good provisions for plugging it in exist, there is a choice. I believe in choice - including easily using a different algorithm if so desired. There is safety in numbers, but some of us make it a point to walk in the opposite direction. · 1 year ago
Optional crypto is as good as no crypto at all. I'm far from thinking there is *any* magic anywhere, and definitely not in certificate management and cryptography, which is my domain of work. You may find the use of TLS shortsighted, but I'm happy the gemini authors are as shortsighted as me then · 1 year ago
What it boils down to is that encryption should be used deliberately, with a full understanding of details, or if you rely on a third party, understanding of who they are. Having built-in encryption seems good, but at the margins it assures that really good crypto will not be added (because what we have is good enough), and on the other end, those who screw it up (due to their own or third-party errors) will suffer. Choice. It's all about choice. Forcing a particular security protocol, like TLS, into the Gemini spec seems shortsited (and if I put my paranoid hat on, menacing). · 1 year ago
axion: with all due respect, _your_ points are bogus. Metadata provides more than enough to opress, and I am not asking anyone to _forcibly remove_ encryption. Just make it optional, so when you need it, you have it. That way you are not misled into a false sense of security. Leaving certificate management to casual client software is plain dangerous if you rely in security - you better know exactly what certificates are, what the pitfalls are, where they are stored, and how to destroy them reliably. If you think you are keeping anything that MUST be private by connecting to some Gemini server with built-in magic, you are not very wise. · 1 year ago
@lykso: A sister protocol is an ideal solution. Spartan is annoyingly different-enough to be different, both in request/reply semantics and extending gemtext with a =: line type (which I have yet to understand). A sister protocol could be trivially implemented on any server, as it just requires no encryption, even in-parallel to normal Gemini. Everything in existence would work as before, and minimalists could enjoy well, minimalism or retrocomputing or whatever. · 1 year ago
@axion 👍 · 1 year ago
I believe TLS is worthwhile in that it (for clients/servers agreeing to use modern ciphersuites) eliminates all passive eavesdropping of the content of the traffic. The threat actor I have in mind are ISPs who datamine all traffic across their networks. While I realize that TLS does not eliminate traffic analysis, I do think it is valuable for the above reasons, regardless of the sensitivity of the content distributed via Gemini. Still, I find stacksmith's challenge to the status quo valuable—I think questions like these will increase understanding of why things are the way they are. · 1 year ago
I'm sorryif my post sounded harsh, that was not my intention. So I apologize. But that does not change the fact that no matter how detailed and/or against the stream the points are, I still think the argument is bogus. · 1 year ago
I like people that have no fear to express their thought against the stream.
I don't see any reason to be harsh when he expressed with plenty of details his reasons against TLS. · 1 year ago
I think most of these points are kind of garbage. Gemini using TLS by default is one of the reason I like it so much. The emphasis on client certificates for account management is great. You can create throw away identities, and still make sure that the information you wish to keep private stays that way. You don't have to live in world where your freedom of secrecy has been forcefully removed. Some things MUST be kept private, so we cannot impersonate anybody. So you will need some sort of account management, with passwords. And then how do you keep that password secret? With TLS... which is now optional, which adds more complexity, and leaves room to screw things up. · 1 year ago
Got to read it all now. Public key would probably the most secure way to access the servers. · 1 year ago
Good article! Very opinionated! But I don't think Gemini's going to change much. · 1 year ago
@stacksmith I mean, we could also just spin up a "sister protocol" to Gemini identical in every way except the TLS (and port number) and give it its own URI prefix to make the distinction easy. I.e., Spartan but with INPUT responses and without "input prompts." Because you've got to negotiate whether or not TLS will be used for the connection somehow, and this seems like the simplest way to do that.
Which is also exactly what's been done with HTTP, so hey: real-world validation that the concept works, right? · 1 year ago
@stacksmith Yeah. I like the "sister protocol" approach a bit better than changing the Gemini spec (for whatever reason), but Spartan itself *does* deviate just enough from the Gemini protocol that it might be an annoyance for developers to write compliant software. (The INPUT response doesn't exist in Spartan, and the "input prompt" markdown element doesn't exist in Gemini.) Changing the Gemini spec to make TLS optional *would* save developer effort in the long run, compared to implementing Spartan as well, so maybe that's the better solution. · 1 year ago
The only change to the Gemini spec is to replace the word 'required' with 'optional' in the TLS section... Not that it's going to happen. We are in a 'thought experiment' territory. · 1 year ago
@lykso: I think it's the perfect solution. Kindof like the web with http vs https. I hope browser writers do both. And yes, there are some valid uses for TLS. But most of the time it's like arriving to a dinnerparty in a tank, and insisting that the hosts pour a new concrete driveway that is capable of supporting tanks. · 1 year ago
I don't think it makes sense to change the Gemini protocol given that Spartan exists and given the use to which client certificates are being put. There also *are* valid use cases for TLS, and I'd hate to preclude Gemini ever being a platform for those sorts of applications. (I also, on principle, like having some assurance that the content I'm trying to convey is arriving to the requester unmolested, trivial though my content may be.)
The solution I like best at this moment is simply normalizing gemini+spartan in a way similar to how gemini+titan has been normalized. Let Spartan be an optional-but-ubiquitous fallback protocol for Gemini servers, out of convention. · 1 year ago
TLS also verifies that your data arrives unmodified and the connection is properly closed. · 1 year ago
Thank you for sharing, it was a great read. · 1 year ago
Client certificates _are_ actually optional; a client works well up to a certain point without a certificate. If server certificates were also... · 1 year ago
There are many great things about encryption and certificates - station is one great example - and so is Spellbinding for that matter. I do wish these were optional. · 1 year ago
The way I view this, of course TLS+TOFU isn't a perfect solution. However, it's the one that brings the most value in practice by leveraging existing software assets and crypto infrastructure. Assuming encryption is desirable, a niche protocol like Gemini would be foolish to roll a custom solution. As the FAQ/Solderpunk puts it, it's wiser to ride on the coattails of bigger players.
Removing TLS from Gemini would change the nature of the protocol drastically—client certificates being a built-in mechanism of TLS is tremendously valuable and neatly solves a bunch of problems, and most importantly without anyone having to write custom middleware to implement it. · 1 year ago
if identity is equal to a certificate
A Lagrange identity is an X.509 client certificate with some local metadata, like the freeform notes text. · 1 year ago