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

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

[Juliusz Chroboczek]

Hi,

While fixing https://github.com/jech/galene/issues/13, I implemented
automatic generation of self-signed certificates if a certificate is not
found in the data/ directory.  In short:

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.

2. If you're currently using a self-signed certificate, you may remove it:
   Galène will notice that there is no certificate, and generate
   a self-signed certificate in memory (the certificate is never written
   to disk, as usual in Galène).

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.

I've tested that my self-generated certificate works with Chromium and
Firefox.  Please let me know if you think there's something wrong.

-- Juliusz

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

[Michael Ströder]

Disclaimer:
Yes, sometimes I have very strong opinions too. ;-)
But my words are definitely not meant as personal offense.

On 2/24/21 8:30 PM, Juliusz Chroboczek wrote:
> I implemented
> automatic generation of self-signed certificates if a certificate is not
> found in the data/ directory.

Hmm, given that

1. it's bad practice to let the user click accept-this-weird-stuff
buttons and

2. that browsers are already making it more difficult or almost
impossible for inexperienced end users to accept bad certs

it's IMHO not very useful.

> 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? That's one of the very common configuration errors. And when
automatically reloading two files there is a race condition.

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.

> 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, not even
TOFU-based. So it's waste of time to seriously think about the crypto stuff.

Ciao, Michael.

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

[Juliusz Chroboczek]

> 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

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

[Juliusz Chroboczek]

>> If at least one of cert.pem and key.pem are present

> 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've changed the behaviour in that case -- we'll fail the connection if
only one of the two files exists.

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

[Dave Taht]

Several notes.

I strongly agree with being able to generate a self signed cert.
Especially if you are operating a server that is off the internet,
it's difficult to get a cert via let's encrypt,
and asking folk to run the openssl command line is just asking for trouble.

The CA authority argument has always smelt of the old key escrow argument, and
I vastly prefer to not register some things with any centralized
authority and explain to potential users that's why it isn't
registered and that the "invalid cert" thing is misleading.

I however wouldn't mind if that there was a command within galene to
fire off the lets encrypt facility if a box is on the public internet
and has working dns. shell out to acme, I think....

On Wed, Feb 24, 2021 at 1:25 PM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> >> If at least one of cert.pem and key.pem are present
>
> > 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've changed the behaviour in that case -- we'll fail the connection if
> only one of the two files exists.
> _______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org



-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

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

[Michael Ströder]

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.

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

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> Several notes.
>
> I strongly agree with being able to generate a self signed cert.
> Especially if you are operating a server that is off the internet,
> it's difficult to get a cert via let's encrypt,
> and asking folk to run the openssl command line is just asking for trouble.
>
> The CA authority argument has always smelt of the old key escrow argument, and
> I vastly prefer to not register some things with any centralized
> authority and explain to potential users that's why it isn't
> registered and that the "invalid cert" thing is misleading.
>
> I however wouldn't mind if that there was a command within galene to
> fire off the lets encrypt facility if a box is on the public internet
> and has working dns. shell out to acme, I think....

Or just use a Go implementation of the ACME protocol:
https://go-acme.github.io/lego/usage/library/

However, since Galene won't persist anything to disk, I'm not sure if
this is actually a good idea; you'd need to get a new cert every time
you restart the daemon, which I'm not sure is a good idea (it will
likely get you throttled, if nothing else).

-Toke

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

[Michael Ströder]

On 2/24/21 10:29 PM, Dave Taht wrote:
> I strongly agree with being able to generate a self signed cert.

That's easy to do.

> and asking folk to run the openssl command line is just asking for trouble.

Really?

> I vastly prefer to not register some things with any centralized
> authority and explain to potential users that's why it isn't
> registered and that the "invalid cert" thing is misleading.

Being one who runs simple shell script CAs for all internal self-hosted
stuff I definitely don't preach using public CAs everywhere.

But I have too much experience to teach people what to do with certs in
browsers and don't want to do that again for external Galène users.

> I however wouldn't mind if that there was a command within galene to
> fire off the lets encrypt facility if a box is on the public internet
> and has working dns. shell out to acme, I think....

Re-reading cert.pem and key.pem for more convenient key rotation is
already great.

But leave the rest to developers of certbot or other ACME clients. IMHO
there is way more important stuff to do.

Ciao, Michael.

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

[Juliusz Chroboczek]

> The CA authority argument has always smelt of the old key escrow argument

Not in this case, I don't think so -- it's just another way for some folks
to make heaps of money.

> I however wouldn't mind if that there was a command within galene to
> fire off the lets encrypt facility if a box is on the public internet
> and has working dns. shell out to acme, I think....

There is a Go library to do that, and it wouldn't be difficult to
integrate.  However, that would require being able to listen on port 443,
which is probably more trouble then it's worth.

As to shelling out, recall that we're supposed to be portable to Windows,
and Windows users are the ones most likely to be confused if the behaviour
is different depending on platform.

-- Juliusz

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

[Juliusz Chroboczek]

> Re-reading cert.pem and key.pem for more convenient key rotation is
> already great.

Cool.

Anyone willing to contribute a (well-tested) hook for certbot to install
keys in Galène?  Essentially, it consists in doing

  cp key.pem ~galene/data/key.pem
  cp fullchain.pem ~galene/data/cert.pem

while ensuring that the permissions are right (galene/400) and that the
modtime is updated.  Since all but one of my internet-accesible servers
are used in production (for Real Work, no less), I'm not too keen on
experimenting right now.

And while we're expressing strong opinions: certbot f*cked up by calling
the cert file fullchain.pem, it should be called cert.pem, while the
current cert.pem should be called certonly.pem.

-- Juliusz