Updated recommendations regarding TOFU & TLS

nervuri nervuri at disroot.org
Sun Apr 4 20:02:10 BST 2021

On Thu, 2021-03-04, Drew DeVault wrote:
>Hello! I have recently announced some upcoming changes to my Gemini
>software implementations with respect to TLS and TOFU:
>I've also updated my older TOFU recommendations article to reflect the

A few observations:

1. Not storing the port means that the client can't adequately support
different certs being served on different ports.  You can test with:


2. Not storing the expiration timestamp means that the client can't
issue a less scary warning when it receives a new cert after the old one
expired (or when it's about to expire).

Solderpunk argued in favor of clients using expiration dates, for ex:

> I guess I see the main utility of explicit expiration dates in this
> context as being a kind of promise from the sever admin that "I have no
> plans to do a key rotation for about this length of time".  This means
> that apparent MITM attacks happening at a time when there's a lot of
> validity left can be treated with much higher suspicion.

3. A cert can be renewed without changing its public key, so storing a
hash of the SPKI (SubjectPublicKeyInfo) instead of the entire
certificate means potentially less unnecessary warning messages for
users.  Here's the OpenSSL command to extract the SHA512 hash of the
DER-encoded SPKI:

openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha512 -binary | openssl enc -base64 -A

I used base64 at the end to get a shorter string.

And here's the command one would use to renew a cert without changing keys:

openssl req -new -x509 -key private_key.pem -out new_cert.pem -subj "/CN=example.com" -days 36500

It generates a certificate valid for 100 years using the old key.
Amfora uses the SPKI, so it wouldn't raise a warning about this new cert.

More information about the Gemini mailing list