mumble
mumble copied to clipboard
mumble-voip
[Feature Request] Prevent old user versions
Context: Security, Privacy
Description: I would like to be able to block old versions of mumble from joining my servers.
I know this is a difficult issue (in terms of opinions), but #4001 pointed me to the fact that there are many (very) outdated versions of mumble around and it is imo a security and privacy risk for others to let them join so easily.
Like I said, some people won't like this, but I wanted to give this issue a plattform for discussion. Imo it should be the decision of a server owner.
For Reference: Many Servers (of Games, Services etc.) also don't let outdated versions join, for various reasons, including security, so it is quite common.
Alternatives:
- I am aware of suggestVersion, but as far as I understand, that is just a notification, or am I wrong?
Open Questions:
- [ ] What SSL/TLS versions does mumble/murmur still accept?
- [ ] are there any messages/popups implented in the past (v.1.2 and above) that could be used for this?
- Ban-Message? (suggested by @Krzmbrzl (comment))
- "Access denied/Connection refused" message (not available?)
I am aware of suggestVersion, but as far as I understand, that is just a notification, or am I wrong?
That's indeed correct (afaik anyways).
In general I do agree with you that restricting the version of a client that is allowed to join, should be an option a server admin has. However on the implementation side this is a very delicate issue. If we do that in a way that doesn't make sure that the connecting client will know that (s)he can't connect because the used client is too old, then we'll anger a lot of users and get a bunch of reports of Mumble not working. Or even worse: They don't report it (where we could clarify the issue) but go and tell their friends that Mumble sucks because you can't even connect to a server... This could get really bad for us.
The main idea I had was that for newer clients we could implement a new message type for this, that'd open a popup for the user and for older ones we could send a text message before disconnecting them. I'm not convinced though that a text message is enough for users to really notice...
I would like to be able to block old versions of mumble from joining my servers.
Should this be done on the version number? version number and OS?
Maybe encryption could also be taken under consideration. Like accepting TLS 1.1 connections, but then issue a warning message and disconnect.
I wonder what the real issues with older clients are? Would it be useful to block specific client versions that have security issues?
I'm not convinced though that a text message is enough for users to really notice...
I don't know if that works for older clients, but maybe some CSS would draw enough attention.
<div style="background-color:#ff5500"><br/><b>Attention! Attention!</b><br/></div>
I don't know if that works for older clients, but maybe some CSS would draw enough attention.
CSS is a good starting point however HTML messages are not always an option and this feature must be as visible as possible...
@Krzmbrzl Ok, I see that can be indeed a problem.
questions:
- how far back is the backwards-compatability?
- what does the client "say" when a user cannot join (or is denied access etc.)?
- are there any messages/popups implented in the past that we could use here?
While I agree that a message in the log/chat is normally not enough, it is better than nothing and a user will always look for reasons and thats directly in front of his/her eyes.
Three related things:
-
Server access denied message: Maybe a general message for denied access for technological reasons could be implemented, that leads the user to a wiki page via an url. Or leads him/her to look at the chatlog.
-
Update notification: I noticed that there seems to be a general update notification that can be disabled by package maintainers. While it is understandable to do it this way, maybe it should be modified, so that also package users get to realize that they use (very) outdated versions. And #4121 showed us that there are alternatives, like official PPAs etc.
-
General notification: I don't know if thats possible, but maybe you could implement a general notification window that could contain messages that are added to the code later (aka in later versions). Because if you think about it, there can always be new errors or technology changes that might prevent users from joining a server (or other situations as well). Technologywise the message would then come from the server.
@streaps
Should this be done on the version number? version number and OS?
Well the version number could be enough. But an outdated OS or dependencies can be a problem as well...
- Does Mumble check the OS and some dependencies by default?
Maybe encryption could also be taken under consideration. Like accepting TLS 1.1 connections
Interesting thought, should probably be investigated.
I wonder what the real issues with older clients are? Would it be useful to block specific client versions that have security issues?
That question is maybe a bit overspecific, but there are surely some issues.
how far back is the backwards-compatability?
Well ideally way back, but I think at this point at least include the complete 1.2.x series.
what does the client "say" when a user cannot join (or is denied access etc.)?
Afaik there is not "connection refused" in that sense known to Mumble right now. I guess you'd get the normal "Disconnected from server" message :thinking:
are there any messages/popups implented in the past that we could use here?
This just came to my mind but depending on how banning is implemented on the client side, we could misuse the Ban-message for this. I'd think that a Ban is also something that the user should be notified of and thus my hope would be that there's a popup or something like this for this case. I haven't checked that though...
While I agree that a message in the log/chat is normally not enough, it is better than nothing and a user will always look for reasons and thats directly in front of his/her eyes.
Let me correct that: "a sane/good/interested user ...". I'm afraid that this does not include all users and even if that small percentage starts spreading the word that "Mumble doesn't work", it could end up badly.
I noticed that there seems to be a general update notification that can be disabled by package maintainers.
Afaik this is nothing specific to package maintainers. It's a normal option in the setting and by default it is on. I don't think that there is much we can do about changed default values :shrug:
I don't know if thats possible, but maybe you could implement a general notification window that could contain messages that are added to the code later (aka in later versions).
Absolutely. We just need a generic Notification message that takes a String and when that is received, it can open a popup to display that String.
And I agree that this will probably get useful in the future again ^^
Does Mumble check the OS and some dependencies by default?
If the client didn't disable it in the settings, Mumble also sends the OS and OS version when connecting to the server. What dependencies would it check though? E.g. OpenSSL versions of dynamic libraries? If that's what you mean: No it does not.
@Krzmbrzl
the complete 1.2.x series
Well thats long:
10 Dec 2009 - 1.2.0
Is it really technically possible to connect to a 1.3.0-server with this?
we could misuse the Ban-message for this.
:+1: That would be a good option (if it exists), as the user would not blame mumble for it, but the server.
general update notification that can be disabled by package maintainers.
It's a normal option in the setting and by default it is on. I don't think that there is much we can do about changed default values shrug
My idea is a little different, but you are right, because of the (mostly) disabled status of this option, a new or changed function would be necessary. The user should maybe be notified that a new version of mumble is available - reasons for this are obvious (more newer versions and better security with it) - and given some considerations:
- if windows user/or self compiled/ or static download / or official repos:
- update
- if package user:
- notify the package maintainers
- use alternatives like snap/ppa etc.
Options for "when should the user be notified?" (chosen by devs or users themselves?):
- immediately
- after some time (to give the package maintainers some weeks to pack the new version)
- only when the version is very outdated, e.g. "1.2.19" as of now.
Absolutely. We just need a generic Notification message [...]
Cool, that could solve some problems in the future :+1:. For security :safety_pin: : hardcode it, so that server admins are not easily able to manipulate the message.
Does Mumble check the OS and some dependencies by default?
If the client didn't disable it in the settings, Mumble also sends the OS and OS version when connecting to the server. What dependencies would it check though? E.g. OpenSSL versions of dynamic libraries? If that's what you mean: No it does not.
I thought wrong about this; somehow I just thought about what the client checks, but this is of course about what the server checks :bulb: . So that might be to intrusive (to check for dependencies etc.). Regarding dependencies:
-
Openssl: The point @streaps mentioned is a good one: only allowing higher versions of TLS (or whatever is used in the future).
- The question is what is the status right now? I guess very old versions of SSL/TLS are not allowed anymore?
-
Celt/Opus: Opus can be enforced now, so outdated Celt should not be a problem anymore (server-wise).
Is it really technically possible to connect to a 1.3.0-server with this?
Haven't tested but I think so, yes :thinking:
The user should maybe be notified that a new version of mumble is available
Well the system to do so is in place already, but it is optional. And I really don't want to make this mandatory. It should be up to the user whether or not (s)he wants update-notifications. But then again it should also be up to a server-admin to not let these outdated clients onto their servers :shrug:
For security safety_pin : hardcode it, so that server admins are not easily able to manipulate the message.
You mean the message that gets sent? Well it'd depend on the context the message is being sent in but I think in the different scenarios that message would probably be hardcoded anyways :thinking:
The question is what is the status right now? I guess very old versions of SSL/TLS are not allowed anymore?
No idea. I haven't looked into all the crypto stuff...
Update notifications:
Well the system to do so is in place already, but it is optional. And I really don't want to make this mandatory. It should be up to the user whether or not (s)he wants update-notifications. But then again it should also be up to a server-admin to not let these outdated clients onto their servers :shrug:
The problem I see is this: Package maintainers can disable the update notification and my request is, to change that. So that also users of packages get notifications about updates (under specific circumstances) (see above comment). The choice about disabling this, can still be the users choice.
You mean the message that gets sent?
Yes.
Well it'd depend on the context the message is being sent in but I think in the different scenarios that message would probably be hardcoded anyways :thinking:
Ok, sounds good. Just wanted to mention that security aspect.
The question is what is the status right now? I guess very old versions of SSL/TLS are not allowed anymore?
No idea. I haven't looked into all the crypto stuff...
That would be good to know.
Package maintainers can disable the update notification and my request is, to change that. So that also users of packages get notifications about updates
It is always possible for the user to do so. And if package maintainers change defaults, that's none of our business :shrug: If you don't want that, I guess you'll have to open an issue for them...
Package maintainers can disable the update notification and my request is, to change that.
Package maintainer can still patch your software to disable the update notification, please don't work against package maintainer, there are reasons why these things exist.
There is nothing worse for a user than getting a notification for something they can't do anything about. That's why update checks are disabled by package maintainers. Because 95% of users can't do anything with an update notification from specific software.
I'm all for preventing old clients to join servers (with a good error message telling them why), preventing maintainers from disabling update checks brings nothing to the table in regard to that.
@bendem @Krzmbrzl I understand this problem very well, I am also maintaining packages :wink: (but not mumble). But what I want (and this is of course a sub-topic) is a debate about this.
To summarize, the general question is: What is more important und valid?
- that a User is informed about a new version (and that he/she is running a completely outdated version)
- that the package maintainers can refuse to update the software (for whatever reasons, we all know most of the reasons, some are "valid" some are also "less valid") and at the same time keep the information about a new version hidden from the user.
I think that No. 1 is more important und that No. 2 is maybe even invalid.
Now I of course know that the main problem is this stable-distro approach (that leads to outdated packages and that many distros have as default) - that is criticised not only by me -, but still it is also a decision of software developers to play along or not.
To give you an example (I already mentioned it above): The users of packages might get the information at a different point in time and in a different form:
-
Regarding the point in time:
- user gets the information a few weeks (or even months) after the initial release of a new version, so the package maintainers have/had enough time to package it.
- user gets the information only when the package is very outdated (e.g. older than a year or there are already two new versions available).
-
Regarding the form:
- The user is informed that a new version is available (since longer time) and he/she might inform his/her package maintainer about this.
- The user is also informed that Alternatives (snap, PPAs etc.) might be available and is lead to the official wiki of mumble.
This way we (or you) prevent very outdated versions. This method could also be promoted/proposed to the package maintainers to prevent working against each other.
It is always possible for the user to do so.
And where is this option, I could not find it? Or is the user asked that in the audio wizard (on first start)?
And where is this option, I could not find it?
Settings > Network > Mumble Services > Check for application updates on startup
Or is the user asked that in the audio wizard (on first start)?
No
But what I want (and this is of course a sub-topic) is a debate about this.
I don't want to sound rude. Not at all, but I don't think this is a debate worth having. The option is there (freely available for every user) and thus each user can decide for themselves. It defaults to enabled, which is all we can do on our side. If package maintainers choose to disable it by default, then there's nothing we can do. Even if we made this hard-coded, the maintainers could still disable it as this is FOSS.
Besides: Forcing this on package maintainers will also force this on every user out there. That's just not acceptable.
If you want the maintainers to keep the option enabled (for reasons I can understand very well), that's something you have to discuss with them. It's just out of our hands (even if we wanted to enforce it).
TL;DR: In my eyes this can't be enforced by us (even if we wanted to) and thus the debate about this is rather pointless :shrug:
@Krzmbrzl
And where is this option, I could not find it?
Settings > Network > Mumble Services > Check for application updates on startup
Is not visible for me (thats the point).
Uhm okay then it is hard-coded disabled by the package maintainers. Then I agree that I think this is a silly thing to do (from the maintainers), but my main point remains. There's nothing we can do about it...
Okay just found that this can be disabled via a Makro: https://github.com/mumble-voip/mumble/blob/5be2bb965faa5e0b6c691d8dc3a6f2692355c97e/src/mumble/NetworkConfig.cpp#L28-L31
@Krzmbrzl
There's nothing we can do about it...
I don't understand that point. Its you who program this. Of course in pure theory package maintainers could reprogram things in any way they want, but they don't do. You provide this option and they just use it during compilation.
As I said:
This method could also be promoted/proposed to the package maintainers to prevent working against each other.
I don't understand why it should be impossible to offer different options or talk to the maintainers. It is of course your choice, if you don't want to do it, but right now you tell me, you can't do it.
You provide this option and they just use it during compilation.
But it is still an active decision that they don't want auto-update checks. We should respect their decision.
talk to the maintainers.
That is of course possible, but a) I have no idea who they are (though that could be found out) b) Afaik this is mostly a Distro-decision and not one that is up to the package maintainers. If a distro doesn't want new software in their repos, then there's not much a maintainer can do, right? And thus for the majority of users it wouldn't matter if they knew that their software is outdated...
I would like three things:
- Implement a new option like I proposed above (let's call it: "later update notification")
- Let the user decide about the notification:
- implement an option to (re-)enable the notification
- implement it in a potencial new startup wizard (#4137)
- Better information on the website and the wiki
- that the packages in the distro can be outdated
- that alternatives like snap, PPAs etc. are available (partly done, but could be a little better)
And thus for the majority of users it wouldn't matter if they knew that their software is outdated...
It matters very much, because otherwise they might not even know that they use outdated software. And there are alternatives like snap, PPAs etc. (and also a change/upgrade of OS), so they can choose. But they need to be informed first.
implement an option to (re-)enable the notification
No. We won't start a war with package maintainers here.
Implement a new option like I proposed above (let's call it: "later update notification")
If a package maintainer disables updates because (s)he is unable to update the package anyways (due to distro restrictions), why would that maintainer enable a delayed update notification?
because otherwise they might not even know that they use outdated software.
Are there really users that care about something like this that don't know that software installed through the repositories is most likely outdated?
No. We won't start a war with package maintainers here.
Thats not necessarily the case. In my impression the "makro" (as you called it) is understood as "disable auto-notification", not "disable the ability of the user to enable notification".
An additional example: You already provide a PPA for ubuntu. Is that a war with the package maintainers? No it is not, it is providing alternatives, so why not let the user know about alternatives.
If a package maintainer disables updates because (s)he is unable to update the package anyways (due to distro restrictions), why would that maintainer enable a delayed update notification?
- Because he is fair.
- There are other reasons than distro restrictions.
Are there really users that care about something like this that don't know that software installed through the repositories is most likely outdated?
Thats exactly the point, the stable-distro-concept is missleading users, so they will only notice that, when they search for it themselves.
In my impression the "makro" (as you called it) is understood as "disable auto-notification", not "disable the ability of the user to enable notification".
In fact when checking the docs for that macro, the implementation is actually wrong... https://github.com/mumble-voip/mumble/blob/5be2bb965faa5e0b6c691d8dc3a6f2692355c97e/INSTALL#L139-L140 I'd interpret that as if this option would only disable the check by default, not remove the setting altogether...
Thats exactly the point, the stable-distro-concept is missleading users, so they will only notice that, when they search for it themselves.
Actually it's not. It does what it is supposed to do: Provide stable software. New features mean new bugs. Thus if you want a stable software, you shouldn't upgrade to a new feature release in normal day-to-day work. Besides I don't think it is up to us to lecture the user about how distro repositories work.
I'd interpret that as if this option would only disable the check by default, not remove the setting altogether...
Then at least change that. Because maybe the maintainers don't intend that :wink:.
If you are using the package from the distribution, you really don't need the update check. The package gets updated automatically by the package manager. It's the same with many other applications (e.g. Firefox, ...)
keep it simple
That's a valid point (which I agree that disabling it by default is a good choice here). But if a user wants to know, I don't see a justification to deny it to them because of it. If they do indeed keep it simple, then the update check won't be done for them anyways :)
I've been in contact with the Debian package's maintainer (@crknadle) for the past year.
He probably knows the best solution for the issue.
@davidebeatrici Well in Debian (at least since Buster (which is now Stable)) the packages are recent. But we see older versions, e.g. recently in an issue about ubuntu: #4121
But that said, I would like to see a discussion about this (including package maintainers).
In general I understand the issue with stable distros, but in fact that means for now, outdated packages (and I'm sure with negative security effect) and the user is not even aware of newer versions.
So I would like to see some sort of solution:
- Either more recent packages (sometimes difficult to implement, even in Backports: because of dependencies etc.)
- Or at least the possibility for the user to be informed (if he/she chooses to be)
Also solutions to consider:
- Snap packages (some software relies entirely on that, LXD for example)
- official packages (e.g. Ubuntu could rely more on your PPA) Edit: I see now, the ubuntu packages are based on Mr. Knadle's package, but not as recent, so Ubuntu's decision.
Well in Debian (at least since Buster (which is now Stable)) the packages are recent.
not really: 1.3.0~git20190125.440b173+dfsg-2
not really: 1.3.0~git20190125.440b173+dfsg-2
You are right, I have only looked at the 1.3.0 :smile:.
I think one way of letting users updating their clients is to mute them. If the server discovered an old client, it just mutes them and refuses the audio packets sent by them. In the meantime, display a message in the chat window, maybe periodically, one per 30secs.
Anyway we are going to drop the support for decoders other than Opus. Muting them is the best way to avoid incompatible old codec packet piss off the clients of other users.
:thinking: @Krzmbrzl Sry for bothering with this, but just two ideas:
- Maybe you could add a
feature requestlabel, so this is not forgotten? - Maybe we could hide the whole (rather off-topic) discussion about the "notify users to use new versions"-topic, because it is partly already implemented and partly not really doable or "wise".
Edit: Thx :+1: