Comments on Short packet: CAcert.org - you got what you paid for

CAcert's official position was posted the followin...

2008-09-14T16:36:00.000-07:00

CAcert's official position was posted the following day by way of a vulnerability note explaining the fix that was promptly implemented. The views of individuals are at best community views and do not necessarily reflect the views of CAcert, Inc. nor the community as a whole. There are many passionate people working towards a common goal and I can assure you that there are those who care greatly about security among them (myself included).

It is worth noting that there has recently been much discussion about address and domain validation (AV, DV) and the solution passing audit & presented for browser inclusion will be more secure than what we have today.

Cheers,

Sam
CISSP

I agree.To the people from CACert (?) who replied ...

2008-09-05T17:56:00.000-07:00

I agree.

To the people from CACert (?) who replied in other comments (evaldo): sorry, you totally miss the point, which makes this even more painful than it already was.

This is astonishing... CAs are one of the only instances that need more security than a bank... what the hell does it take for people to take that seriously?

I just do not even want to think about this any more.

So, let's only include in browsers root certs for ...

2008-08-23T13:19:59.130-07:00

So, let's only include in browsers root certs for CA authorities that we know have good code quality.

I believe my argument was to be extremely cautious about a CA where code that shouldn't have been in production in the first place - is in production. Hence, "we know there's a pretty nasty risk here."

As opposed to what you're saying above which is, allow me to paraphrase, "we don't know whether or not there are any risks here."

I know it's on CAcerts radar to improve security and I believe that they have a decent shot of doing so, should they manage to find some more manpower. That doesn't really diminish the fact that there's risk, it's unnecessary, it's unwarrated and it's here today. If they manage to fix their issues in a satisfactory manner, I'll be the first guy to blog something supportive about it.

(That's the important part of this reply. The rest is just sugar on the top..)

All kinds of corporations that pass all kinds of audits produce all kinds of lousy code. The only way to know whether code is really good is to publish it.

..and in this case it's published and bad to the extent that I think that users shouldn't be exposed to the risk - or at the very least should be aware of it. If you disagree, hey, that's fine. Debian does too.

Random security researchers don't have any financial incentive to not report problems in a codebase and so they are honest.

I disagree, and that's one of the reasons I'm somewhat vocal about CAcert: You can certainly sell exploits.

Take the same security researcher and have them employed by some auditing firm and now they have an incentive to be more lax - since the guy paying the bills is the guy who wrote the code.

I'm not sure what sort of experience you have with code auditors, but that doesn't sound like the norm. Starters, the boss of the boss of the guy who wrote the code is the one likely to sign off the auditors bill and the auditors are likely to want to prove their worth as much as possible. There's absolutely no gain to being lax, when you can earn so much more in terms of brownie points by highlighting even pretty trivial downsides with the code.

Sure, I'd agree that overall code quality is more ...

2008-08-23T11:05:36.341-07:00

Sure, I'd agree that overall code quality is more important than whether any one particular bug is fixed.

So, let's only include in browsers root certs for CA authorities that we know have good code quality.

Hmm - looks like we need to get rid of all of them. I don't know anything about verisign's code quality, and neither do you. Sure, they passed some 3rd-party audit, but somehow I doubt that this organization is looking at their source code so much as checking that they have a board of directors and screen employees, etc.

All kinds of corporations that pass all kinds of audits produce all kinds of lousy code. The only way to know whether code is really good is to publish it. Random security researchers don't have any financial incentive to not report problems in a codebase and so they are honest. Take the same security researcher and have them employed by some auditing firm and now they have an incentive to be more lax - since the guy paying the bills is the guy who wrote the code.

"Sure, a bug is a bad thing, and you know we are w...

2008-08-21T05:37:08.204-07:00

"Sure, a bug is a bad thing, and you know we are working on minimizing problems."

I (still) don't think that the one bug is the actual issue of a shaky code base, but it seemed prudent to move the discussion to IRC rather than run a game of blog tennis, so such was done.

At least, we are showing you our codebase, what ab...

2008-08-21T03:41:25.914-07:00

At least, we are showing you our codebase, what about others?. Sure, a bug is a bad thing, and you know we are working on minimizing problems.

Now, are you right to make CAcert the martyr of your cause? Take a look at the following url. IT IS NOT JUSTIFICATION, it is just another example of how things go bad. Now, did they remove Verisign and Thawte from root lists? There were too many problems you never learned about in the CA world

http://www.benedelman.org/news/020305-1.html

"A lot of people criticise CACert but none of them...

2008-08-21T02:27:19.803-07:00

"A lot of people criticise CACert but none of them provide solutions, implement something better, or actually put their criticisms into context. You seem to be another one of those."

The solution in my book is to get the root cert the hell out of anywhere even remotely mainstream until they got a grip on their operations and codebase. As for the actual coding bits, I've been (briefly) in touch with CAcert and offered some ideas about tools and practices which might make it easier to maintain.

Compare this to any other default package, though - "There's probably bad holes in this, it's bloody hard to audit properly, users can be affected without knowing they're even at risk." - would you keep that package in the core distribution until it was fixed? Further, would you rack down on people reporting issues about it with, saying "You don't offer solutions so you don't have a say"?

"Yet, you raise hell over the issue as if it was the worst thing ever."

I think you missed the point, though: Arbitrary certificate issuing for .jp was a case in point for "the codebase is horrid, there are bad holes and it's pretty damn easy to run across them". One thing you didn't see was the second hole a few days later allowing arbitrary issuance of client certificates (it was posted as 'private' in their bug tracker and never publicly commented upon by myself or CAcert), and I'm guessing you also didn't see the GPG related bugs of similar magnitude (not found by me, but see their tracker for info.)

"You don't even /know/ of all the problems with commercial CAs, but you are willing to trust webtrust based on documents they publish?"

I believe it covers enough technicalities (even though the document isn't that technical all by itself) to raise an eyebrow if the production system is running PHP with register_globals on, yes. It wouldn't cover everything, of course, and I'm not saying that other CA's are infallible either. But again, you wouldn't say "Yeah, so what, there's a bad state of affairs in Apache, but for IIS, we can't even see the code, so let's ignore the one we have at hand.", I'm guessing?

"And in as such, being the person responsible for CACert's inclusion in Debian's ca-certificates and Debian's Mozilla products, I will continue to further CACert, because I believe in what they are doing, and because you have not convinced me of anything with your slander."

I'm sorry to see that you put politics or ideals in front of security - it doesn't make sense to me, at all. I too like the idea of CAcert, but unless they can run it like a CA should be run - with a decent baseline of security - then the 'idea' is worth jack, since PKI is all about trust in the end. You're basically implicitly granting trust for something that does not have the ability to support it at this time. And you do this for millions of users, because you 'like the idea'?

As for slander, I think that finding/reporting two pretty nasty holes, both stemming from a non-use of anything resembling best practices give me the right to claim that the code is less than stellar without being called a liar.
Still don't believe what I'm saying? Check out the code base yourself. Takes ~5 minutes.

A lot of people criticise CACert but none of them ...

2008-08-21T01:01:53.468-07:00

A lot of people criticise CACert but none of them provide solutions, implement something better, or actually put their criticisms into context. You seem to be another one of those.

Before this was fixed, you could have possibly taken over some Japanese TLDs, but nobody actually knows which ones. Yet, you raise hell over the issue as if it was the worst thing ever. You don't even /know/ of all the problems with commercial CAs, but you are willing to trust webtrust based on documents they publish?

CACert may have some way to come, but they are the only ones on the right path, if you ask me. As such, I am happy to support them, getting a lot for no pay. And in as such, being the person responsible for CACert's inclusion in Debian's ca-certificates and Debian's Mozilla products, I will continue to further CACert, because I believe in what they are doing, and because you have not convinced me of anything with your slander.

I'm not really saying that you're evil, mind. The ...

2008-08-15T04:56:51.119-07:00

I'm not really saying that you're evil, mind. The issue isn't really the specific vulnerability either (that was a case-in-point), rather the platform as a whole.

Normally I wouldn't mind as much - shit happens and it's up to whoever is running a system to know and assess the risks, especially if the code is open.
Not so much with a CA though - any vulnerability on your end could mean a security issue for any user with your root cert installed. They wouldn't even need to know that they have your root cert installed.

Given that outset, I think your codebase really isn't suitable for the task and disclosed why I think this to be the case and why I question the judgement of operating a CA on it, seeing it doesn't really allow for either good maintainability or a good security standard (register_globals in combination with these two is outright scary)

It's pretty hard to make that statement without it being a bit of a slap in the face. I'm aware of and sorry for that, but I can't really see how to avoid that.

CAcert has fixed the issue shortly after reported ...

2008-08-14T06:30:20.089-07:00

CAcert has fixed the issue shortly after reported and disclosed an advisory. Looks like we are not that evil as you say. Perhaps giving us the hint before going to public shame would be a more courteous way of handling the issue. Thanks for the bug report :) http://blog.cacert.org/2008/08/321.html