💾 Archived View for bbs.geminispace.org › u › gemalaya › 12931 captured on 2024-05-10 at 14:00:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
Re: "Seriously, how do I check if the server fingerprint is the..."
There's a tool out there that generates a database of gemini server certificates with their fingerprint, can't remember the name of the repo. If i find it i'll put the link here.
2023-12-22 · 5 months ago
@nikhotmsk Found the tildegit repos:
— https://tildegit.org/nervuri/trust-stores
— https://tildegit.org/nervuri/trust-store-generators
Hope this helps.
👤 nikhotmsk [OP] · Dec 23 at 04:19:
Cool. I am writing an article about gemini, will put the link
👻 mediocregopher [...] · Dec 23 at 08:33:
@nithotmsk I suspect most people don't actually go to the trouble of checking the server fingerprint. I've gotten in the habit of just always accepting it. Even if someone were to mitm me, what could they really do with that? It's not like HTTP-world where you can get your password phished.
And even if they got an SSL fingerprint, they could do little with it, as you can't really reuse it for other things, as there's a little exchange), I think it's not possible, if it is please contact me, I have to make a tool that will have the real private key and rewrite requests for certain things internally. (Relaying things in an easier way, and allowing having bubble like software running in a subpath of a path, having the full path be handled by a little multiplexer like tool), I'm not sure if I will do that, but if I can, it will be pretty nice.
Is there a reference list or something?
[Correct me if my opinion is wrong] I think the idea of Gemini is __not__ to have any third party confirming which cert is for which server... because this third party will eventually become an 'authority'... and then this authority will eventually become malicious... and then eventually this authority will start a censureship... and we will come back to the current state of the big web...
To answer your original question: I look at the previous server certificate and if it is already expired - normally I would accept the new one - it is obvious why it is changednow. After accepting the new cert I look at the server content - trying to assess if I am still on the desired server... Plus some server owners usually announce in advance "I will change my cert at this and this date", which info I appreciate - this makes me confortable accepting new cert later on :)
I admit all of this is not perfect. These are the risks of Trust On First Use certificate management in Gemini :)
Having looked at how the popular clients handle when a capsule sends a cert different than the original TOFU, the UI's are absolutely terrible!
Most show no info about the new certificate, so even if you wanted to compare what you are getting with what someone else is getting, you can't do it easily. Some provide a "fingerprint" of the new cert but many don't use that terminlogy, and they don't tell you what input was used to create the fingerprint, or what hashing algorithm was used. So its even viritual impossible to ask someone out-of-band what "fingerprint" they see, unless they use the same client.
Lagrange: Have to click "Page Information", then "Copy Fingerprint" then paste it somewhere. Fingerprint is the SHA256 hash of the DER encoded version of just the public key, extracted out of the new certificate.
Elaho: Just says "Server Certificate" and shows the MD5 hash, with ":" separators, of the DER encoded version of the entire new certificate.
Kristall: Shows the fingerprint directly, as the SHA256 hash, with ":" separators, of the DER encoced version of the entire new certificate
Amfora: Shows no information about the new certificate at all! Just mentions the expiration date of the previous cert. Under the covers is using the SHA256 hash of the DER encoded version of the just the public key, extracted from the new certificate
This is... a pretty horrible experience all round. Client's so poorly communicate information about the new cert, in any useful way that the user could then use that information to verify if the change is "valid" or not. , The only "good" news here is the infinitesimally small chance that a TOFU warning is someone MITMing you. Or that we have a bit of a monoculture when it comes to clients, so someone could just say "Lagrange says the fingerprint is X, what do you see?"
🕹️ skyjake [mod...] · Dec 25 at 15:26:
@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.
@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 · Dec 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.
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?