mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.41k stars 1.12k forks source link

Murmur should fail to start if there are problems with certificate loading #3341

Closed khyew closed 6 years ago

khyew commented 6 years ago

The current behaviour for a Murmur server that is configured to load a custom certificate is to attempt to load and verify the certificate and, if that fails, fall back to using self-signed certificates.

The default behaviour should be changed so that the server instead crashes (with an appropriate error message) if certificate loading is attempted but doesn't succeed.

For server operators that rely on end-to-end encryption, falling back to a self-signed certificate is dangerous.

I cannot imagine a situation where a Murmur operator intentionally elects to use a CA-signed certificate, yet is ok with silently falling back to a self-signed cert and sacrificing confidentiality and integrity in exchange for uptime. At the very least this fall-back behaviour should be an option, and it should definitely not be the default.

mkrautz commented 6 years ago

I believe this is the behavior of 1.3.0 (development snapshot) already:

Call to loadSSLSettings: https://github.com/mumble-voip/mumble/blob/f6ba3a5/src/murmur/Meta.cpp#L378-L380

Cert/key loading in loadSSLSettings: https://github.com/mumble-voip/mumble/blob/f6ba3a5/src/murmur/Meta.cpp#L464-L517

I you believe this not to be the case, please say so :)

mkrautz commented 6 years ago

For server operators that rely on end-to-end encryption, falling back to a self-signed certificate is dangerous.

Just to be clear, Murmur does not provide end-to-end encryption between individual users. The server acts as a conduit.

khyew commented 6 years ago

Looks like the change in how it's handled in 1.3.0 will resolve my issue. Thanks for pointing that out :)

Just to be clear, Murmur does not provide end-to-end encryption between individual users. The server acts as a conduit.

Err, yes-- "end-to-end" was a misuse of the terminology there. My bad!