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

["Michael Ströder" <michael@stroeder.com>]

On 2/24/21 10:16 PM, Juliusz Chroboczek wrote:
> Good security relies on carefully balancing security with usability:
> if a security protocol is not usable, people will use insecure
> alternatives instead.
Yes.

> 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.

This comparison is invalid:

1. Your self-signed certs are transient and not written to disk. TOFU
does not work because every Galène restart results in a new key pair
being generated rendering your known-hosts (its equivalent in browser)
useless.

2. The browser vendors dictate how to use TLS. There's a tendency in
recent browsers to make it harder to accept invalid server certs. Like
it or not this will get harder in the not so far future. So usability
will suck if the admin does not do the right thing.

> 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.

As said: You and me are not the ones to decide what browser will provide
as UI to the end users.

And whoever is capable of setting up Galène and deal with the end user
support fallout caused by NAT traversal and paranoid firewalls will also
manage to get a Let's Encrypt cert.

>> 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?

I'm not that much concerned about attacks in this case. I'm more worried
that such an automatic fallback makes it harder to find the real
configuration issue.

"It works for me with openssl s_client -connect supergalene:8443, no
problem, but I had to disable the CA check in the monitoring..."

Believe I saw so many situations like this over the years. Or just look
at TLS issue "solutions" on stackoverflow (sigh!). IMO fail early, fail
hard is almost always the better approach.

And as I understood you so far your aim was also to keep the
implementation itself simple.

>>> 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. 

How should the end user decide whether there's an active MITM attack
going on or whether the admin restarted Galène?

> If you catch your ISP doing an MITM, you can save the spoofed
> certificate and drag them to court.
We have yet to see even more serious attacks going to court. But that's
getting off-topic...

>> 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.

Right. But this should be simply subject of local config (cert and keys
installed by the admin). Don't fall into the trap having to revise such
a decision all the time.

Ciao, Michael.