On Mon Sep 21, 2020 at 3:04 PM EDT, Alex // nytpu wrote:
> As an additional question, if I was writing a more advanced gemini
> client, should I validate cert chains if they're availaible or only use
> TOFU on the fingerprint and ignore chains entirely? The spec just says
> to validate however you want, but what's the community's recommendation?
Coincidentally, I just finished a TOFU implementation in my client which
I'm relatively satisfied with. To answer your question directly, I chose
to disregard the certificate chain and *always* use TOFU. I don't think
the CA cabal is something Gemini needs to get used to supporting.
In more detail, the TOFU algorithm I decided to use is:
1. On startup, the client loads a list of known hosts from
~/.local/share/gmni/known_hosts (adjusted per XDG basedirs as
appropriate), which is a plaintext file where each line is one host,
with the following attributes in order, separated by spaces:
hostname fingerprint-algorithm fingerprint expires
fingerprint-algorithm is always "SHA-512"; if it's not, this
known_hosts entry is discarded. The fingerprint is the SHA-512 digest
of the X509 certificate, and expiry is the Unix timestamp of the
certificate's notAfter time.
2. Upon receiving a request to validate a certificate:
A. It confirms that the current time is within [notBefore, notAfter].
If not, the trust state is INVALID, GOTO 3.
B. Computes the fingerprint.
C. Consults the list of known hosts for a matching host. If not
found, the trust state is UNKNOWN, GOTO 3.
D. If a matching host is found, and the fingerprint matches, the
trust state is TRUSTED. GOTO 3.
E. If a matching host is found, and the fingerprint does not match,
the trust state is UNTRUSTED. GOTO 3.
3. If the trust state is TRUSTED, proceed with the request.
4. If the trust state is UNKNOWN, display the fingerprint to the user
and ask them if they want to trust this certificate, now or always.
If always, another entry is written to known_hosts.
5. If the trust state is INVALID, the user is told about the issue and
given the option to continue (but not to update known_hosts).
6. If the trust state is UNTRUSTED, the user is told so and the request
is aborted. The user must manually intervene in the known_hosts file
to continue.
Code is here:
https://git.sr.ht/~sircmpwn/gmni/commit/02f6af661513683f0c6c1465c5ff1dd8f03a30c9
---
Previous in thread (2 of 5): 🗣️ acdw (acdw (a) acdw.net)
Next in thread (4 of 5): 🗣️ colecmac (a) protonmail.com (colecmac (a) protonmail.com)