Comment by 🍀 gritty
and to the core of my question, could I securely share a key between client and server entirely in Gemini.
I guess this could be a viable project if the threat is a compromised user cert.
I might try this out, if nothing other than a way to learn totp. bonus if it's useful for Gemini.
Mar 24 · 6 weeks ago
2 Later Comments ↓
My question is what do you mean by 'securely'.
No one else will see it in transit. And it will not be corrupted.
However, there is no guarantee that the receiving party is who you think it is -- only that they have the same certificate you've seen before.
I am not a fan of TOTP but it can improve the odds that the receiver is the same person you've communicated with before and the certificate was not stolen.
However most people TOTP with their phone, so if that was stolen and unlocked it is not very useful.
TOTP is not necessary. Also note that not everyone can or will want to use it, and not everyone has a second device. Also, TOTP does not use public and private keys; it uses a password, which is not transmitted. If someone manages to spy on the communication, then with TOTP the authentication can still be stolen, but only for one minute (which is still better than using a password, since a password can be stolen permanently). (API keys (whether fine-grained or not) are as bad as passwords.) Furthermore, you can make a kind of 2FA with X.509.
Obtaining a copy of a certificate does not enable someone to use it, since they will also need the private key, which is not transmitted. Private keys can optionally be passworded (although you need a client software that supports passworded private keys; I would recommend supporting this if it is not already); the password is also not transmitted, but then using the certificate will need the password as well as the private key and the certificate.
If you allow someone to make a certificate which will be stored on a backup disk or on a computer not connected to the internet, and then use that certificate to issue another one to themself and use that one for authentication instead of the original one, then that can also mitigate compromised or lost certificates since they can easily issue another certificate to themself (and revoke the old one); this also allows using different certificates with different devices.
Using a certificate chain (as I mentioned above) also has another benefit, in case you have a use for such things as fine-grained permissions, temporarily authorizing someone else to act on your behalf with restricted permissions, etc. In this case, the certificate can contain an extension with the permissions for your service, and a permission is only granted if all certificates in the chain are valid and all of them grant the intended permission.
Depending on what your service is, the root certificate might either be the user's self-signed certificate, or your own root certificate for that service which will be used to issue certificates to others (which they then might use to issue further certificates, possibly to themself). If you are issuing certificates to the users, then it should be safe as long as the certificate is issued before the account is created (it can be issued even in a public communication); it is not secure for the service operator to issue the certificate to the user after the account is created. However, to issue certificates to them you will need their public key (but not the private key). It is simpler to just expect the user to create a self-signed certificate, although that avoids some of the benefits mentioned above, but some of the benefits of X.509 are still retained (spies still cannot steal and use the certificate to impersonate you).
(For the Super ZZ Zero catalog service (which is not implemented yet), I intended to do something like the above, to issue certificates to someone before account creation (with the details included in cerificate extensions), and to put permissions if needed (I probably don't need fine-grained permissions for this case, but it would have that possibility just in case). This is Scorpion rather than Gemini, although the same considerations can apply to any protocol that uses TLS. I have partially written a implementation of X.509 in C, although it does not deal with cryptography at all and expects you to specify function pointers to external functions for dealing with the cryptographic stuff (specifically, hashes and signatures).)
However, note that many Gemini client software probably expect the use of self-signed certificates on both sides, although most also allow to import certificates. However, that might be an advanced mode for users who are willing to do that, since some people might not know how to do it.
If you want to, you can still have TOTP as an option for those who do not want to use X.509 for some reason, or in case someone wants to use both for the reasons that some other people have specified, but TOTP and 2FA should not be required nor recommended; X.509 is better. (I would just use X.509 and not implement TOTP, but some people can disagree.)
Original Post
TLS Security Question — I'm thinking of ideas for my next Racket project for Gemini, and I have a question about TLS because I don't know much about it. Question: is it safe to assume the data in transmission between a browser and server is secure here in Gemini because of TLS? The obvious answer seems to be yes, but I may want to rely on this security for my next project and so I'll open to the security professionals here.