#546 Mumble Client Certificate

Alpha_0.2.2
closed
nobody
Mumble (544)
5
2012-10-30
2010-03-03
Bryan
No

Murmur 1.2.2 Linux & Mumble 1.2.2 Windows
ISSUE: Client certificate not allowing multiple users on one pc to connect to same server

If user1 connects to murmur server1 then user2 connects to murmur server1 user2 will be logged in as user1. If client certificate is revoked or changed user2 can connect as user2. This happens 100% in my case user1 is registered and user2 is unregistered. This issue is either due to client caching or binding client certificate to client and not user. Check needs to be added for username change and allow non registered user. Furthermore this password exchanged technique is similar to PGP implementations and has severe exploits. Due to the nature of this project, client certificates not issued by a murmur server are just asking for being exploited. I recommend removal of client certificate in lieu of option to register on a murmur server through a wizard in client w/ ssl or encryption defined by murmur server attempting to register with. I have been able to exploit the client certificate easily. below is example of fields necessary:

  1. Server registration Password (murmur instance password to allow reg if defined......else gray out on client automatically) (new var)
  2. Username (proposed username to add to murmur db for this murmur instance)
  3. Password
  4. Password Verify
  5. Display security used for this action (verifies server allowed levels 1st. then allows user to select from allowed. should be defined in murmur.ini for allowed security methods)

This implementation would also solve creating new users issue since no good new user creation interface exists in the community for unattended end user registration. using ACL & Groups, admins can still require adding to group before access to channels and change server registration password or disabling registration if required by application.

Discussion

  • Thorvald Natvig

    Thorvald Natvig - 2010-03-03

    The certificates are stored in the user-unique local storage on the client, meaning the home dir on Linux, the HKCU registry on Win32, and .. err. whatever it is called on OSX. The purpose of the certificate is to identify a PERSON, and unless you have a very weird computer setup, each individual person using your computer is likely to have their own user account, and hence their own certificate.
    On the server side, things are configured to have one account per physical person, which means that if you log in with a known certificate, you'll automaticlly log in with your useraccount.

    I can't see how client certificates are any easier to exploit than passwords, no matter who issues them. Please detail your exploit.

    Password security doesn't work. We tried that for the 1.1.x series, and people habitually forget their passwords, leading to a social engineering attack when they go tell an admin that "No, really, I'm user X, I just forgot my password, can you reset it for me?". With certificates being stored in registry, and users strongly encouraged to back them up, the chance of a user loosing their identity is minimal. It also means that you don't need to worry about users that use the same password all over, since there is no password.

     
  • Bryan

    Bryan - 2010-03-03

    I agree with the password problem, but i believe that is due to the lack of user registration and user control in the client for the 1.1.x tree. can we have selection of auth methods ie pw or certificate on server side config. If using 3rd party auth ie phpbb3 i would like to disable certificate auth.

    I humbly believe the problem is not the password but the ability to change and reset the password.

     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).