TLS Questions: CAs and Tofu
I'm working on a Gemini client (cuz we clearly don't have enough) and have a few questions regarding TLS:
First, how common are CA signed certificates in the Gemini verse? My understanding is that most servers use self signed certificates nowadays.
Second, for TOFU, is there any problem of accepting a certificate different from the one that was first seen, but provides the same public key (and therefore was signed by the same private key)? I want to say no, and it'd be convenient for when a server needs to replace an expiring certificate, but I want to make sure I'm not missing anything.
Feb 24 · 2 months ago
11 Comments ↓
You're correct that MOST servers use self-signed certificates, but there are enough servers out there that use CA-signed certs that you should keep it in mind as a possibility (for example, sdf.org does this). I believe that checking the public key would be safe enough, and is something I have done in the past, but if someone else knows better please defer to them.
It generally makes more sense to pin to the public key instead of the certificate, for the reason you outlined. At least, that's the advice I've been reading for implementing certificate/key pinning.
The consensus for self-signed certificates in gemini seems to be to make them never expire (or as close to that as you can), so whether you use the certificate or public key it doesn't matter.
Any certificates signed by a respectable CA will have a short expiration date though, so pinning to the certificate will cause problems with those (I'm sorry I can't answer your first question about how common that is, but I believe it's at least non-zero).
If your intention is to do TOFU on CA signed certificates, then I think you'll have to pin to the key and not the certificate. If you're intending to verify certificate chains if it's not self signed, then you could probably get away with pinning to the certificate (but I can't think of any advantage that would give you)
I am of the (controversial) opinion that you can just ignore the server certificate issue altogether. When we have banking or anything of importance here, sure.
Client certificates are great for session tracking for games.
🚀 lars_the_bear · Feb 24 at 15:48:
@stack : Hah! Since browsers do little to nothing to check or report certificate validity, banks could self-sign also, for all the difference it would make.
🚀 ColonelThirtyTwo [OP] · Feb 24 at 16:55:
Thanks for the info! My plan was to use TOFU if it looked like a self signed cert or go through the usual CA flow if not.
I haven't looked at too many Gemini certs yet but at least geminiprotocol.net seems to have a non-"infinite" lifetime so I think it's worth handling
For TOFU, I recommend also checking if a newly provided certificate is signed by a previously trusted public key, and if so transferring trust from the old key to the new one. This allows sites to seamlessly switch to a new key, in case they fear the old one may be(come) compromised or the encryption outdated.
🚀 ColonelThirtyTwo [OP] · Feb 24 at 20:26:
@mbays: is there a mechanism for that? From what I can tell, x509 certs can only have one signature, which for a self signed cert must be with the public key that is provided.
@ColonelThirtyTwo Right, this would be instead of it being self-signed.
I observe the type of trust for capsules by changing the security icon when using TOFU, PKI or DANE. I can say that Let’s Encrypt is used and is not uncommon. Use Trust Anchors for your trust db (a combination of Subject, Public Key and Name Constraints).
There are a few things that can be done. One is to ensure that you can view the certificate (and the hash of the certificate), in case you want to verify it independently. Another (a bit more complicated, but possible) is to use an extension that indicates that one certificate supersedes another; both the old and new certificate need to have this extension and the same root certificate in order for this to work, though; if the root certificate also changes then it must be verified independently like I had previously mentioned.
DANE is also good to have, although it will not be secure unless the DNS is secure.
You can still have multiple methods and configuration options if you want to, or omit some for a simpler implementation if you do not need all of them.
I think it is reasonable to make the security icon to indicate which kind of certificate validation is being used; in addition to TOFU, PKI, and DANE, there might also be one that specifies matching a exact certificate specified by the user for that domain.
Using TOFU only for self-signed certificates will not work if they have a self-signed root certificate which is used to issue another one to themself (there are some reasons to do this). If the icon is used to indicate the security type, then you could do use TOFU if none of the certificates in the chain is known and PKI and DANE are not available (or are disabled by the user), and the icon indicates this. Due to possibility of reassignment of domain names, you might want to use TOFU even if DANE is available (which might be configurable by the end user; DANE will then be used together with TOFU).
@zzo38: I have a pop-up on the icon with various security details. And the algorithm is like here:
— bbs.geminispace.org/s/Gemini/26311
I think re-signing with TOFU _is_ handled since it uses the root signing key in the Trust Anchor hash.
There are many rough edges on the UI side though, like overriding trust is manual and for some cases impossible :/