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.orgis set to expire in a few days (I run my own CA as an experiment).
-spc