4

If I have a client-server web chatroom, is it important for public or private(client-side encrypted) messages to be signed on the client side? Am I correct in assuming (correctly set up)TLS will prevent any MITM risk? Each user has their own private/public key for pm encryption.

Clarity: I am developing both the chat server and client

3

Using TLS doesn't prove the user's identity.
When you use a web browser to connect to a chat room, the server doesn't authenticate your web browser. Only your web browser authenticates your server.
If you are using a chat client, it MIGHT use client side authentication. Even in that case it will just ensure that you are using a valid client. The certificates stored in clients are not the user's certificates. If a web chat room did create certificates for each user, then a user would have to be educated to install it's server on the client and also it will be a pain for multiple accounts to access the chat room using the same client (say a shared computer in the house).

To prove that it is actually you who is sending the messages, you should use message signing unless each chat client has a unique key and you have a mapping between the chat client and the user..

  • To clarify, users do not really "sign in," they simply choose a nickname at the connection time. I was thinking that at connection time, an RSA key pair is generated, which is used to sign messages sent to the "main chat" and to both sign and encrypt messages sent as private. Would this be OK? – One Normal Night Dec 3 '16 at 1:01
  • So the next time a user logs in, they can use the same nickname only if no one else has used the same nickname? If that is acceptable to you and nickname is just a lose identity, then yeah, using a public private pair is fine. – Limit Dec 3 '16 at 1:03
  • Only if no one else is currently using that nickname, actually. – One Normal Night Dec 3 '16 at 3:05
  • @OneNormalNight Then yes. Using a RSA key pair should suffice. – Limit Dec 3 '16 at 3:38
  • 1
    Thanks friend! I shall develop it with this answer in mind – One Normal Night Dec 3 '16 at 3:53
2

Message signing and TLS provide different, overlapping guarantees.

TLS guarantees that the data exchanged between your browser and the server is genuine, and the communication between the other guy's browser and the server is genuine. It doesn't protect against a buggy, hijacked, or subverted server. In this scenario, the server is a man-in-the-middle built into the protocol; having end-to-end signatures protects against scenarios where the server can't be trusted.

Client-side signatures can also be subverted, if the client is subverted, or if the client's credentials have been compromised. TLS for the communication doesn't protect against that.

However, TLS does offer some other protections. It provides confidentiality as well as authenticity (end-to-end encryption could provide that as well). It also provides protection against replay and reordering: an old signed message would still be valid, but the server can reject out-of-order messages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.