-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
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/
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.
2023-12-28 · 5 months ago · 👍 michaelnordmeyer
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.
@Acidus Maybe also make this service make itself check the TLSA records if there are any, and if you build a gemini client, make it check tlsa records of the validator every time they expire, and have it have TLSA records?
Yes, I realize it's not obligatory for you to set a TLSA record, but I guess this might be helpfull if people like the idea.
@jmjl That's a neat idea. I'm not too familiar with TLSA, DNSSEC, and DANE, but this is a chance to dig into them
-- Response ended
-- Page fetched on Sun May 19 15:07:12 2024