Closed khyew closed 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 :)
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.
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!
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.
Mumble users are prompted to accept the certificate with an innocuous-looking dialog box and it's impossible to distinguish between servers where a self-signed certificate being presented is normal, or is exhibiting a failure case, or the connection is actively under attack by a MITM.
Murmur operators cannot distinguish between, or be notified of, a failure in certificate loading without trawling through logs. In multi-node cloud environments, the preferred resolution for software that cannot validate its initial parameters is to simply die; orchestration systems can easily read these failures and perform rollback actions or notify the on-call engineer.
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.