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.
At this point, there's little or no use of Gemini for anything sensitive, and we haven't yet reached the point where it's profitable for ISPs to MITM Gemini streams to inject ads.
Which is all to say, you're 100% correct, but what's the alternative? A lot of clients are pretty lax about TOFU handling for server certs, but e.g. Lagrange at least warns you that it's changed. It could be more stern in the warning, but the truth is that the way Gemini server admins mostly use certs is not really compatible with TOFU - they don't use long-lived certs, and they don't really provide a way to know when a cert change is legitimate. We (people on the old mailing list) originally foresaw the Gemini TOFU use of certificates working like SSH certs... but it hasn't worked out that way.
The onliest thing I see to do without sacrificing compatibility is to set up multiple certificate "observatories" in different locations that you can query when a cert changes. Then you can answer at least the questions of "is everyone seeing this same changed cert?" and "when did this cert change?" As well as, for new sites, "is this the first cert anyone ever saw for this site?"
I think there are some good points here, but I haven't tinkered with gemini since shutting down tanelorn.city a couple of years ago.