Thoughts on TOFU
Sean Conner
sean at conman.org
Fri Jun 12 23:50:19 BST 2020
It was thus said that the Great Felix Queißner once stated:
> Hey List!
>
> While planning out the implementation of TOFU for Kristall, i noticed
> something weird:
>
> Quoting the spec:
> ----------------------------------------------------------------------
> TOFU stands for "Trust On First Use" and is public-key security model
> similar to that used by OpenSSH. The first time a Gemini client
> connects to a server, it accepts whatever certificate it is presented.
> That certificate's fingerprint and expiry date are saved in a persistent
> database (like the .known_hosts file for SSH), associated with the
> server's hostname. On all subsequent connections to that hostname, the
> received certificate's fingerprint is computed and compared to the one
> in the database. If the certificate is not the one previously received,
> but the previous certificate's expiry date has not passed, the user is
> shown a warning, analogous to the one web browser users are shown when
> receiving a certificate without a signature chain leading to a trusted CA.
> ----------------------------------------------------------------------
>
> This means that trust in a server is lost as soon as a certificate is
> expired and a subsequent renewal of the certificate with the same
> private key is the same as visiting the host for the first time. But
> when i refresh my server certificate before it expires (which is
> recommended), we will have the situation that the client will not trust
> the server anymore (same situation as when an attacker is doing a MITM
> attack) which i think is not a good situation.
>
> My proposal for both server certificates is the following:
> An endpoint stores the public key of the servers certificate as well as
> the host name. As long as this host continues to use the same identity
> (pub+privkey), it will be trusted. Certificates that aren't refreshed
> will error to the client, having another pubkey presented will error
> "harder" (as in: this is a possible MITM attack)
>
> The same behaviour could be used for client certificates as well,
> allowing the renewal of client certificates with the same private key
> (which would solve the "how do i have persistent identities")
>
> What do you guys think?
I think that's reasonable, as the client certificate for gemini.conman.org
is set to expire in a few days (I run my own CA as an experiment).
-spc
More information about the Gemini
mailing list