starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

HSTS-like feature to prevent end user from clicking through a TLS certificate warning (Anti MITM) #2747

New issue

Open

opened 2026-02-20 22:11:58 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-20 22:11:58 -05:00

Owner

Originally created by @synsyn-ack on GitHub (Oct 5, 2023).

Context

TLS/SSL Security / Remote Server authentication / Anti MITM

Description

Ideally, the server owner should be able to set a flag server side to force client-side TLS signature verification for a configurable & refreshing period of time (like HSTS).

This would not be intended to prevent all MITM scenarios, as the flag could in theory be unset by an attacker on first connection, but the user would still get a warning of the event.

Screenshot shows current behavior, which should probably remain the default server-side to keep the software accessible (unless you want the user to be able manually cache the untrusted certificate fingerprint first, then enable strict verification every connection post that initial event).

Thanks for everything!

Mumble component

Both

OS-specific?

Additional information

No response

Originally created by @synsyn-ack on GitHub (Oct 5, 2023). ### Context TLS/SSL Security / Remote Server authentication / Anti MITM ### Description Ideally, the server owner should be able to set a flag server side to force client-side TLS signature verification for a configurable & refreshing period of time (like HSTS). This would not be intended to prevent all MITM scenarios, as the flag could in theory be unset by an attacker on first connection, but the user would still get a warning of the event. Screenshot shows current behavior, which should probably remain the default server-side to keep the software accessible (unless you want the user to be able manually cache the untrusted certificate fingerprint first, then enable strict verification every connection post that initial event). Thanks for everything! ![Annotation](https://github.com/mumble-voip/mumble/assets/147119423/8960f2ec-4c6b-4c07-acde-8e17964c3cd4) ### Mumble component Both ### OS-specific? No ### Additional information _No response_

deekerman added the

labels

2026-02-20 22:11:58 -05:00

deekerman commented

2026-02-20 22:12:00 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Oct 6, 2023):

I think before something like this makes sense, https://github.com/mumble-voip/mumble/issues/4544 needs to be implemented. Otherwise, I think server admins will run into issues when they have to renew their certificate.

@Krzmbrzl commented on GitHub (Oct 6, 2023): I think before something like this makes sense, https://github.com/mumble-voip/mumble/issues/4544 needs to be implemented. Otherwise, I think server admins will run into issues when they have to renew their certificate.

deekerman commented

2026-02-20 22:12:01 -05:00

Author

Owner

@synsyn-ack commented on GitHub (Oct 6, 2023):

I did skim #4544, but it seemed to me that it was targeting an issue outside of the scope of ensuring the user not being able to bypass a trusted TLS channel (which is protecting all keys transmitted after that) and into the realm of securing self signed root certificates by cross-signing. This applies to that the domain contacted in the hostname field should always have a trusted certificate assigned to it. It would not pin to more than the hostname defined by the server (and shown in the signed certificate).

HTTP-related, but still decent info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

Ideally for this HSTS-like flag you can rely on the host OS vendor to provide the trusted root & the server operator to provide the trusted leaf certificate + chain to the user (how it currently functions, if you're using TLS via QT's verification), rather than needing to "roll your own" cryptographic trust system (which has bitten other projects with vulnerabilities in the past, and adds a lot of complexity!) that seems to be part of #4544

As far as some of the details, the flag should probably not be the default (as it isn't in many web server implementations, to prevent server operators from shooting themselves in the foot), and should probably be user-clearable per server in the event the of a mess up server-side (like clearing all the offline browser cache for a site in firefox or such).

You can transmit the flag over the TLS channel after the first connection from server to client. You then just have to have the client prevent bypass of TLS trust for that hostname. Eliminates a security risk that most end users won't understand the consequences of clicking through.

Thanks for the reply!

@synsyn-ack commented on GitHub (Oct 6, 2023): I did skim #4544, but it seemed to me that it was targeting an issue outside of the scope of ensuring the user not being able to bypass a trusted TLS channel (which is protecting all keys transmitted after that) and into the realm of securing self signed root certificates by cross-signing. This applies to that the domain contacted in the hostname field should always have a trusted certificate assigned to it. It would not pin to more than the hostname defined by the server (and shown in the signed certificate). HTTP-related, but still decent info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security Ideally for this HSTS-like flag you can rely on the host OS vendor to provide the trusted root & the server operator to provide the trusted leaf certificate + chain to the user (how it currently functions, if you're using TLS via QT's verification), rather than needing to "roll your own" cryptographic trust system (which has bitten other projects with vulnerabilities in the past, and adds a lot of complexity!) that seems to be part of #4544 As far as some of the details, the flag should probably not be the default (as it isn't in many web server implementations, to prevent server operators from shooting themselves in the foot), and should probably be user-clearable per server in the event the of a mess up server-side (like clearing all the offline browser cache for a site in firefox or such). You can transmit the flag over the TLS channel after the first connection from server to client. You then just have to have the client prevent bypass of TLS trust for that hostname. Eliminates a security risk that most end users won't understand the consequences of clicking through. Thanks for the reply!

deekerman commented

2026-02-20 22:12:01 -05:00

Author

Owner

@saelic commented on GitHub (Jan 6, 2024):

This future is an ABSOLUTE MUST NOWADAYS, especially in installations where Mumble is used for more sensitive conversations than gaming. It should be controlled by dedicated option in murmur.ini.

@saelic commented on GitHub (Jan 6, 2024): This future is an ABSOLUTE MUST NOWADAYS, especially in installations where Mumble is used for more sensitive conversations than gaming. It should be controlled by dedicated option in murmur.ini.