💾 Archived View for gerikson.com › gemlog › gemini-sux › TLS-and-its-discontents.gmi captured on 2022-06-03 at 22:46:45. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-05-22)
-=-=-=-=-=-=-
Stacksmith: A Call for a Gemini Without TLS
The TLS requirement of Gemini never really grabbed me. Solderpunk laid out the reason in this gopher post:
Encryption schemes like TLS aim to provide three things: authentication, integrety, and (transmission) confidentiality. Gemini fails to provide two of them.
The problems with TLS on Gemini can be summarized as follows:
This makes server development fragile, and complicates it to little gain.
On the one hand - super simple protocol that’s easy to parse!
On the other - you need to be able to handle the latest crypto.
To avoid the complexities of PKI (via Certificate Authorities), Gemini is ok with TOFU (Trust On First Use), which basically means the client will more or less blindly accept whatever cert comes down the pipe. This can crucially be a man-in-the-middle cert. This means that potentially nothing on a gemsite can be trusted to not be manipulated by the MiTM, including any metadata about the certificate.
Not that this really matters, because most clients don’t show any metadata anyway.
To fully trust a server cert under TOFU, the user must
In addition, many gemsite operators (re-)use certs meant for HTTPS, often provided via Let’s Encrypt (see below). These certs have a short validity, so if you visit many gemsites, be prepared to see the popup about the cert being changed many times. Is it due to cert rollover or a hostile MiTM? Who knows?
The same goes for stuff like PGP keys, and potentially politically sensitive speech, which was a big selling point in Solderpunk’s original proposal to add encryption to Gopher.
So what’s left? ISPs etc. cannot directly read Gemini traffic. But they can see that Alice’s IP has visited Bob’s IP, using a port other than 443. If gemini ever becomes big, the use of gemini on port 1965 itself is a decent fingerprint. Expect ads appearing in your browsing advertising gemini-adjacent products, like ortholinear keyboards and off-grid cabin living.
DANE does seem to be a nice end-run around the need for CA certs. But they are much harder to set up compared to generating a self-signed cert.
Let’s Encrypt is an impressive project. They’ve managed to streamline the issuence of TLS certs for websites, they’re running a “real” CA, and they’re doing it at no cost to the user. Behind LE is EFF and other boosters of the 90s Net vision of pervasive encryption. If everyone encrypts traffic, it doesn’t stand out as much, and we are all safer (for some libertarian values of safer). And of course, mainstream browsers are slowly ratcheting up the pressure by showing scary warning triangles for plain http:// sites.
I resisted getting a CA cert for my website for a long time because I only serve read-only content. The main selling point for such sites from LE was
Confidentiality sounds cool but if you’re not serving sensitive data it’s not that big a deal.
Gemini is largely read-only and specifically designed to be that way. The fact that TOFU negates authentication and integrity makes it even more ironic that it was saddled with TLS.
In retrospect, it would have been nice for Gemini to be usable without TLS, and TLS to either use CA certs or DANE (ideally DANE, to kickstart that a bit). But right now, we’re stuck with it.
I don’t see it as a reason not to use Gemini, but I will continue to point out the inherent uselessness of it going forward.
Björn (ew0k) has already written about this, I suggest reading the following which are coming from someone who knows their stuff:
Your Gemini Browser and Server are Probably Doing Certificates Wrong
────────────────────────────────────────────
→ more posts in the ‹gemini-sux› category
About this category: “All that is wrong with Gemini, or your money back”
Copyright © 2018 - 2022 Gustaf Erikson
[This Page Viewed Best In Any Gemini Client]