To all Gemini client authors: how do you handle TOFU authentication errors?
I'm looking to write a client soon and I want to get a general feel for what the de-facto standard is for TOFU authentication. More specifically, what does your client do when authentication fails? Do you use DANE? Do you use CAs? Do you simply trust the next valid certificate? What does your client do, and what are your justifications for it?
Oct 06 ยท 8 days ago
2 Comments โ
๐ skyjake [mod...] ยท Oct 06 at 09:04:
what does your client do when authentication fails?
Lagrange terminates the connection immediately when it detects that the server certificate is not the trusted one, and shows an error message.
Do you use DANE?
No. I've considered it, but it seems too complex and not commonly used enough to be worth adopting. Integrating an external tool to the client could be an option, to perform the DANE validation externally when required.
Do you use CAs?
Yes, you can point Lagrange at a file containing trusted CA root certificates, and server certificates signed with those are trusted automatically, bypassing TOFU. This is mostly provided as a convenience if one happens to already have a CA-issued certificate that is also used for Gemini.
Do you simply trust the next valid certificate?
The user has to manually apply a "Trust" action to assign a new certificate as the trusted one. The assumption is that the user has been made aware of the certificate change beforehand, perhaps via a pre-announcement on Antenna, etc. Lagrange allows copying the certificate fingerprint so one can compare it manually.
There is one exception, though: if the new untrusted certificate has been generated with the same private key, it will be automatically trusted. This is because cryptographically both certificates must have been generated by the same person/entity that has access to the key in question. (Assuming the key hasn't been leaked, of course.) This is again for convenience, so fixed-duration certificates can be used without bothering everyone periodically about certificate changes.
๐ mbays ยท Oct 06 at 17:03:
I like to recommend more generally trusting a new certificate if it's signed by the private key of the previously trusted certificate, even if the key it's signing is new. That gives a way for capsule owners to smoothly swap out a key, e.g. because the encryption is out-dated. My terminal client diohsc implements that; it always asks the user when the cert changes, but defaults to acceptance if the old cert had expired or in the case above.
Source