0

I am considering how to make my chat application a bit more secure. It has a similar structure to IRC, multiple users can join each server, and servers can be hosted by anyone. I have been using TLS so far, but it has the problem of requiring each server to have a signed certificate, which is not very practical because it is important that hosting a server be as easy as possible and signed certificates often cost money. I was considering using SSH, but it seemed rather difficult to use it purely as an encrypted wrapper over a TCP socket. Additionally I need to be able to connect via websockets from a browser (so that I can run a client in the browser), and therefore I'd have to find some way of implementing the SSH protocol inside the web browser which seems impractical.

Security is not the number one priority for this program, but it needs to be safe from a MITM attack because passwords are sent over the connection. Of course the person running the server could also intercept these passwords but I don't think there's much that can be done about that.

Should I just use TLS and tell the users to get a signed certificate, or are there any other protocols that I could use instead to wrap a TCP (or websocket) connection? Is it even somewhat feasible to implement a custom protocol (of course using existing crypto libraries)?

Improve this question
7
  • "it is important that hosting a server be as easy as possible" - Installing TLS certificates is relatively easy. Other methods based on sharing secrets are much more complicated.
    – mentallurg
    May 13 at 21:55
  • 2
    "signed certificates often cost money" - There also CAs that provide free certificates: Let's Encrypt, Zero SSL, Buypass.
    – mentallurg
    May 13 at 21:55
  • Would separate servers produce separate networks, or are those servers expected to be part of one single network? (i.e. you need to defend from potentially malicious servers)
    – Ángel
    May 14 at 1:53
  • the person running the server could also intercept these passwords but I don't think there's much that can be done about that The protocol could be designed so that it doesn't use passwords, or passes it in a way they cannot be snooped (e.g. a centrally trusted passes a signed nonce which is used as salt for producing an authenticating hash)
    – Ángel
    May 14 at 1:58
  • @Ángel the servers are entirely independent and produce separate networks. I would like to avoid any kind of central authority if at all possible.
    – Jachdich
    May 14 at 7:44

1 Answer 1

Reset to default
2

Suitable method of encryption for user-hosted chat platforms ... but it needs to be safe from a MITM attack because passwords are sent over the connection

No method of encryption protects by its own against MITM attacks. To defend against MITM one needs to make sure that one is communicating with the expected remote peer and not some MITM attacker. This requires one to know the identity of the peer and to be able to verify it (authentication).

When using publicly trusted certificates in TLS the identity is the public domain name and verification is done by checking that a) the certificate is valid and issued by a trusted CA and b) that the certificate is issued for the expected domain name - see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.

When not relying on the publicly trusted certificates one needs to distribute the authentication information between the nodes some other (but secure!) way, like with self-signed certificates in TLS, with keys in SSH etc. As Ginnungagap commented there are some methods to distribute these information using DNS - which requires a secure DNS though (DNSSec) which isn't as widely established as the existing trusted public key infrastructure. Of course one could also implement some custom distribution method, which makes it even more complex though.

In other words: the less complex way is likely to rely on publicly trusted certificates. These are available for free from CA like Let's Encrypt.

Improve this answer
4
  • TLS and SSH public keys can be exposed through DNS via TLSA and SSHFP records although this is only secure as long as the zone is DNSSEC enabled and the client properly verifies it.
    – Ginnungagap
    May 13 at 19:39
  • @Ginnungagap: good point. I've added it to the answer.
    – Steffen Ullrich
    May 13 at 19:50
  • Even a CA like Let's Encrypt still requires the user to purchase a domain name, though, which is a bit problematic
    – Jachdich
    May 20 at 16:39
  • @Jachdich: Compared to the other costs involved in running a server (connectivity, energy, hardware ...) the domain name is really a minor expense, being in the range of a few coffee to go.
    – Steffen Ullrich
    May 20 at 16:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .