I wrote up my client's TOFU procedure into an article here: https://drewdevault.com/2020/09/21/Gemini-TOFU.html I hope that this is useful to other client authors.
On Wed, Sep 23, 2020 at 02:49:05PM -0400, Drew DeVault wrote: > I wrote up my client's TOFU procedure into an article here: > > https://drewdevault.com/2020/09/21/Gemini-TOFU.html > > I hope that this is useful to other client authors. Thank you Drew, this is very helpful. I keep trying to find time to work on a Gemini client and when I do, having well thought out TOFU notes will be great. Brad
Hello Drew, You might be interested in a gemlog post I wrote a while back, with basically the same topic, it's my TOFU recommendations for Gemini. gemini://makeworld.gq/gemlog/2020-07-03-tofu-rec.gmi My recommendations are pretty similar to yours. A few differences: - I don't specify a file/storage format - The cert fingerprint is generated from just the SPKI section of the cert, not the entire thing. See the post for rationale. - The port is also stored (host vs hostname) so that different ports can use different certs - I don't make any distinction between temporary and always trust - I mention SHA-256, but that's just an implementation detail I also noticed that your flow doesn't seem to update the host data if the cert has expired, it just allows the request to continue. I assume that's an error? Or maybe I'm misreading. Would be happy to hear about what you think of my recommendations! I hope they're useful, I've been trying to spread them on Gemini since I wrote them. Cheers, makeworld
On Thu Oct 1, 2020 at 5:55 PM EDT, wrote: > - I don't specify a file/storage format Yeah, it's not necessary for us to standardize, but for what it's worth at least one other client has implemented my known_hosts format and I moved it to a more general location (~/.local/share/gemini), so we have a chance to establish a software agnostic trust store if we so desire. > - The cert fingerprint is generated from just the SPKI section of the > cert, not the entire thing. See the post for rationale. Aye, your rationale is good. Like I mentioned, the reason I hash the whole thing is to match the output of openssl x509 -sha512 -fingerprint, so that it's easier to independently verify the fingerprint. The ability for the server operator to replace the cert with a fresh one with the same PK and have the TOFU entry remain trusted is interesting, but seems fraught with some risk. In any case, I'm of the opinion that operators should never directly handle certificate maintenance in a TOFU system. > - The port is also stored (host vs hostname) so that different ports can > use different certs Good call, I'll think about this. > - I mention SHA-256, but that's just an implementation detail I just went with SHA-256 because I don't expect these files to be hand-edited often and the hash, while longer and more cumbersome, is more likely to be useful for longer. > I also noticed that your flow doesn't seem to update the host data if > the cert has expired, it just allows the request to continue. I assume > that's an error? Or maybe I'm misreading. The first step is to validate the certificate independently of the trust store. If it has expired, it would fail this step. Other things checked here include the valid hostnames, desired hashing algorithms, or anything else you find it useful to validate. Technically we don't even need to store the expiration. So yeah, the known hosts data does not get updated when the cert expires, but the expired cert would not be trusted anyway. > Would be happy to hear about what you think of my recommendations! I > hope they're useful, I've been trying to spread them on Gemini since I > wrote them. Thanks for sharing! I'll add a link to my article.
---