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.
please stop putting words in my mouth: I never said it's not nice to have, I said I don't think it adds much value, and that I believe that it's dangerously misleading.
I've been part of running a large IRC network for more than a decade: I have seen tens of thousands of users fall for various scams, get their passwords stolen, hand their passwords out willingly, connect through 'free bouncers' that perform operations as them, get DDoS'ed, install 'pingbooster.exe', you name it.
I wouldn't call them stupid, just mostly unaware or naive, and ultimately if we are going to attempt to protect their communications them we need to take their behaviour into account.
There are also operational concerns with deploying TLS: OpenSSL is up there in the top 10 list of 'software with the most security vulnerabilities', and if our servers get hacked our users really aren't any better off.
We have a some plans (inspired by Chrome's architecture) to work around this huge issue (restarting a webserver has no impact, but you can't do this with an ircd), but it all takes time and we're volunteers.
Ultimately I am a pragmatist, I will do things that I think are necessary and that I believe can work.
If I understand your reasoning, TLS for HTTP should be considered useless as well. Users do stupid things that lets their information get stolen. SSL/TLS provides one layer of security, and at least prevents plaintext sniffing of traffic.
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.
we believe it's better to not have it than to do it badly.
the other way to do it would be like freenode: do it quickly without understanding the risks... they used the same SSL cert for every ircd, then they got hacked, and with no PFS, all their past SSL'ed IRC is now effectively in the clear.
Since anyone can look over your shoulder and see your screen, and also anyone can torture you into giving up your passwords and log files, all encryption is worthless, and actually worse than no encryption at all since it gives you a false sense of security.
This is essentially the line of reasoning I'm seeing employed in this blog post.
SSL is valuable on IRC solely for letting you authorize with NickServ. If you are at a developer conference on the conference wifi, you would be foolish to connect to IRC sans-SSL and authorize with NickServ, especially if you owned any channels. If you blindly accept an unverified cert, that's your problem, but don't take SSL away from me because some people don't understand certificates.
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...
I'd love to be able to connect to a QuakeNet IRC server which is SSL/TLS protected to help guard against anyone sniffing on the local network, or along the route to the specific IRC server.
Yes, there are problems to solve. Clients need to validate the servers certificate properly. Users need to understand that whatever they send may still be logged by the network, other users on the channel, etc.
Saying that IRC doesn't need SSL is like saying that other IM applications such as Skype don't need it either. Anything which helps prevent eavesdropping should be done.
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.
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's true that we still haven't secured the connection between the user and his ISP's DNS server, which I agree is a problem. DNSSEC only helps between the DNS servers themselves.
We are now down to either a) run your own DNS server locally on your machine or b) use a third-party DNS server that we trust.
Personally, I use Thomas' (the person mentioned in the article itself) free, uncensored, DNS service called CensurFriDNS. You can read more about it here: http://censurfridns.dk/
In the recent weeks, there have been a lot of discussions about security on IRC and the use of web-based IRC clients in particular.
The general opinion appears to be that people really don't give a rat's ass about securing themselves on IRC. People run IRCd's and their IRC clients on multi-user shell services for a suspicious little amount of money per month just to be able to claim they have their own server and to get a cool virtual host from the huge list that many of these shell providers have.
Recently people are starting to use "bouncer" like web services that keeps them connected even when their browser isn't attached to their session. This basically means that you do not own your connection to the IRC server which also have security and privacy implications.
We can't change people over night, but hopefully we can slowly plant a seed that will make people think about what they do and how they do it.
https://katzenpost.mixnetworks.org/