CACert.org is basically a self-signed Certificate Authority with aspirations of having its root cert included in as much mainstream software as possible. They're included in some Linux distributions, a couple of BSDs - notably OpenBSD - and aspire on being included in Firefox/Mozilla (which would probably make the certs signed by them at least moderately useful for mainstream usage).
Let me say this first - I rather like the idea of a free CA. Philosophically it's a nice idea. The most important thing though, is not that the CA is free - it's that the CA can be trusted.
I've come to the conclusion CAcert.org can not be trusted. Whether or not you share that sentiment is entirely up to you - I'll outline my own reasons below.
Summarizing them a bit: The source code is available (definite plus), they have a formalized structure of sorts, they are fairly transparent and they audit themselves. This is all good things that I - as a presumptive user - would be expecting.
The thing that gets to me, though, is that they manage to miss out on some of the very fundamental things. If you run a CA, you probably don't want to run it on PHP. If you run it on PHP, you probably want to run a recent version and follow best practices. If you don't follow best practices, you really, really don't want to have register_globals enabled.
And if you insist on blowing all of these fairly sane precautions, bad things can happen:
(Basically means 'which email address would you like to use to verify that you control yahoo.jp so you can get a cert for it'.)
The code base is, in a word, horrid. Bad or no documentation, cases of input being sent to the database without quoting and it seems that some older code - containing what looks like vulnerabilities - got some sanity checking code tacked in front of it without really fixing the main issue.
Case in point - not a whole lot of random peeking allowed me to bypass one pretty damn important security feature (in some instances at least - it's not a generic exploit), and I'm not a vulnerability researcher. If it takes a bit of HTTP knowhow and a few Google queries to get signed certificates for domains I'm in no way associated with, I'm guessing someone who's actually into PHP security could do a whole lot more.
It's good that they have processes, but if it comes to the point where we see schoolbook examples of bad programming, the code really shouldn't be in production in the first place.
And this brings us to what is important in a CA - trust. To trust a CA, you should trust the organization maintaining it. In this case, the board hasn't managed to get a good reality check of the state of the 'product' (or if they have, they're ignoring it / keeping mum), the programmers just plain haven't done a good job and the auditor(s) really, really shouldn't have missed something this obvious.
I don't want to see the root cert of this CA in Mozilla. I don't want to see it in Debian. How it managed to slip by OpenBSD's radar is beyond me. I certainly do hope, though, that there will be a decent free and/or open CA some day - hell, it might even be CAcert - but saying that they're good because they're free and they should be included in as many places as possible because of this is just not sound thinking.
At least to me, running the operation like they do means that they probably shouldn't be trusted without a complete overhaul in code and management. It's that bad.
Finally: I'm perfectly aware that there might be commercial CA's out there with pretty bad bugs of their own - but at least webtrust ensures that they didn't do the classical schoolbook examples of bad security and practices. This peace of mind is well worth $15 a year for a cert.
YMMV, of course.
[Edit: The exploit mentioned above was fixed in a very timely manner once pointed out to the CAcert chaps.]
11 comments:
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
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.
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.
"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.
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
"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.
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.
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.
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.
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
The main task of the SSL certificate is data encryption. Encryption should protect your password in every possible location, browser makers should pay extra server owners for the use of SSL.The issue of verification of the server, it should rest on DNSSEC and designed to provide encryption certificate should not have anything to do with it.
Post a Comment