Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving connecting to servers with dynamic IP addresses #6406

Open
bergfried opened this issue Apr 28, 2024 · 0 comments
Open

Improving connecting to servers with dynamic IP addresses #6406

bergfried opened this issue Apr 28, 2024 · 0 comments
Labels
feature-request This issue or PR deals with a new feature triage This issue is waiting to be triaged by one of the project members

Comments

@bergfried
Copy link

Context

No response

Description

One of the main selling points of Mumble is that the users can set up server and clients comparatively easily in a way that they do not need to trust any third party. However, relatively often, that also means that the server is hosted at a dynamic IP address.

When using a mumble server identified by a dynamic IP address, checking the server certificate is a tedious chore because the client will not automatically accept the server's certificate. Both user experience and security could be improved, I think, with a few adjustments:

  • When entering the address to a server (e.g. when adding or editing favorites), provide a new checkbox labeled "Always ask for the address before connecting" or simply "Dynamic address".
  • If unchecked, the behavior is essentially the same as the current behavior.
  • If checked, then, whenever the entry in question is used to connect to a server, a similar dialog window should appear that asks for the address again, with the previously used IP address being provided by default. Thus, just confirming the dialog will connect to the address previously used for this entry, but a different address can be entered immediately if necessary.
  • Also, if checked, and if the server certificate associated with the previous address had been authenticated earlier, and the server at the new address shows the very same certificate (or at least a hash-equal certificate) as the previous one, the certificate should automatically be authenticated for the new address, and the previous association should be un-authenticated. Also, whatever address has been entered in that dialog will then be stored for the next time. (For example, editing the favorite in question later will then show the most-recently entered address that favorite successfully connected to.)

To provide a similar experience when starting the client via CLI to connect directly to a server with a dynamic IP address, I think it would be best to provide a new command line option to connect to a pre-stored favorite, like this:

mumble --connect-to-favorite 'Label of the favorite server'

As described above, if the favorite in question has a "Dynamic address", the user should then be asked for the new address via GUI.

(Alternatively, one might consider adding a query field or something to the mumble: URI to express the idea of a dynamic address. However, since that URI cannot be changed to reflect the new address after successful connection, it will not work as neatly. However, one could add a new query field to the URI to announce the expected hashes, like sha256=00112233… or similar, but this might have other side effects I did not yet consider. This is why I prefer adding a switch like --connect-to-favorite instead.)

With these changes combined, it should be possible for a user to easily connect to servers with a dynamic IP address securely without the need to manually recheck digests each time.

Mumble component

Client

OS-specific?

No

Additional information

No response

@bergfried bergfried added feature-request This issue or PR deals with a new feature triage This issue is waiting to be triaged by one of the project members labels Apr 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request This issue or PR deals with a new feature triage This issue is waiting to be triaged by one of the project members
Projects
None yet
Development

No branches or pull requests

1 participant