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.
Mar 24 · 6 weeks ago
11 Comments ↓
It is, if you have a way to verify the certificate independently (e.g. if they physically meet you); but TOFU (the common way it is done with Gemini) still provides some security although not as much. Using certificates on both sides can also help, especially if there are secret files; then spies cannot steal your authorization or provide you with the correct files if they are secret and the correct files are known to you but not to the spies (this requires that you have accessed it securely at least once before) (you can then stop requesting files if you suspect being spied on).
🍀 gritty [OP] · Mar 24 at 02:11:
@zzo38 - thank you. I'm still formulating the idea, but it seems TLS plus a user cert might be the safest here in Gemini
The transmission is encrypted if the SSL library succedes and is as secure as the hardware on either side.
If you accept client certificates, likewise, there is no way to forge them, expired or not. You can store them and verify them, or just keep the digest (hash) for verification, as many bits as you like. For games 64 bits of the digest works for me.
I am not sure why anyone cares about expiration, other than there is no way to revoke a certificate other than expiring it.
I am not a tax professional, so be sure to seek the advice of a CPA.
Note that client certificates are not useful for security if it involves things that do not require user authentication (e.g. read-only access to public files). For things that do require user authentication, client certificates are very helpful, and are better than other methods (such as passwords, TOTP, etc). What do you intend to do that you will want to be secure?
🍀 gritty [OP] · Mar 24 at 04:55:
Full disclaimer, I don't know much about security but you answered my question - I was interested in implementing TOTP for a fun Gemini project but it seems redundant and less secure than user certificates.
Multi-factor authentication via TOTP is complementary to certificate-based authentication. It mitigates a stolen client certificate.
Whether it’s worth it depends on what kind of threats you are trying to counter.
Multi-factor authentication via TOTP is complementary to certificate-based authentication. It mitigates a stolen client certificate.
does it really? the one-time password is itself generated from a (different) private key, so you're just adding a second private key to the mix, right?
@lamb-duh, the idea is that the shared key used to generate the TOTP resides on a second device which hopefully won’t get compromised at the same time as the first device.
🍀 gritty [OP] · Mar 24 at 19:03:
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.
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.)