[Galene] Re: Heads up: Galène generates self-signed certificates

[Juliusz Chroboczek <jch@irif.fr>]

> Yes, sometimes I have very strong opinions too. ;-)

Good, because so do I.

>> I implemented automatic generation of self-signed certificates if
>> a certificate is not found in the data/ directory.

> it's IMHO not very useful.

I strongly disagree.  Good security relies on carefully balancing security
with usability: if a security protocol is not usable, people will use
insecure alternatives instead.

A case in point: secure telnet (telnet over TLS) was not usable in
practice (it required setting up a CA), so we kept using plaintext telnet;
it's only when ssh came out, which was easy to use (TOFU authentication),
that we started encrypting our traffic.  The self-proclaimed security
specialists were yelling at us that ssh's model is insecure, that there is
no key revocation mechanism, and that we must deploy our own CA or be
tortured for all of eternity.

Same here.  What is really insecure is people trusting third-party
services with their private data.  By making Galène easier to deploy by
non-specialists, we're improving the security of the Internet, even though
we might make it easier to deploy Galène in a manner that the "use
a centralised CA or I kill you" crowd don't condone.

>> 1. If you're currently using a real certificate (stored in data/cert.pem
>>    and data/key.pem), there's nothing to do.  The only difference is that
>>    Galène will notice when you update the certificate, and load the new
>>    certificate automatically.

> Does it also check whether cert and key match, e.g. have same RSA
> modulus?

Yes.  If the moduli don't match, you'll get an error in the log
("tls: private key does not match public key") and the connection will fail.

> That's one of the very common configuration errors. And when
> automatically reloading two files there is a race condition.

If you hit the race condition, you'll get the error above.  Galène will
recover at the next connection attempt.

> If at least one of cert.pem and key.pem are present but it does not
> work, please ensure that it fails early, fails hard. An accidential
> fall-back to a transient self-signed cert has to be strictly avoided.

Currently, we fall back to the self-signed certificate if either of the
two files is missing.  Could you please describe the kind of attacks that
you're worried about?

>> The self-signed certificate uses 2048-bit RSA, which I understand is
>> compatible with all browsers.  I could easily generate ed25519 or P-256
>> instead, if you understand the crypto please let me know what to do.

> A transient self-signed cert gives no security at all

I strongly disagree: a self-signed cert prevents passive attacks.  Your
ISP can perform a passive attack without being noticed, and if you catch
them they can claim they made a mistake.  If you catch your ISP doing an
MITM, you can save the spoofed certificate and drag them to court.

> So it's waste of time to seriously think about the crypto stuff.

A TLS handshake with RSA is some 4kB, EC could bring this down to a few
hundred bytes.  Probably not an issue for Galène, but something to think
about if you're deploying a service over low-throughput links.

-- Juliusz