Comment by jlgaddis | Hacker News Reader

Comment by jlgaddis | Hacker News Reader

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.

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

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.

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.

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

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

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/

Reply on news.ycombinator.com