IRC Networks Under Systematic Attack From Governments | Hacker News Reader

IRC Networks Under Systematic Attack From Governments

quakenet.org

361 pointsmeebi136 comments

Freenode has very recently been under DDoS attack[1] and has been dealing with them for at least a year or more[2]. It seems likely that they're getting the same government treatment as Quakenet. Given that Freenode hosts channels for many open source projects, these attacks aren't just annoying bystanders, they're potentially affecting the progress of our technology.

[1] http://blog.freenode.net/2014/02/turbulence/

[2] http://blog.freenode.net/2013/05/the-good-the-bad-and-the-ug...

"It seems very likely that they're getting the same government treatment as Quakenet" is not a conclusion that can be drawn from this blog post or the leak. My understanding based on what I read is that "Anon IRC" is on its own network and QuakeNet has nothing to do with anything except apparently relishing any opportunity to publish a political op-ed. IRC servers (and their users) have been DDOSed from the dawn of time by anyone and everyone.

To put it another way - when a body is found in the woods, you don't instantly jump to the conclusion that it must have been government drones because the government is using drones to kill people in Yemen.

> ... "Anon IRC" is on its own network ...

A few years ago, irc.anonops.com was (one of) the primary hangouts, if memory serves. I'm not sure if that's still the case or not.

Intelligent technical discourse is actively suppressed by the operators on that network.

Most DDoS attacks directed at IRC networks are not government related. IRC networks have a long and proud history of being one of the most DDoS-prone targets on the internet.

For this reason many hosts disallow IRC in their ToS

To my understanding to take down an IRC server doesn't even need to be a DDOS (Distrubuted Denial of Service) AKA multiple of computers and connections. One good DoS (Denial of Service) AKA one computer one connection, is all it takes to take it down.

Those are easy to block with a firewall policy. DDOS is the only way to sustain an attack.

It's a matter of bandwidth. If a single malicious actor can clog the the IRC server's uplink on the internet facing side of their firewall yes, otherwise no.

It's probably the case that lots of people try that, but unless the IRC server(s) are being hosted on their home network then I doubt one or two computers could bring a whole IRC network down.

That's not at all a given. I distinctly recall, for instance, DALnet being the target of crippling DDoS attacks ~15 years ago. IRC servers are incredibly vulnerable in this particular regard.

It was a rough time to be on DALnet.

I wouldn't say they're vulnerable, but just attractive targets.

The decentralized network of servers allows an IRC network to be more resilient than many other systems.

IRC servers form a spanning tree which makes it really easy to split an IRC network in two. I think this is the protocol's main weakness which should be addressed somehow. It's difficult without overcomplicating the protocol though.

I think that model oversimplifies it a bit, though for some implementations you're correct.

Often however IRC servers are either a hub or leaf. A hub accepts no user traffic directly and its IP address does not need to be publicly known. That makes it difficult to split the network since only the leaf addresses are known to an attacker.

As for the leaf servers, you can prioritize traffic between the leaf and hub over the traffic between the leaf and its users. You can also have them travel over different peers (most of the servers in the network I have experience with are multi-homed). Usually DoS attacks then manifest themselves as a large number of users timing out from their leaf server. Many IRC clients will attempt to connect to other known leaf servers when they cannot reconnect to the one that dropped them, meaning they get back onto a healthy leaf.

An attacker would then need to be able to saturate all (or at least most) of the leaf servers to take down the network. In my experience IRC servers run on networks that far exceed IRC's requirements and taking down all leafs at once would be a tall order for all but the largest botnets.

There have also been anycast IRC implementations which I don't have experience with, but I imagine they would mitigate most simple DoS attacks.

IRC has been so DDOS prone for 20 years or so that many hosting providers explicitly disallow IRC clients or servers. No need to jump to conclusions.

I think you are confusing the use of IRC networks to systematically start a DDoS attack with a bunch of sleeping malware hanging inside an arbitrary channel.

He's not, I run an IRC network, a decent sized one.

they're prime for DDoS attacks and many attacks are hard to avoid with scrubbing.

We get attacked for anything, for, enforcing a no malicious behaviour rule, for "harbouring an enemy" of a certain group.

these kids are fickle, and IRC networks are ripe for abuse.

I mean, the reasoning why ISPs might block such services in use.

ISPs generally block them because they attract DDoS attacks like flies on... Rice. Attacks have collateral damage to other customers, and consumes a lot of support resources.

i don't

You don't what? You can type full sentences, there's no word limit here.

Just exactly what purpose would the government be serving by DDoS'ing freenode? I would think if they wanted to spy on us they would want the servers up and running and everyone able to connect so they can monitor. Killing the servers just disconnects everyone and if they continue to do it people will find other places, likely more than 1.

>Given that Freenode hosts channels for many open source projects, these attacks aren't just annoying bystanders, they're potentially affecting the progress of our technology.

As if governments could care less...

Some Minecraft servers I know have been getting DDoSed too. I wonder if they are using IRC for the chat backend, and if that is just getting his by these same things?

no.

There's no suggestion in that blog post that the security agencies have indulged in DDOS attacks.

Elsewhere in this thread, blibble linked to a (nearly five-year-old) blog post on quakenet.org entitled "Trust is not transitive: or why IRC over SSL is pointless" [0].

The article presents arguments that I've heard over and over again in the months since the Snowden leaks began. The argument essentially boils down to "we can't achieve 100% security even with SSL, so SSL is useless" and is completely wrong. It also misses the point.

The argument in the blog post is that, paraphrasing, since Carol can be MITM'd without her knowledge, everything is compromised.

It shouldn't be necessary to utter the phrase "defense in depth" here on HN as I would hope that everyone here is familiar with it. As I commented just six days ago:

> I have locks on my doors but that doesn't mean I don't have a pistol next to my bed.

Let me say that I'm not familiar with QuakeNet. (For the last several years I've only hung out on Freenode and two private IRC networks -- and I use SSL when connecting to each of them.) Freenode, however, has "NickServ" and the two private networks I use have similar functionality.

At the very least, SSL protects my credentials from being "sniffed" when I authenticate to NickServ. Anyone else on IRC can verify that the user with the nickname "jlgaddis" is authenticated and is really me. Since sensitive information is sometimes discussed, that authentication as well as the encryption is critical. Without SSL, it would be much easier to sniff my credentials, authenticate to NickServ using them, and impersonate me on the networks, possibly gaining access to sensitive information that would otherwise not be possible.

IRC over SSL is not pointless. If QuakeNet can't understand that and implement basic security precautions, I don't think they have much room to complain about being attacked.

[0]: https://www.quakenet.org/articles/99-trust-is-not-transitive...

so we've had a solution to the credential sniffing for 10+ years: our services support AUTH via something very similar to CRAM-MD5.

with that out of the way: you've missed the main point, and that is that it's really really hard (I would use the word impossible but I'm not 100% certain) to secure multiuser chat.

the sheer number of places that could be compromised is so high, that offering a 'secure connection' (which users associate with actually secure online commerce) is dangerously misleading.

we understand the threat model very well, and we recommend that you shouldn't trust us to secure your communications, and suggest something like fish instead.

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 assuming that us users are idiots.

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.

> so we've had a solution to the credential sniffing for 10+ years: our services support AUTH via something very similar to CRAM-MD5.

Interesting. This suggests you're storing all passwords in plain, is that true?

correct, which is far from ideal (essentially we're trapped by our CRAM-MD5 support)

we've thought long and hard about this too, and don't consider it to be a large threat, as the only two people with access to the box[1] could silently replace the AUTH code and log all the passwords anyway, rendering any secured password store irrelevant.

[1]: it's not even known outside the core where the box lives, and it's also essentially completely isolated from the internet at large.

Deleted comment

as I said it's not ideal.

the only point of entry onto the machine is via the auth service, so if you get in that way you have access to it.

it's not a matter of injecting code, it's literally one line to run spin up gdb attached to the process, and then one/two more more lines inside gdb to put a breakpoint on the line and print the variables on the stack when it's hit.

add in the fact that something like 95% of our users reconnect every 24 hours, so you get the vast majority very quickly.

yes, if the admins go rogue then we're screwed, but the same is true nearly always as they're the guys that set up the defences in the first place.

Unencrypted password storage. Easily reversible (or bruteforced) authentication. Easily MITMed protocol.

What year is this?

Just looked up CRAM-MD5, and the password is used as a key to HMAC-MD5, which means you can at least store MD5'ed versions of the passwords.

Add on a layer of encryption (unique key per password, keys in a separate encrypted table) and you're way better off than you are now.

Also, since MD5 can be collided, consider SSL for the login process.

> Just looked up CRAM-MD5, and the password is used as a key to HMAC-MD5, which means you can at least store MD5'ed versions of the passwords.

In real CRAM-MD5 this is not true. It uses HMAC-MD5 of the key directly. To be able to calculate that, you need to do

    MD5((key XOR opad) || ...)

Which means that you either store "key XOR opad" (not meaningfully different from storing key), or an intermediate result from MD5, which is tricky.

Quakenet's authentication mechanisms, except for LEGACY-MD5, call MD5, SHA1 and SHA256 before using it as the key, so they could store just each of those different hashes (unsalted). The LEGACY-MD5 mechanism does require the plain text password to be known by the server.

That's what I mean - store the intermediate result of the MD5(key XOR ipad) and MD5(key XOR opad). The only trickery is implementing the HMAC wrapper, but that's not very difficult.

Here's the auth mechanism the parent is referring to: https://www.quakenet.org/development/challengeauth

mIRC and irssi can handle it through scripts.

Contrast SASL, which is supported in every client I've used: https://freenode.net/sasl/

I don't know what fish is. Is it this?

http://ultrx.net/doc/fish/

Trying to shut down IRC on the internet feels a bit like the government is running around attempting to cut telephone wires in the hopes it'll get enemy agents to stop communicating, when all it'll really do is annoy a bunch of innocent bystanders.

IRC is also used as command and control for a lot of malware.

Bot-net owners can be disrupted if they can't access the channels their compromised machines are connecting to.

Telephone networks can be used to command and control spies too. Does that mean everyone who uses a public platform uses it for bad? No a subset of all users do.

I don't see what your comment adds to this discussion other then trying to justify their actions. I can use your logic for a few other examples:

Most terrorist enter the country by air travel, we need better airport screening.

Some people who cross the boarder illegally don't do so to find a better life, but to run drugs in america. We need better board protection and patrol.

Email is very useful to set up worm command and control networks, we should monitor or DDoS public email servers.

Your logic can be used to justify basically anything. Its a logically fallacy, the Strawman argument.

That's actually not an example of a strawman. It's certainly a ridiculous position (X could be used for crime, therefore ban X), but I'm not sure what you'd call it.

It's called a fallacy of composition.

You made his point for him...

This isn't much different then many other things governments do, like the war on drugs for example.

> Many of the charges being thrown at IRC users associated with the Anonymous movement are now clear to be identical to the actions of the agency itself.

The state not only has a monopoly on violence, but also apparently on hacktivism.

"We urge the British government to initiate an immediate and thorough public investigation..."

And now, for another caricature of British victim speak:

"Pardon me, Mr. Assailant, would you be a good chap and ask your right hand to stop beating me thus about the face? It's rather painful and I fear it might ruin my good humor."

humour* ;)

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.

we are now actively working on the problem for server links, but ultimately believe that having ssl for client connections at this moment in time adds little value: https://www.quakenet.org/articles/99-trust-is-not-transitive...

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...

There's still some value.

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.

Does QuakeNet runs services such as Freenode's ChanServ, NickServ, etc.?

At the very least, SSL helps protects a user's credentials when using such services.

Not the same as Freenode does, but Quakenet does have services, yes.

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.

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. =)

I think the government is behaving wrong when it doing the same thing as organized crime that is to run DDOS attacks in order to bring down servers. So when the government attacks platforms of free speech they have a problem with running against the core values of democracy.

Who would work for a government agency like the NSA or GCHQ? Anyone who is intelligent and well-minded must realize that these government agencies stomp on people's liberties in the name of security. I am sure that employees of these agencies come to work every day telling themselves that they are keeping the world safe. But their reassurances to themselves must sound hollow to themselves. I hope everyone working at these agencies realizes that. At least Edward Snowden did.

It saddens me to think that I once applied and actually wanted to work for GCHQ. Fortunately they told me to "come back when you've graduated" and that was enough time for me to come to my senses.

> Who would work for a government agency like the NSA or GCHQ?

At this point, I think they only hire psychopaths.

To what end would the GCHQ DDoS IRC servers? What would they gain from that?

According to the leaked documents, denial of the targeted users to communicate with each other.

Basically, jamming communications between internet terrorists / freedom fighters (depending on your stance on the matter)

And/or just regular people who chat with each other.

EMP'ing the telephone exchange hopping to cut off the bad guys phone calls to each other.

Telling their boss that they did something.

DDoS has also been used to cause netsplits, which can then be exploited to gain access to private rooms.

On any sensible IRCd this won't happen. Users sneaking in during netsplits will be booted as netriders when the split closes.

They wanted to stop AnonOps from enabling the planning and execution of Anonymous operations. They bragged that a month after "rolling thunder" that the same nicknames/operations weren't there anymore. It's hardly effective, mostly childish.

That news is covered here:

http://blogs.csoonline.com/other/2979/irc-network-calls-inve...

I wonder, why DDoS the IRC servers, if you can find out the IP addresses of the "offending" users via /WHOIS and then inject TCP FIN packets to disrupt their connections.

After all the NSA has the capability to do very deep going traffic manipulation as proven with Quantum Insert, so why not use it here?

QuakeNet makes it trivial for a user to hide their IP from other users on the network. If you are registered with Q (a network service) and set mode +x on yourself, you will now have the host username.users.quakenet.org.

/whois doesn't work if you are cloaking your hostname or just connect via tor/vpn or just some random place. Probably easier to just target the central node.

Yeah, but how many scriptkiddies use a VPN or apply for cloaks? Next to zero for most of them.

Also, I bet my behind that the NSA has epxloits for the most popular IRCd's, so that only tor/vpn are a real problem for them (and besides, even these connections can be shot with TCP FIN injections).

Actually the vast majority of script kiddies and "cyber criminals" use VPNs. The problem is that they have a habit of accidentally connecting to servers without always turning on their VPNs. They lack professional discipline, not toolsets.

On plenty of networks (it's been years since I was on IRC, so unsure which IRCd's support it, but iirc both Quakenet and Freenode do in slightly different ways) even support host-masking as long as you are auth'd on the network - of course, IRCops could still find out, so a subpoena (or hacking into the servers) could see it, but prevents /whois from telling you at least.

(I think some networks even partially hide your IP by default anyway)

Scriptkiddies have very good how to guides and they are always shown to hide their IP address.

I tend to doubt that there's many exploits out there for the popular ircds, because IRC is such a hostile environment - ircd is probably one of the most battle-hardened codebases out there.

"inject TCP FIN packets"? really?? that would be like making a public statement saying "HI WE ARE THE NSA FUCK YOUR INTERNETS"

Sorry but no, that's not the way they do it....

Even assuming there would have been a valid reason for law enforcement to disrupt the communications of those individuals, how could an intelligence agency be justified in doing so?

Try to remember the NSA is an intelligence agency, not a law enforcement agency. They're not interested in producing evidence and bringing anything to trial.* Rather, they're targeting anonymity and privacy in all forms since these oppose their core mission (Signals Intelligence (SIGINT) and Information Assurance (IA)... http://www.nsa.gov/about/mission/index.shtml).

* Though through inter-agency collaboration, they tip off other agencies when they have something...

I still don't see how disrupting the ability of individuals to communicate with each other does anything to undermine anonymity and privacy.

For this discussion's sake, there are two forms of communication: (1) The public forum you can meet up with new people and talk. (2) And the direct message sending kind like phones and emails. Though the NSA is actively monitoring both, here we're discussing the latter.

With that out of the way, they're targeting the former in-order to make it impossible for people to come together and organise privately and anonymously around subversive ideas.

The specifics of targeting IRC are probably tied to the efficiency of the protocol which allows very cheap hardware and minimal bandwidth to the extent that non-complying private foreigners may provide a free forum the government can't control.

I don't really understand the point of bringing age into their argument ("overly eager teenagers"), but I tend to agree that DDoSing IRC servers is the lowest form of low. Let us idle in peace!

It is unlikely that "overly eager teenagers" are doing anything other than playing around or engaging in raw, unbacked braggadocio, as is especially the way of the male teenager. It is unlikely that targeting these users, shutting them down, or prosecuting and convicting them will do anything to enhance security, but it will cost the government money, incur an opportunity cost as these resources are wasted while more reasonable (if less sexy) things that might actually have a positive effect are left undone, and, oh, last and most assuredly least from the government's point of view, it may destroy young lives which were quite likely on a track to be otherwise quite productive, computer-savvy citizens. (How many people here can tell tales of early, somewhat-less-than-legal activities before they became productive members of the computer world?)

I've phrased it with "probably"s on purpose; every once in a while a teenager will manage to escalate to the "true threat" level. However I think it is likely such a teen will either A: tend to show up by other, more practical measures or B: slip through a crack regardless; it doesn't justify harassing relatively innocent and frankly naive users, for what is probably little more than the purpose of padding numbers to make your enforcement look good by going for cheap, easy targets, regardless of whether that's good for anybody else.

It's more of a play on 'juvenile behavior', as in, Anonymous DDOSes whoever they don't agree with under the pretense of 'FREEDOM!11ONE' or whatever. Speaking of low.

Is there any actual evidence that QuakeNet is being attacked by governments? Just because they did it in 2012 doesn't mean that's what's happening now.

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 :-)

As an oper of a small IRC network, I agree with this blog post.

Not that i've really ever used quakenet myself.

Meanwhile they censor anyone running Tor internal relays on the same IP by g-line banning them.

Tor allows for rampant abuse and is problematic to prevent. Many IRC networks ban it due to this.

However, the solution is to make it so if you want to use Tor on an existing that you instead connect via a hidden service address, allowing the IRCd to mark you as a Tor user and then allow channels to stem abuse.

I said an internal Tor relay, not an exit node. My IP cannot be abused for irc spam. These Quakenet guys are just against tor.

I am also on some blacklist, and while I can still connect to most channels, some don't work anymore. Because of this blacklist I cannot join #help, which is the channel I must connect to if I want to ask them anything, such as which blacklist I'm on. Finally I got a friend of mine to ask them for me and a #help operator /queried me (private chat), but they won't disclose which blacklists they use. Meanwhile I haven't been able to find any, and if I'm on something, I wouldn't know what for.

So that's my experience with Quakenet, censorship and non-disclosure of blacklists. Then they publish this and reach #1 on Hackernews? Come on. Bullshit. They don't give a flying fuck about freedom of speech.

irc.perl.org doesn't disclose its BOPM config either.

This is because when we're getting attacked we want to force the attackers to go to the trouble of trying to connect, rather than being able to filter their set of available client nodes to the ones not blacklisted before attempting to connect. Makes attacks more obvious and makes attackers work harder.

Free, volunteer run services sometimes have to make decisions that prioritise being able to deal with problems within the available resources over the well being of the occasional individual user who ends up being caught as a false positive.

After all, if the network just got taken down entirely, it can't transmit any speech at all.

we actually don't, the only thing tor specific we do is set to their host to something along the lines of 11223344.tor.gateway.quakenet.org.

OTOH a lot of people do naughty things through tor (e.g. mass flooding) and get caught automatically by the network services, resulting in a large %age of tor hosts being banned for short periods.

> we actually don't, the only thing tor specific we do is set to their host to something along the lines of 11223344.tor.gateway.quakenet.org.

Then explain to me why my client was reporting disconnects for months after the week I hosted that relay? I was unable to connect to any Quakenet server.

Also I'm not a Tor gateway if I'm running an internal Tor relay. There is no need to change my hostname.

And can you also tell me which blacklists you check user's IPs against? As I've commented elsewhere, I was on some sort of blacklist that prevented me from entering #help, but someone from #help (that a friend of mine talked to) said it could not be disclosed which blacklist that was. Note that this happened before any Tor relay activities.

ah, sorry didn't notice the relay bit.

we don't do anything explicitly to relays.

we get the tor ips from tor itself, and filter out hosts that have a connection policy that would result in them not being able to connect.

we do however source and combine multiple proxy lists, which I suspect you ended up on.

I seem to remember you were chatting to me, and I said something along the lines of 'try again tomorrow and if it's still broken I'll sort it out manually', and you didn't come back!

I'm not sure how many people get this, but I think you might be confusing me with someone else. The blacklist thing was like a year or two ago. I don't remember all the details ;)

Thanks for replying to this anyway.

yeah, I just tried to connect using irssi from my non-exit relay, works just fine...

As pointed out by blibble, the blocking is almost certainly due to Mr. Angry having got himself onto a list of open proxies somewhere along the line; any effort directed at tor, whether masking, restricting, or outright blocking, is in my experience always aimed at exit nodes only - because there's simply nothing to be gained by blocking relays.

Note that I have no particular insight into this specific case, but have opered on irc.perl.org for some years now (and was freenode staff for a while) and am working based on a >95% correlation with previous similar cases that I've dealt with myself.

Odd, my experience differs.

Could we leverage a VPN tunnel over short band radio waves? This would allow us to detect a Man in the middle attack, as well as provide decentralized access. The speeds would be slow, and the network could be 'jammed' but it could work for medium distance messaging.

What's the point of governments attacking IRC? It's wide open for spying.

Why the F* don't we have popular encrypted IRC systems yet? This should/could have existed as of 10 years ago..at least. This is a serious question.

Server-Server and Servier-Client SSL is a thing for IRC. Of course if you operate one of the servers then you naturally see everything that goes through it. Any anybody in the same channel sees everything in that channel, since that is the point of IRC.

IRC clients typically also support DCC, though I am unaware of what the encryption options there are. There are are other forms of encrypted "IMing" however, if you want secure peer-to-peer text chat you should probably look outside what irssi has to offer.

I'm not really clear how you would encrypt an IRC network? Its very nature is one of wide dissemination.

You can use FiSH, but that's really mostly for one to one communication in which both parties are trusted. I suppose you could use it for group chat, but it would become harder and harder the more people that were added (what happens if you trust all of them, but two of them don't trust each other and so on). There are plenty of good options for encrypting real time communication.

Encrypting group chat is a much more challenging issue and one could argue it goes against the whole spirit of IRC.

So, these guys are extending on the irc protocol: http://ircv3.org/

I thought it was clear that those attacks are happening ever since LulzSec was taken down by embedding operative wannabe on IRC.

Does anyone have a mobile friendly mirror? The site isn't readable on iOS 7 Safari.

https://gist.github.com/paraboul/8844618

That's lacking linebreaks, so: http://pastebin.com/LPdkh5R5

It's sort of not readable on my desktop, the lines extend off the browser. In Firefox I View/PageStyle/NoStyle. Is anything like that implemented on mobile browsers?

I don't understand - is QuakeNet saying it has unique evidence that it specifically has been targeted by DoS attacks perpetrated by GCHQ, or are they guessing it's the GCHQ based on the report done by NBC?

Specifically, this line:

> as well as wholesale attacks on the IRC servers hosting the network.

What is this?

It's pretty disingenuous to downplay attacks vs Anonymous as motivated by them "engaging in such topics with an opinion contrary to that of the intelligence agencies". No, that's not agencies go after Anon. Agencies go after anon because of the actual criminal activity.

edit: I'm receiving disagreement downvotes. What's up?

>Agencies go after anon because of the actual criminal activity.

Where is the due process? There isn't any. Please tell me which actual crimes that some Anons have committed whose consequences are so critical that it justifies the abandonment of longstanding principles of fair governance, and military action to sabotage IRC operations in order to halt the occurrence of said crimes.

You don't give due process to imminent threats.

It ends up fitting well into a battlefield metaphor - you don't try every single enemy soldier before you shoot them on the battlefield.

The argument can be had whether or not this is indeed a battlefield, but to cry, "due process" won't get much of a reaction out of the folks who are doing this (GCHQ/NSA).

>You don't give due process to imminent threats.

We do, in fact. But I can agree that we rightly don't allow imminent threats of grievous injury or disaster to proceed unchecked. Please, show me what grievous injuries and disasters have been or would have been wrought by anon via IRC. PS Defacing the DOJ website and sending black faxes to US attorneys doesn't count.

>It ends up fitting well into a battlefield metaphor - you don't try every single enemy soldier before you shoot them on the battlefield.

Except this isn't a battlefield and we're not at war.

>The argument can be had whether or not this is indeed a battlefield, but to cry, "due process" won't get much of a reaction out of the folks who are doing this (GCHQ/NSA).

Then they need to go. They have no function in a free/democratic society. If we must keep them, then they cannot have any judicial influence.

> Then they need to go. They have no function in a free/democratic society.

Snowden himself has said that spy agencies have a place, when they're doing targeted operations. Maybe you should go convince him?

This argument is a non-starter, because you already begged the question. The argument revolves around whether or not this is a battlefield, and if we are or are not at war.

I see. Can we agree that Ian Fleming and Tom Clancy wrote fiction?

Quite good fiction, I'd even say!

I mostly agree with you, but my point is this article is misrepresenting the motive behind those attacks as "these people disagree with the government - quick, silence them" which is obviously not what's going on.

Isn't it? Where is the evidence that the targets of the government attack have been given due course to defend themselves in an open court of law, with due process, based on widely acknowledged and agreed upon state law?

There isn't any. That's why this is a politically motivated attack on speech and little else. If you can't see the fascism from here, maybe you're standing too close.

Evidence of them being given due process is off topic. We are talking about the motives behind the unlawful attacks on Anon. It is not up for debate that a lot of illegal shit is being done and taken credit for by anonymous members of Anon. That is the reason for the actions, not because of Anon's politics. You can't just say since they haven't located specific Anon members to prosecute for those crimes, therefor there cannot possibly be a reason except "rrrr I need to silence you". That doesn't follow.

The DEA raided the known drug den, but since they hadn't conducted court trials first, it could only be because the drug dealers espoused anti establishment political messages!

It's not off-topic at all. Not only has anon been deprived of due-process, so have many people who are completely unrelated, and who are not involved in crime at all.

>It is not up for debate that a lot of illegal shit is being done and taken credit for by anonymous members of Anon.

Most of which are mere nuisances, and none of which involve any immediate danger which might justify such action.

> That is the reason for the actions, not because of Anon's politics.

Okay, then why doesn't GCHQ intercede when they overhear someone planning a burglary, or notice them planning to murder some average plebe?

>Okay, then why doesn't GCHQ intercede when they overhear someone planning a burglary, or notice them planning to murder some average plebe?

Exactly. These attacks by GCHQ on innocent members of the public are entirely politically motivated. If due-process is to be done away with "because terrorism" then I'm afraid this leaves a lot of doors wide open for civilians to denounce their government, and rise up in revolution - because without such checks and balances on power, we live in a totalitarian world where those in power, are the only ones with power.

Power, to the people!

Reply on news.ycombinator.com