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).
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.
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)
This is not hypothetical, although most of the large-scale attacks of this nature have focused on the web. What sort of havoc can someone cause in your organization by injecting fake chat messages? :-)
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.
> 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.
Yes I'm saying that if you have confidential conversations you need to trust everyone to not publish the logs (and use SSL/set +z). No matter how good the crypto is.
It's a case for having end to end crypto in IRC if anything.
1) just hack the PC and read the logs straight from the file system / messages from RAM
2) impersonate a trusted user (since clients don't send fingerprints beyond the basic ident information)
3) and there's no guarantee that even if the client is connected to the server via SSL (eg set +z on the channel) or end-to-end encryption is builtin, that the "client" still isn't anything more than an IRC bounce (eg ZNC) that users primarily connect to via clear text.
So while I'm all in favour of encrypting IRC comms, the other links in the chain are so weak that pragmatically end-to-end encryption wouldn't offer you any significant privacy guarantees. So as much as I do love IRC, I honestly don't think it makes practical sense trying to leverage it as a secure platform for confidential conversations. There's better mediums for that; just as IRC excels in other areas where many other communication platforms fall short (eg openness, protocol simplicity, automation via IRC bots, etc).
It's not a case against crypto. You're actually proving my point.
But those things aren't solved. That's my point. The fundamental design of IRC makes these points hard to solve; and even if you did set out to solve them, you'd ultimately end up with a new protocol that was originally based on IRC but now not compatible with it. So it wouldn't be IRC any longer.
IRC is about open chat and it does that very well. There's better protocols for sharing sensitive information. I just don't get this modern obsession with shoehorning features into every piece of software or protocol and expecting everything to work perfectly. Even with chat protocols, there's a multitude of different paradigms - many of which aren't necessarily compatible with others. Why can't we just concentrate on making secure communication platforms better instead of bastardising an open platform to behave like a crappier implementation of a secure platform?
> It's not a case against crypto. You're actually proving my point.
That makes no logical sense. Crypto wouldn't solve the issues I raised and you've completely glossed over the part why I say privacy is only as good as the weakest link.
It's easy to argue about how to harden IRC from snoopers, but a great deal harder to actually fix those problems in practice since you only need one weak link in the design of the platform and the whole security model falls flat on it's face. Simply put: in terms of privacy there are far too many weak links in IRC. It just not a good protocol for secure conversations. And frankly I think it's best left that way as changing IRC to be secure would detract it from what makes IRC so great to begin with. eg it's openness, hack-ability and so forth.
Honestly, I think you're chasing an impossible vision. Sure, in an ideal world you could fix all those issues, but then it wouldn't be IRC any longer since you've now broken support for ZNC, bots, and so on.
[1] 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
On most sane servers you can enforce SSL with channel flags and usermodes.