On Sat, May 29, 2010 at 7:22 PM, Aaron Wiebe <epiphani@gmail.com> wrote:
I disagree. If you can trust your irc server/network, ssl provides benefits: I know that content in transit between me and my server cannot be decrypted. That was the _ONLY_ goal of ssl.
As I said, it's real benefits are few and far between -- not that they don't exist.
This argument is bull. The same could be said of every single other ssl mechanism out there.
Bahamut is not trying to be silk. If you want full, end-to-end encrypted chat that addresses all of your concerns, use silk. And for the extra paranoid, run it over tor. We implemented SSL for two reasons: feature parity with other ircds out there, and the client<->server tcpdump snooping prevention. I'll address some of the usability and implementation quirks that have been mentioned in this thread, but the direction this conversation is going is pointless.
-epiphani
Other implementations suffer from the same problems, but the incentives are different. That doesn't make the example I gave any less valid. BTW, I was specifically referring to services such as mibbit (qwebirc mostly being an exception). Yes, that example doesn't really hold true for java applets, and I agree with you there. I'm not by any means advocating for true end-to-end encryption. I don't think that is feasible for IRC, and frankly, not needed. I understand why such functionality was implemented in bahamut, and, ironically enough, I just finished up a patch for implementing SSL in ircu .12. There is some value in SSL-enabled connections, I don't dispute that. I just don't feel the value it does provide is that significant -- obviously others disagree, and that's fine. I was merely pointing out that the ircd cannot ensure the security of any conversations taking place in a channel, and simply should not try -- which was the direction the conversation was heading in when I replied. That doesn't make cmode +S pointless, but users should understand its limitations. -Jason