Marc Branchaud wrote:
Ben Laurie wrote:
Incidentally I was put under a lot of pressure when releasing the OpenSSL advisory a few weeks ago to allow CERT to notify "vendors" before going on general release. I have a big problem with this - who decides who are "vendors", and how? And why should I abide by their decision? Why should I pick CERT and not some other route to release the information?
I agree that such pressure is pretty reprehensible. As others in this thread have said, it's your decision how you want to publish the information. People should respect that decision.
However...
Also, if the "vendors" were playing the free software game properly, they wouldn't _need_ advance notification - their customers would have source, and could apply the patches, just like real humans.
I agree with that to a certain extent. However, we (RSA) recently had to release patches to several versions of Xcert's old Sentry CA because of the OpenSSL fixes. I do not know how our customers would have been helped by having the source.
First, I want to point out that Xcert's use of OpenSSL was entirely in agreement with OpenSSL's license. The fact that we built closed-source product atop OpenSSL was playing the game properly, as far as the rules were laid out. (If you think OpenSSL's users should behave differently, change the license!)
I have two points to make about this: a) We can't change the licence (until we rewrite the whole thing). b) I like BSD-style licences because it means people get to use the software even if they are doing the wrong thing - but I do hope they'll see the light in the end and do the right thing.
Even if we gave our customers our source code, we had made a few changes to the OpenSSL code for use in Sentry CA. Mostly to deal with things like PKCS#11 and ECC (we used OpenSSL for crypto, some ASN.1 and SSL).
Correct answer: contribute the patches back to OpenSSL, then you don't have this problem.
So patches don't necessarily apply perfectly cleanly (though these ones did). It seems unreasonable for us to expect our customers to make the appropriate changes themselves. (We even had to make our own patch for a particularly early version of Sentry CA that used a verison of OpenSSL that did not get a patch from openssl.org. There's nothing like money to bring out the whore in all of us...)
That's probably fuller of holes than I care to think about.
Also, one of the selling points of Sentry CA was that it's thoroughly tested. We had to make sure that the patches didn't break the product. Again, we can't really expect our customers to do that themselves.
Vulnerable or potentially flakey would be their choice until you've done your testing. I know what I would choose.
Now, I'm a big fan of open-source software, and am very sympathetic to its ideas in many ways. All I'm trying to point out is that the issues aren't necessarily so black-and-white. We certainly could have benefitted from advanced notice of the flaws, but I personally think that "vendors" shouldn't get first dibs at any patches. That said, I don't really know what we could've done with the news while waiting for OpenSSL's patches to come out.
There would have been patches, too, of course.
So the way things happened is probably the fairest outcome possible. It was a rough couple of weeks for us, though, getting our own fixes together while OpenSSL was sitting pretty. Customers don't seem to like _knowing_ they're vulnerable, for some reason...
Because they know that the attackers know, too, of course. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff