5 ms·

The problem is stingier than it looks. On one hand, anything that can run on top of an encrypted connection "supports encryption". IRC is no exception, IRC ser

The problem is stingier than it looks. On one hand, anything that can run on top of an encrypted connection "supports encryption". IRC is no exception, IRC servers have had SSL support for a long time now. However, the messages you send over the SSL connection will arrive in plaintext form at clients who chose not to use SSL when connecting to that server. Logs are also stored plaintext by many clients. There are servers which no longer allow non-SSL connections to cope with that. Edit: this debate is pretty long-winded, it was a pretty hot topic in a lot of circles even 10 years ago. I've heard proposals of adding encryption on top of IRC. The advantage being that even peers over unencrypted connections would still get encrypted data. I vaguely remember toying with some perl scripts for doing that over irssi. It's pretty pointless IMHO. People rely on IRC logs, and IRC in general has largely been for open forums and open collaboration. If someone needs to discuss sensible stuff over IRC, it's fair to assume that they don't want it discussed with anyone who happens to join their channel. In that case, it's perfectly acceptable to set up an SSL-only server with strong authentication (or even better, to ensure that you don't leak logs, to have everyone connect over SSH to a machine that runs a local-only IRC server).

davb 11y ago
It's also worth noting that many clients now have LibOTR (Off The Record - end-to-end encryption) plugins available. For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc).
- notalaser 11y ago
  > For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc). Exactly, at the end of the day you're still depending on people not to leak these things anyway.
  - laumars 11y ago
    This is the thing that's gets me about encryption on public communication platforms. On the one hand, I do want my authentication to be secured, but as much as we might discuss securing chat, it's all posted in the public anyway. It's like standing on a street corner and shouting your personal details and hoping that's every stranger adheres to the implied NDA. At the end of the day, as long as your authentication is secured, then that keeps your password safe. The fact that your communication to the server is also secured is a bonus as it means that any eavesdroppers can't tell which user your are not even which channels you hang out on. But anything more than that is just pointless given you can't trust all clients to be secure. I'm not entirely sure this is a problem that can be solved in any way either. If the text can be read, then it can be ripped and logged. Much like the Snapchat problem and how ineffective DRM is at stopping piracy. (OK, not exactly the same, but definitely some overlap)
    - lawl 11y ago
      I don't buy that argument. It's like saying we don't need TLS because in the end we still need to trust the server to not publish our password.
      - notalaser 11y ago
        That argument is made in the context of IRC networks, where the same server can have clients over both encrypted and unencrypted connections. If your own connection is encrypted, an eavesdropper listening at your router's exit can't see what you're typing. However, clients over unencrypted connections will get your message -- unencrypted! -- so an eavesdropper can just as well listen there, and he'll get your messages. He won't get your password, but will get your data. The argument holds for every similar system. E.g. TLS connections to a SMTP server mean that an eavesdropper won't see what you're asking the SMTP server to send, but if that server then relays your message over an unencrypted connection, all that TLS mumbo-jumbo won't help a bit, because the server just published your data in plain sight. Your password is safe, sure, but your data is in plain view, so if someone wants to spy on you, they don't even need your password anymore. So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections.
Strom 11y ago
Probably the most used encryption on top of IRC is mircryption [1] and its compatibles [2]. This was popular on EFnet 15 years ago already. [1] http://www.donationcoder.com/Software/Mouser/mircryption/ http://www.donationcoder.com/Software/Mouser/mircryption/ [2] There are lots of plugins that add mircryption compatibile encryption to IRC clients on all platforms, e.g. for modern mIRC there's FiSH 10 https://github.com/flakes/mirc_fish_10 https://github.com/flakes/mirc_fish_10
ryanlol 11y ago
>However, the messages you send over the SSL connection will arrive in plaintext form at clients who chose not to use SSL when connecting to that server. Logs are also stored plaintext by many clients. On most sane servers you can enforce SSL with channel flags and usermodes.

davb 11y ago

It's also worth noting that many clients now have LibOTR (Off The Record - end-to-end encryption) plugins available. For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc).

notalaser 11y ago
> For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc). Exactly, at the end of the day you're still depending on people not to leak these things anyway.
- laumars 11y ago
  This is the thing that's gets me about encryption on public communication platforms. On the one hand, I do want my authentication to be secured, but as much as we might discuss securing chat, it's all posted in the public anyway. It's like standing on a street corner and shouting your personal details and hoping that's every stranger adheres to the implied NDA. At the end of the day, as long as your authentication is secured, then that keeps your password safe. The fact that your communication to the server is also secured is a bonus as it means that any eavesdroppers can't tell which user your are not even which channels you hang out on. But anything more than that is just pointless given you can't trust all clients to be secure. I'm not entirely sure this is a problem that can be solved in any way either. If the text can be read, then it can be ripped and logged. Much like the Snapchat problem and how ineffective DRM is at stopping piracy. (OK, not exactly the same, but definitely some overlap)
  - lawl 11y ago
    I don't buy that argument. It's like saying we don't need TLS because in the end we still need to trust the server to not publish our password.
    - notalaser 11y ago
      That argument is made in the context of IRC networks, where the same server can have clients over both encrypted and unencrypted connections. If your own connection is encrypted, an eavesdropper listening at your router's exit can't see what you're typing. However, clients over unencrypted connections will get your message -- unencrypted! -- so an eavesdropper can just as well listen there, and he'll get your messages. He won't get your password, but will get your data. The argument holds for every similar system. E.g. TLS connections to a SMTP server mean that an eavesdropper won't see what you're asking the SMTP server to send, but if that server then relays your message over an unencrypted connection, all that TLS mumbo-jumbo won't help a bit, because the server just published your data in plain sight. Your password is safe, sure, but your data is in plain view, so if someone wants to spy on you, they don't even need your password anymore. So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections.

Strom 11y ago

Probably the most used encryption on top of IRC is mircryption [1] and its compatibles [2]. This was popular on EFnet 15 years ago already. [1] http://www.donationcoder.com/Software/Mouser/mircryption/ http://www.donationcoder.com/Software/Mouser/mircryption/ [2] There are lots of plugins that add mircryption compatibile encryption to IRC clients on all platforms, e.g. for modern mIRC there's FiSH 10 https://github.com/flakes/mirc_fish_10 https://github.com/flakes/mirc_fish_10

ryanlol 11y ago

>However, the messages you send over the SSL connection will arrive in plaintext form at clients who chose not to use SSL when connecting to that server. Logs are also stored plaintext by many clients. On most sane servers you can enforce SSL with channel flags and usermodes.