💾 Archived View for rawtext.club › ~sloum › geminilist › 005749.gmi captured on 2023-11-14 at 09:53:12. Gemini links have been rewritten to link to archived content

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

[spec] Certificate trust

Solene Rapenne solene at perso.pw

Sun Feb 28 19:32:53 GMT 2021

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

On Sun, 28 Feb 2021 20:27:26 +0100Côme Chilliet <come at chilliet.eu>:

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

Hi,

I suggested something on IRC a while ago, I'm not sure this wouldbe a good idea but I'll share it here.

Instead of TOFU, 2 mecanisms could be used:

1) Check chain of trust of the certificate, with let's encrypt andother provider (they are not alone anymore) it's easy to get a validcertificate

2) If 1 is invalid, let's (introduce something new here) check ifDNS doesn't have a TXT field with the certificate fingerprint andsee if it matches the current one, accept if OK

3) if 2 found a TXT that doesn't match, tell the user, if it matches,accepts, if no TXT, TOFU?

The fingerprint published in DNS is already done for SSH fingerprintusing a SSHFP field. This allows to have a third party check. Iagree it's not absolutely perfect but, it gives the opportunity foran extra check.

This wouldn't have any backward incompatibilities because it's upto the client to implement it, if a person hosting a gemini serverdoesn't want to host it, just do TOFU as usual.