💾 Archived View for midnight.pub › posts › 1256 captured on 2024-03-21 at 16:00:45. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
-=-=-=-=-=-=-
Barkeep, a White Lady if you please.
It looks like the SSL cert for midnight.pub is expired. Hopefully ~m15o is aware of it.
Gopher is very happy, though, just saying.
Oh, you resilient burrower :)
I know this is only tangentially related to the post but, am I the only one who is bothered by how little concern is given by gemini to certificate validation? From the sacred scripture:
Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first-class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or set up a Let's Encrypt cron job, just make a cert and go).
It just allows clients to not do any validation whatsoever, and just *recommends* doing TOFU. This is horrible. Not that CAs would be much better of course, but shouldn't the spec at least require clients to be extremely upfront to their users about the (very real) risks of MITM attacks? Most clients just give the user a choice of whether to permanently or temporarily trust the certificate, which simply requires answering y/n. Now this is great from the user's perspective, of course, since it requires very little work, but what if someone is actually MITMing them? Even if they've already previously explicitly trusted another certificate, their client is at worst going to give them a warning about potential wrongdoing (the better the client, the spoopier the warning) which the user is promptly going to ignore (yet another server admin that carelessly changed their certificate! Oh well, let's carry on…) And you better not send anything sensitive through that TLS connection at any point thereafter, because by then it's no better than plain TCP.
The advantage of CAs is that the (admittedly very hard) job of validating certificate ownership is offloaded to an ostensibly trustworthy third party. However, given that CAs really aren't an option when it comes to gemini, TLS doesn't really provide that much security unless the user is encouraged to do some validation on a best-effort basis (attempting to contact the site owner, cross-checking with their friend's certificates, etc.) I guess it's still somewhat better than TCP, in that the attacker does have to actively intercept the connection instead of just passively listen, but you shouldn't ever assume a potential attacker is going to be deterred by that – because that's when disaster strikes.
As an aside, as if the DNS and CGNAT tyrannies weren't enough, CAs add yet another layer of centralization and another hoop to jump through for server admins. There are other methods of automated validation, like web of trust or whatever, but one of the tenets of gemini is simplicity, and those methods are, well, anything BUT simple.