💾 Archived View for bbs.geminispace.org › u › skyjake › 13008 captured on 2024-07-09 at 03:59:05. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-07-09)
-=-=-=-=-=-=-
Re: "Seriously, how do I check if the server fingerprint is the..."
@Acidus Please describe what you would expect a good UI and UX to be here, and maybe things can improve.
In the end it doesn't matter that much what information the new certificate contains. These are usually self-signed, after all. Ideally the user would already know beforehand that a particular server has changed their certificate when encountering an untrusted one.
2023-12-25 · 6 months ago
🧇 Acidus · 2023-12-25 at 21:04:
@skyjake That's probably a longer blog post. At a minimum, whenever I would suggest that whenever a client is displaying the "fingerprint" of certificate, it should include text explaining what the "fingerprint" represents. Something like:
"The SHA-256 hash of the public key received from bbs.geminispace.org is: ba48d94a...". I would probably truncate the hash, with an option to copy the entire thing. That's obviously a little wordy, and could be streamlined given the context it is displayed. (If shown in a section about the current domain, the client doesn't need to say the domain, etc.)
More generally, when displaying a TOFU mismatch error screen, I would suggest providing specific, concrete steps the user can do. Since this could be lengthy, I'd probably put that in a help doc and link to it. An example of a concrete step would be "Ask a friend to run 'openssl ... | shasum ...'. If the output is ba48d94a... this is most likely a perfectly safe change." Again, that's wordy, but it's specific and actionable.
Asking other people to run a series of piped *nix commands is also a pretty bad experience. To help with this, I'm working on an out-of-band certificate check to Kennedy. Anyone could submit a domain, Kennedy does a live fetch of the cert from server, and displays the "fingerprints" that popular clients would display among other info.
🚀 ElectricalDance · 2023-12-26 at 10:52:
This is a hard problem to solve. It depends a lot on the type of capsule and for most personal capsule its fine to just trust whatever certificate is presented, in a way similar to TOFU, this seems to work in things like Signal or whatsapp.
For the highly adverserial environement we can look for examples on services like VPN, hacking groups, darknet marketplace etc how they handle it: It is usually by signing messages proving they really do own whatever domain they are operating and when they change the certificate they will sign the new one.
Most users anyway ignore it and then are surprised when it turns out there was a malicious version :P.
As I said, it is a trick problem
In many case if you do not want to rely on a centralized authority (with the risk of becoming just like the web) you need to rely on social links between people and reputation (which is another problem on its own).
If you are running a popular gemini service you could have some external social media account (on this bbs, twitter, whatever) where you publish the fingerprint of your certificate and announce when you rotate them.
🧇 Acidus · 2023-12-28 at 19:06:
I just added a Certificate and Key Validator service to Kennedy to try and help solve this problem.
gemini://kennedy.gemi.dev/certs/validator/
— kennedy.gemi.dev/certs/validator/
Seriously, how do I check if the server fingerprint is the correct one? Is there a reference list or something?