💾 Archived View for rawtext.club › ~sloum › geminilist › 005748.gmi captured on 2023-09-08 at 17:14:04. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[spec] Certificate trust

Côme Chilliet come at chilliet.eu

Sun Feb 28 19:27:26 GMT 2021

- - - - - - - - - - - - - - - - - - -

Hello,

I have been using lagrange for a few months to browse Gemini, and I realize that I’m already making a habit of ignoring certificate mismatch warnings, and blindly trusting any certificate that shows.

The certificate trust is one of the weak point of the current specification I think, and it would need to be clarified.

Firstly, there is the idea of TOFU, but it does not say on which part of the certificate the TOFU works (some people consider it’s the whole certificate, some only the fingerprint), and it does not say how much the certificate needs to be valid (I’ve seen on the ML some people considering that a wrong domain in a certificate and a past expiration date should be ignored by clients). Reading the specification it appears that it recommends using fingerprint and to consider past expiration date invalid.Secondly, there is the good old CA system, nowadays mostly using letsencrypt. It seems badly supported in most clients which still use TOFU in this case and will complain at each renewal.A third possibility I think would be to use DANE and base validation on the DNS system, but I’ve not seen anyone advocating this, is there anything wrong with that idea?

I’m failing to see how TOFU can provide any security, especially if there is no way to announce a renewal by sending both new and old cert or something, there is a MITM possibility at each renewal. The only TOFU example I’ve seen cited is openssh, which seems offtopic because you usually do not ssh into random machine on the internet by following links like you do with Gemini.

Côme