6 ms·

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 pointle

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-or-why-irc-over-ssl-is-pointless https://www.quakenet.org/articles/99-trust-is-not-transitive...

blibble 13y ago
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.
- xnyhps 13y ago
  > 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?
  - blibble 13y ago
    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.
    - pixl97 13y ago
      Unencrypted password storage. Easily reversible (or bruteforced) authentication. Easily MITMed protocol. What year is this?
    - deleted 13y ago
      [deleted]
      - blibble 13y ago
        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.
    - optimiz3 13y ago

blibble 13y ago

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.

xnyhps 13y ago
> 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?
- blibble 13y ago
  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.
  - pixl97 13y ago
    Unencrypted password storage. Easily reversible (or bruteforced) authentication. Easily MITMed protocol. What year is this?
  - deleted 13y ago
    [deleted]
    - blibble 13y ago
      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.
  - optimiz3 13y ago