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.
Some ircd's implement channel mode +z which only lets SSL clients join.
> 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.
That's the problem though, you simply cannot trust other clients. If you need end-to-end encryption then you need secure clients as well, otherwise an attacker could:
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).
> And even if all these things were solved, you'd still trust the others to not publish the logs.
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.
