On Tue, Jun 9, 2009 at 8:14 AM, Andreas<andreas@kolsyrad.net> wrote:
They probably won't change to Unreal even if hell freezes over. There are many other softwares that support SSL.
There is a lack of SSL support in IRC clients, but some do support it.. SSL is a thoroughly inappropriate encryption method for IRC traffic; high processor requirements (for strong ciphers.. and increased latency/lag on the client side, which IRC users are highly sensitive to. It's not a good solution. For IRC server admins, the SSL protocol has some possibly serious performance implications, and there is a need for many precautions in any SSL implementation. SSL is designed to provide confidentiality, but the protocol (and most libraries that implement SSL) do not present adequate protections against SSL-targeted abuses. If two users both connect using SSL, every message between them has to be enciphered and deciphered twice. If 500 users on a channel use SSL, all connected to the same server, every time just one of them sends a message, the IRC server has to decipher that, and encipher that message, 499 times, when transmitting to the other members. In an active, large channel, this would probably require a special hardware crypto chip, or lots of CPU power, for the IRC server to keep up. For this type of reason, IRC admins may not wish to support SSL on their server, due to the risk that the SSL support itself is actually targetted by a script kiddie to attempt a resource starvation, or to force a server to repeatedly re-generate encryption keys (by rapidly dropping and re-requesting new security associations). It's one thing if it takes a few extra seconds to load a web page; it's quite another if you add an extra 5 second round-trip time to get a message to your friend on IRC, due to crypto processing other messages on your IRC client, or your local IRC server being heavily loaded with SSL processing. Some form of specific payload encryption would perform better. IRC passes a great deal of I/O that isn't sensitive by any measure. Users should ideally be able to _choose_ a policy for their /MSGs. Some traffic is sensitive enough, that the lag penalty is desired over a less-secure channel, but for routine traffic, the latency and client slowness is an unwarranted cost. e.g. It really doesn't do anyone much good to encrypt things like /MOTD, /LIST output, PING-PONG sequences, and public actions like joining or sending a message to a large channel and receiving the /NAMES list. It should be good enough to only authenticate these messages, but with SSL you can't choose to only encrypt the private stuff. These higher I/O commands could generate significant encipherment/decipherment overhead for the IRC client (and server) also -- -J