3 ms·

author here, note that my view has somewhat changed from that which I held in 2009 from "it's silly" to "we'll do it if when we solve a few problems first." PK

author here, note that my view has somewhat changed from that which I held in 2009 from "it's silly" to "we'll do it if when we solve a few problems first." PKI deployment in a semi-untrusted environment is still very difficult. freenode messed it up by sharing their private key between all irc servers, which are hosted on other people's hardware. they had servers compromised in this period, and no forward secrecy enabled, so any TLS traffic captured over those multiple years has been effectively compromised. presumably this was done to save money on CA fees, a problem that's gone away now that letsencrypt exists. note that when I wrote the article the general assumption was that openssl was a reasonably good piece of software... not many people hold this view today. an ircd isn't as easy to upgrade as nginx, upgrading them each time there's a new openssl vulnerability would make for a very splitty network. separating the tls termination from the ircd (and locking it in a seccomp sandbox) would allow it be restarted independently... and is in progress. (re: nickserv passwords, our channel service supports CRAM-MD5, so that isn't really a problem)

asuffield 11y ago
I used to do most of the dev work on freenode for a while, years ago. I said no to the ssl plans, for pretty much the reasons you describe. After I moved on, some people built the bad thing anyway, and we saw how well that worked out. The lesson that I take from this is that saying "no" to people who want to build a bad idea isn't sufficient, because it's just pitting your energy against theirs. You need to lick the chocolate by building something that is good enough to remove the incentive to build the bad idea, without replicating its worst flaws. I should have built the damn thing myself.
- pfg 11y ago
  Out of curiosity, do you know if they've changed how they distribute their keys? This seems like a perfect candidate for something like CloudFlare's Keyless SSL, but I'm not aware of any ircds having support for something like that.
torgoguys 11y ago
Because you don't have a perfect solution, you don't want to do anything? Really, as mentioned many times elsewhere in this discussion, a half-assed implementation is better than none. A poor implementation would probably solve not even just a few, but a majority the issues that a "perfect" implementation would. Just disclaim the quality of the solution to the users and be done with it until you can come up with something better. You cite the freenode mess. All true. Even with that major screwup, it protected their users to a certain extent, even with compromised keys after the fact. (The majority of snoopers aren't motivated enough to store the ciphertext).

asuffield 11y ago

I used to do most of the dev work on freenode for a while, years ago. I said no to the ssl plans, for pretty much the reasons you describe. After I moved on, some people built the bad thing anyway, and we saw how well that worked out. The lesson that I take from this is that saying "no" to people who want to build a bad idea isn't sufficient, because it's just pitting your energy against theirs. You need to lick the chocolate by building something that is good enough to remove the incentive to build the bad idea, without replicating its worst flaws. I should have built the damn thing myself.

pfg 11y ago
Out of curiosity, do you know if they've changed how they distribute their keys? This seems like a perfect candidate for something like CloudFlare's Keyless SSL, but I'm not aware of any ircds having support for something like that.

torgoguys 11y ago

Because you don't have a perfect solution, you don't want to do anything? Really, as mentioned many times elsewhere in this discussion, a half-assed implementation is better than none. A poor implementation would probably solve not even just a few, but a majority the issues that a "perfect" implementation would. Just disclaim the quality of the solution to the users and be done with it until you can come up with something better. You cite the freenode mess. All true. Even with that major screwup, it protected their users to a certain extent, even with compromised keys after the fact. (The majority of snoopers aren't motivated enough to store the ciphertext).