No, nobody can easily know this - Quakenet's probably still the target of DDoS.
Aren't we getting to the point where we more or less must assume that these kind of things happens? I mean, taking into account all the news we have seen during the past, err, year :-)
Non-plaintext authentication mechanisms are a good start - it's an extra layer of security that you add to your system. Having SSL between your servers is also an extra layer of security. Having client-to-server SSL is, once again, also an extra layer of security. And so on.
We are not asking the Quakenet staff to "fix" multiuser chat encryption - leave that to the protocol developers, researchers and people working on different experimental protocols to try to "fix".
But, I still don't understand how much you refuse to step into reality and face that SSL is nice to have on a modern IRC network - we agree that it's not perfect, but do allow your users to understand the risk and let them take the necessary step to enhance the privacy of their communication.
Right now you are just hindering it where every other network is way ahead of you in this regard...
Your users are not dumb. I, as a user, want to be able to decide whether or not I connect, to a network, over SSL, where I assume that the network is able to interconnect its servers over SSL encrypted links, then I can make the decision if I want to add an extra layer of security by using software like FiSH where I can share secrets with my closets friends using, say, a pre-shared key.
I'm sorry, but said article have already been brought up multiple times in #dev and people are starting to understand how it doesn't hold water anymore.
I break into any discussion I see on IRC where someone posts a link to this article as an argument against SSL on IRC simply because it's not an argument against SSL.
Of course, it takes two to tango. We, the client authors, have started enhancing our SSL support and so should the network operators that hosts the servers on the larger networks.
Also, I think we agree on how Freenode stores the same certificate on every sever is... not ideal...
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.
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 :-)
Albeit unrelated, I wonder when Quakenet is going to realise that SSL for IRC, both server-to-server, but also client-to-server, is a must have in the year 2014, if you are truly care about your users privacy.
https://katzenpost.mixnetworks.org/