* [Galene] Heads up: Galène generates self-signed certificates @ 2021-02-24 19:30 Juliusz Chroboczek 2021-02-24 19:47 ` [Galene] " Michael Ströder 0 siblings, 1 reply; 10+ messages in thread From: Juliusz Chroboczek @ 2021-02-24 19:30 UTC (permalink / raw) To: galene 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 19:30 [Galene] Heads up: Galène generates self-signed certificates Juliusz Chroboczek @ 2021-02-24 19:47 ` Michael Ströder 2021-02-24 21:16 ` Juliusz Chroboczek 0 siblings, 1 reply; 10+ messages in thread From: Michael Ströder @ 2021-02-24 19:47 UTC (permalink / raw) To: galene 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 19:47 ` [Galene] " Michael Ströder @ 2021-02-24 21:16 ` Juliusz Chroboczek 2021-02-24 21:24 ` Juliusz Chroboczek 2021-02-24 21:44 ` Michael Ströder 0 siblings, 2 replies; 10+ messages in thread From: Juliusz Chroboczek @ 2021-02-24 21:16 UTC (permalink / raw) To: Michael Ströder; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 21:16 ` Juliusz Chroboczek @ 2021-02-24 21:24 ` Juliusz Chroboczek 2021-02-24 21:29 ` Dave Taht 2021-02-24 21:44 ` Michael Ströder 1 sibling, 1 reply; 10+ messages in thread From: Juliusz Chroboczek @ 2021-02-24 21:24 UTC (permalink / raw) To: Michael Ströder; +Cc: galene >> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 21:24 ` Juliusz Chroboczek @ 2021-02-24 21:29 ` Dave Taht 2021-02-24 21:55 ` Toke Høiland-Jørgensen ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Dave Taht @ 2021-02-24 21:29 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: Michael Ströder, galene 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 21:29 ` Dave Taht @ 2021-02-24 21:55 ` Toke Høiland-Jørgensen 2021-02-24 21:57 ` Michael Ströder 2021-02-24 22:02 ` Juliusz Chroboczek 2 siblings, 0 replies; 10+ messages in thread From: Toke Høiland-Jørgensen @ 2021-02-24 21:55 UTC (permalink / raw) To: Dave Taht, Juliusz Chroboczek; +Cc: Michael Ströder, galene 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 21:29 ` Dave Taht 2021-02-24 21:55 ` Toke Høiland-Jørgensen @ 2021-02-24 21:57 ` Michael Ströder 2021-02-24 22:25 ` Juliusz Chroboczek 2021-02-24 22:02 ` Juliusz Chroboczek 2 siblings, 1 reply; 10+ messages in thread From: Michael Ströder @ 2021-02-24 21:57 UTC (permalink / raw) To: galene 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 21:57 ` Michael Ströder @ 2021-02-24 22:25 ` Juliusz Chroboczek 0 siblings, 0 replies; 10+ messages in thread From: Juliusz Chroboczek @ 2021-02-24 22:25 UTC (permalink / raw) To: Michael Ströder; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 21:29 ` Dave Taht 2021-02-24 21:55 ` Toke Høiland-Jørgensen 2021-02-24 21:57 ` Michael Ströder @ 2021-02-24 22:02 ` Juliusz Chroboczek 2 siblings, 0 replies; 10+ messages in thread From: Juliusz Chroboczek @ 2021-02-24 22:02 UTC (permalink / raw) To: Dave Taht; +Cc: Michael Ströder, galene > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Galene] Re: Heads up: Galène generates self-signed certificates 2021-02-24 21:16 ` Juliusz Chroboczek 2021-02-24 21:24 ` Juliusz Chroboczek @ 2021-02-24 21:44 ` Michael Ströder 1 sibling, 0 replies; 10+ messages in thread From: Michael Ströder @ 2021-02-24 21:44 UTC (permalink / raw) To: galene 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-02-24 22:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-24 19:30 [Galene] Heads up: Galène generates self-signed certificates Juliusz Chroboczek 2021-02-24 19:47 ` [Galene] " Michael Ströder 2021-02-24 21:16 ` Juliusz Chroboczek 2021-02-24 21:24 ` Juliusz Chroboczek 2021-02-24 21:29 ` Dave Taht 2021-02-24 21:55 ` Toke Høiland-Jørgensen 2021-02-24 21:57 ` Michael Ströder 2021-02-24 22:25 ` Juliusz Chroboczek 2021-02-24 22:02 ` Juliusz Chroboczek 2021-02-24 21:44 ` Michael Ströder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox