Question: when I see those flags/warnings that say that a site' s certificate has changed... what am I supposed to do? Is there a repository of places where people can register and say "yep, that was me who changed it" or "nope, I didn't change my certificate, so watch out" ?
1 week ago
Wait, wouldn't any requests involving PII have to go through the address bar? I.e., how could I possibly make a purchase privately through the gemini protocol without putting the financials somehow in the header request? Or am I misunderstanding how the cert/SSL works? · 2 days ago
Kinda wishing I could thumbs-up the exchange between @drh3xx and @jsreed5 about TXT records, DNS, and serving capsules over a bare IP. I too have no idea what's so critical about cert validity. I guess if this protocol somehow magically scaled to the point where people needed to put personal data, financials, or make purchases on it. idk. If anyone knows of that sort of thing on gemini, I'd be curious to see how it works. · 2 days ago
Thanks to all for the informative responses, especially @m0xee and @jsreed5 . I guess a followup question is: under what conditions does seeing this flag constitute a warning to steer clear? If the cert doesn't expire for another year? 3 months? · 2 days ago
So to interpret... when I made the recent connection, the browser didn't see the original cert that it had TOFU'd, and so it threw up a flag. It said the cert (not sure if the new one or the old one) "would have expired 3 weeks from now". I'm guessing the old one "would have expired", and thus we can reasonably guess that it was the gem.sdf.org maintainers who were on the ball and changed the cert 3 weeks ahead of time. · 2 days ago
@jsreed5 I hadn't specifically thought about capsules served on IP with no FQDN. As an optional standard though it wouldn't result in any real change as described but those that adopted the record would allow folks with supporting clients to have increased confidence.
I guess it could be seen as fragmenting the ecosystem though which is likely undesirable (just threw the idea out there).
Most capsules I've seen are games, social or gemlog style affairs rather than distribution of executables or payment/IRL ID processing etc... though so, is a high level of confidence in the certs validity even that critical? · 1 week ago
@drh3xx My only problem with using TXT records for cert validation is that it ties Gemini to DNS. Some capsules don't use domain names, and those capsules would never be able to validate their certs. A standard based on that might cause clients to unfairly flag capsules without DNS records as unsafe.
You clarified that this could be an optional standard. A compromise might be something along the lines of "A server MAY validate its certificate using a TXT record, but clients MUST NOT flag a certificate that does not have a corresponding TXT record as unsafe." · 1 week ago
More DNS abuse could be an option to confirm valid cert if the community could settle on an OPTIONAL standard; most likely for a TXT record format. No need for CAs, those that just want to TOFU still can and those wary can be confident of a certs legitimacy if the record is in place. · 1 week ago
(2/2)
The Web's solution is to use certificate authorities (CAs). They issue root certs that sign individual site certs, allowing users to verify verify that a new cert belongs to the same owner as the old one. Gemini capsules tend not to use CAs, instead relying on "trust on first use" (TOFU).
Is a changed cert dangerous? On the Web, people rely on SSL for things like payments, sending PII, and so on, so unexpected cert changes can be dangerous. That type of sensitive activity doesn't happen on Gemini, so people don't worry about it. · 1 week ago
My answer is too long for one comment and my Gemini client doesn't support Titan, so I'll split it into two.
(1/2)
An SSL certificate is used to encrypt traffic between your client and the server. Its security is dependent on only the server owner having the correct private key for the cert. A cert is a capsule's "fingerprint."
When a cert changes, new data is now being used for encryption; the capsule's "fingerprint" has changed. It may be that the capsule owner legitimately installed a new cert, but it's possible your requests are being intercepted and someone else is fraudulently accepting them. Accepting a new cert is therefore a trust problem. · 1 week ago
Tell them to stop trying to force webshit into Gemini.
Gemini is TOFU, not trust on authority.
If they made a self-signed certificate instead of pretending they need the authority of LetsEncrypt this would never happen. · 1 week ago
In case with some well-established resource, you might get notified that the cert is about to expire and for example next week it would get updated — so you won't be puzzled by the warning. But if you're just visiting someone's gemlog, transmit no sensitive data and no one would have reasons to impersonate that person and hijack that capsule, it's generally safe to ignore the warning and accept the new cert. · 1 week ago
In Gemini there is no established centralised infrastructure to verify the certificate's authenticity, we follow TOFU — trust on first use principle, when you access the capsule for the first time you accept the certificate unconditionally, if on your next visit you get notified that the cert changed, but it's still a long way from old one's expiration, that might mean that something fishy is going on… or not — the owner/operator might have other reason to update the certificate. · 1 week ago
honestly I usually just open the page info in Lagrange and hit trust site... · 1 week ago
Sorry if this is a newbie sort of question. I don't work in tech but I like the idea of a smolweb so I do want to figure out how to navigate it wisely. · 1 week ago
context: I tried to follow the link to the starship troopers gemlog on sdf that was posted here recently. gem.sdf.org thew up a warning that "this certificate would have expired 3 weeks from today" ... what am I supposed to do with that? · 1 week ago