Add working --serveTLS

[ineiti]

Instead of using --noTLS to indicate not to use TLS, changed the flag to --serveTLS. Now:

• if a certificate and a chain is given, --serveTLS is enabled
• if --serveTLS is enabled w/o a certificate, a self-signed certificate is created
• if the remote point starts with https, a TLS connection is established, and the certificate is verified using public CAs used in the system

[ineiti]

Use cases

Currently I see two use-cases, and a third for paranoid people:

1. Use dela behind a reverse proxy with TLS termination
2. Use dela in development environment
3. Use dela standalone with self-signed certificates

For 1. I think we should trust the reverse proxy to do its thing. Of course there are attacks on CAs with rogue certificates where you can have a mitm. If you care about this attack, go for 3. But using TLS-in-TLS seems overly complicated, and IIRC, was one of the problems with the last try to get it to run.

For 2., no TLS is needed. It's development, it should be fast and w/o fuss. Every argument saved in development mode is a happy developer.

For 3., use self-signed certificates and serve TLS with dela. Or set up a reverse proxy with terminating TLS and trust it, but then the reverse proxy could be colluding with your adversary...

So with this PR, 1. and 2. is the default. No TLS served by default, for deployment we use reverse proxies.

If you're paranoid and want to be really sure nobody is interfering with your communication, go for 3.

Serving TLS in dela

Perhaps the arguments could be reduced to --certKey and --certChain, which must either both be given, or none. If they are present, TLS is served. For convenience, we could add a --makeCertificate which writes the keys and the chain in the files given by the other two arguments. But if you're paranoid, perhaps you want to use another tool to create your certificate.

Do we need --certKey AND --certChain?

I'm always lost with certificates and never know which contain the private key and which contain the public key. But I think that --certChain doesn't make sense: when you Join to a TLS serving dela, you have to give the hash of its certificate anyway. So why should you add it? Or is the --certChain for the certificate of the --certKey?

History

In cothority we also started serving TLS in the conodes for the websockets, but this turned out to be complicated with renewing and reloading of certificates. It's still there, but mostly unused.

We kept self-signed certificates only for the node-to-node communication. Which is not ideal, because you need a dedicated port and cannot use a reverse proxy for that. Or at least I never tried.

[ineiti]

After discussion:

By default:

• makeCertificate and listen on TLS

Or one of:

• give --certKey
• give both --certKey and --certChain
• --noTLS to remove listening on TLS

[ineiti]

Done in #280 and #282