💾 Archived View for bbs.geminispace.org › s › Geminispace › 13128 captured on 2023-12-28 at 15:16:09. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I added a "Certificate and Key Validator" service to Kennedy. This helps you figure out if a certificate/key change on a capsule is from a innocent change by the capsule owner, or a possible MITM attempt. Read me here:
gemini://kennedy.gemi.dev/certs/validator/
kennedy.gemi.dev/certs/validator/
If I ever build a Gemin client, I would probably build something like this into it. (with a perference to disable). As in, if you access a capsule and it's cert/key is different, my client would check with this service to see what it got.
1 hour ago · 👍 michaelnordmeyer
🍵 michaelnordmeyer · 57 minutes ago:
What do I do if there's a MITM faking a certificate, and I've never been to gemi.dev? Then the certificate and content of the checker could have been faked as well.
true. This is just trying to solve the "something changed, is it evil?" problem. I'm not trying to bootstrap trust from first principles.
One way to bootstrap trust would be to distribute lists of public key or certificate hashes with gemini clients. While that might work for now, (~3000 casules) its essentially the Certificate Revocation Lists (CRL) approach browsers did, which has a ton of problems (scale, rate of change, etc.)
A middle ground would be that client creators like @skyjake could run their own public services, and bake the fingerprint for that service into their client.
To be clear, this "Ask a 3rd party what they got" approach has issues as well. Like OCSP, it discloses what hosts you are visiting to a 3rd party, which is a privacy issue. Of course, it's opt-in, unlike OCSP.