💾 Archived View for rawtext.club › ~sloum › geminilist › 002756.gmi captured on 2020-09-24 at 02:54:13. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Drew DeVault sir at cmpwn.com
Mon Sep 21 21:09:21 BST 2020
- - - - - - - - - - - - - - - - - - -
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 whichI'm relatively satisfied with. To answer your question directly, I choseto disregard the certificate chain and *always* use TOFU. I don't thinkthe 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