Hacker News Reader

Comment by csmithuk | Hacker News Reader

It's unfortunately also very CPU intensive which is a big problem for IRC networks which handle stupid numbers of connections at the same time.

View on HN

Other networks have adopted SSL much earlier and I simply refuse to believe that Quakenet's problem is CPU related.

I'm not saying that a network should require all of its users to use SSL, but I do think that it's should be up to the user to decide whether or not her or they wants to encrypt the connection between themselves and the IRC server and let it be up to the channel operator to decide whether or not she's willing to accept clients, that connect over insecure connections, in her channel.

It's purely because it hasn't been prioritised until recently, but it sounds like it's getting some attention now :-)

CPU load is not the primary issue. SSL on IRC networks for client connections cannot assert that the communication is secure (for example, that all clients in a channel actually bothered to verify the SSL certificate properly). This issue will remain until client verification techniques such as DANE and DNSSEC are widely adopted on for IRC usage.

It's not true that this is up to the clients authors alone to do this work, and it's not fair for the users to tell them that you are awaiting client adoption of various technology, when the current Quakenet ircd implementation is currently incapable of even accepting SSL connections. Or at least it was, last time I checked.

Also, the DANE support in Irssi was announced in September last year and I have only heard of one network where some of its servers have adopted to this technology. Even though there is only one client that currently supports DANE+DNSSEC verification, we still need the (big) networks to start preparing for the support of it, and help us reaching the point where we can secure our user connections even better :-)

Having SSL on IRC, even without DANE+DNSSEC, is still better than having no SSL at all.

This is why I am disappointed that SILC[1] never got off the ground in the mainstream. It could have been an elegant successor to IRC.

1. http://silcnet.org

I blame the reference (server) implementation leaving so much to be desired. Primarily stability.

I tried running a silc server alongside my ircd for a while, but it never even reached a weeks worth of uptime without crashing (no matter if debian package, self compiled stable or devel, or some minor messing with the source).

Perhaps if a non-C/C++ implementation comes along..

No, it wasn't that. There used to be (maybe still is, I didn't check) a core group of reliable servers. I remember having a client idling on them for weeks without reconnections.

What was missing, I think, was lack of client development and adoption. There was default CLI client which was a weird fork of Irssi, then there was plugin for Irssi, and not much else.

There were of course few small client projects, but few of them got past early alpha stage.

It still helps in the "coffee shop wifi" scenario. I'll take my defense in depth, thank you. =)

Reply on news.ycombinator.com