Mozilla Asks All CAs To Audit Security Systems 77
Trailrunner7 writes "Already having revoked trust in all of the root certificates issued by DigiNotar, Mozilla is taking steps to avoid having to repeat that process with any other certificate authority trusted by Firefox, asking all of the CAs involved in the root program to conduct audits of their PKIs and verify that two-factor authentication and other safeguards are in place to protect against the issuance of rogue certificates."
At least stick the CA keys in HSMs... (Score:1)
Please... at least put the CA private keys in HSMs so there is an audit trail if everything else gets haxxored around.
Re: (Score:1)
Well, I think the Comodohacker alluded that the DigiNotar's netHSM was hacked, which, if that's not bs, means that there could be a 0-day in OpenBSD. Or, maybe the so-called NETSEC backdoor [eweek.com] is real and the dude is exploiting it.
Allegations of OpenBSD Backdoors May be True, Updated [linuxjournal.com]
Re: (Score:1)
1. You're stupid.
2. It's bugle, not buggle. Buggle isn't a word.
3. You're stupid.
why don't they do this already? (Score:3, Insightful)
They do this already. (Score:3)
My software company was in line to provide signature validation services for the State of California. Although we didn't land the contract, finding out what it took to become a legally recognized CA for California was part of the process. California (and by extension, most governments) requires a SAS70 audit. Performed once, and then re-performed annually. The audit itself cost about $25,000, we estimated the actual cost of compliance at $250,000.
That's an approximation of what it costs to become a legally
If you ask nicely enough... (Score:5, Insightful)
Re: (Score:1)
Security does not need to be expensive to be good.
But these companies were not in business to provide security services.
Re: (Score:1)
Security requires attention. Attention requires man-hours. Man-hours cost money. Providing something without caring about security will always, in the very shortest term, be cheaper than providing it securely. In the medium or long term, that can change dramatically, of course.
Re:If you ask nicely enough... (Score:4, Insightful)
And in this particular domain even the customer doesn't care.
Sure I could spend more of my time and money finding and using the CA with the best security practices. But when the cheap-n-nasty is hacked to generate (or just hands out due to their lack of checking) a cert for my domain to someone else that the CA I chose wasn't hacked is completely irrelevant. I've gained nothing by choosing the more secure provider.
So of course you have a race to the bottom...
Re:If you ask nicely enough... (Score:4, Insightful)
And this is the reason that SSL certs (in whatever form they continue to exist) should be part of your DNS record, and that we should have a mandatory transition to DNSSEC over the next few years to ensure that those records cannot be tampered with during transit.
By doing that, the only way to pull one of these stunts would be to take over the domain at the registrar, at which point it would then matter which provider you chose, and the race to the bottom would become a race to the top (or at least to the median).
Re: (Score:1)
That's a bad idea.
Moxie Marlinspike, like so many others before him, explains why:
http://www.youtube.com/watch?v=Z7Wl2FW2TcA&feature=player_detailpage#t=1769s [youtube.com]
Re:If you ask nicely enough... (Score:5, Informative)
...unless you submit yourself to an INDEPENDENT audit you will be revoked from our default trusted root certs
In the case of Diginotar, Price Waterhouse Coopers was doing the audits.
Re: (Score:3)
PWC were (are) the auditors for AIG and Bank of Ireland.
Re: (Score:1)
Re: (Score:3)
PWC from my experience don't do real audits. They're more like an insurance company. They may send out a drone that knows nothing about what he's supposed to be checking but the gross of the money you pay them probably goes to a fund in case you have a breach and sue PWC.
I think that may be true of a lot of other audit companies. There are few audit companies that actually do penetration testing etc.
Re: (Score:2)
Lol. So true. A mate of mine worked for them. He had an accounting background on top of a CS degree. One week he would be providing consultant advice on naval ship building, the next week on running a national train system - despite having zero experience in either of these activities. To put it simply, the powers that be, needed consultants, and PWC kindly stepped in and took plenty of their money!
Re: (Score:2)
In the case of Diginotar, Price Waterhouse Coopers was doing the audits.
OK, so an independent audit by an auditor who hasn't been banned from the list of reliable auditors like PWC.
Is Mozilla really serious about trust or not?
Water still wet (Score:2)
A big, fancy, expensive firm that actually didn't do their job. What a shock.
Re: (Score:2)
DigiNotar is not exactly an example of race to the bottom on price... more like a monopoly jacking up prices.
Re: (Score:2)
The problem here is you need an outside audit which they won't agree to as it might introduce liability. An independent audit doesn't mean anything (I used to be an auditor) as the audit firm wants repeat business.
Re: (Score:2)
Easy. Microsoft, Mozilla, Apple, Opera pay auditors to audio every CA on their list. Auditors report to this consortium with yea or nay. If it's nay, vendors don't include CA on list of approved root CAs.
CAs that don't agree to independent audio - certificate not included.
CAs that fail - certifica
Re: (Score:2)
So we add Google to the list...
One of the problems I see is that some of these folks have large varied reliance on these CA's (Microsoft, Apple, Google) while the others (Mozilla, Opera) only do browsers. It is far more difficult for Microsoft, Google, and Apple to start denying CA's for not "cooperating" because it directly effects their users (of their OS's) in difficult to swallow ways (software, drivers, and other
Re: (Score:2)
The trouble is if you start having the browser vendors adding and removing CAs all the time, you screw things up for the certificate purchaser. My site gets screwed because my CA fails and audit and the browser vendor consortium drops the root certificate for my CA. That kinda sucks.
Re: (Score:3)
Indeed, it does suck.
Nevertheless, if the CA fails an audit, they *should* be removed (perhaps after a reasonable time to resolve the problem and get re-audited, if the problem is not too serious).
Re: (Score:2)
That is a case of caveat emptor. The prospective purchaser of a certificate could use the 'quality' of the audit as one of the criteria used to choose the vendor.
Re: (Score:2)
Easy. Microsoft, Mozilla, Apple, Opera pay auditors to audio every CA on their list.
Yeah indeed. I'm all for it. Indeed the current list of approved CAs is way too long!
Re:If you ask nicely enough... (Score:5, Insightful)
The recent "Too big to fail" CA == Bank comparision story was all too succinct a comparision, and this method won't work for the same reason an independent audit of the banks won't work. In short, most if not all CAs are likely security bankrupt.
Investigation is likely to find that CAs are only one step above flight by night organisations, with slipshod practices, procedures and security at every possible level, from the main servers to the secretaries email inbox. Are you ready to deal with the fallout from such revelations?
Are you ready to actually revoke security authentication from millions of sites across the internet? Are you ready to deal with every major browser throwing a blue screaming fit every time a user connects to a major web commerce login? Are you ready and able unclog a seized up system, signed up to by every major player on the internet, and which a substantial portion of the modern net itself now rests on?
The major problem here is the browsers, and Mozilla's actions here--requesting the CAs to police themselves--are exactly analogous to how our international banking system was woefully mismanaged over the last decades. What Mozilla should be doing is moving away from reliance on the Certification Authority system altogether. It has failed. It has become dangerous to users and website. It must be replaced or abandoned.
Removing the DEFCON 2 warnings for self signed certs will be the first step in the right direction. Until then, Mozilla is just continuing to be part of the problem.
Re: (Score:1)
Moving away from the CA system as it exists? Absolutely!
Moving away from the CA system entirely? Possibly, but not necessarily.
There's 4 problems with the CA system:
Re: (Score:1)
SSL is not about encryption. It is also about trust.
Re: (Score:1)
SSL is not about encryption. It is also about trust.
Please tell us how it is a better idea to trust an unsigned site at the other end of an unencrypted connection MORE than a self-signed site at the end of a SSL connection. If sites with self-signed certs trigger a warning on browsers, then every site served in the clear should as well. A good compromise would be not to display the lock icon for sites with self-signed certs.
Re: (Score:3)
Re: (Score:1)
Investigation is likely to find that CAs are only one step above flight by night organisations, with slipshod practices, procedures and security at every possible level, from the main servers to the secretaries email inbox. Are you ready to deal with the fallout from such revelations?
Yes. I am.
http://tech.slashdot.org/story/11/09/08/1454221/Moxie-Marlinspikes-Solution-To-the-SSL-CA-Problem [slashdot.org]
Re: (Score:2)
SSL has been destroyed, not because of protocol problems but because of the companies running the show.
It's the authentication part of the whole scheme that's the issue. Don't conflate SSL with the CA system; they are parts used together in a complete scheme. "SSL" would continue to work if we switched the authentication component to another method like distributed views (notaries).
Re: (Score:2)
"SSL" would continue to work if we switched the authentication component to another method like distributed views (notaries).
Correct. But it would stop to work (securely) if we switched off the authentication component altogether (as in "just use self-signed certs" without planning for any other means of authenticating them)
Re: (Score:2)
I agree with the accommodating interpretation given to dremspider's comment [slashdot.org], that the SSL we're focused on, web SSL, is practically destroyed by the failure of the CA system.
However, I'm trying to be a little more discerning by pointing out that SSL is one component in security schemes, distinct from the scheme itself, whichever one we're talking about. In web, the security scheme fails if the CA system fails. SSL can still be successfully used in other schemes, as in email, SIP, and VPNs.
Maybe we should
This is fine, but solves nothing (Score:2)
Re: (Score:2)
The problem with Convergence is, how does the average user know which notaries to trust? They have no way of establishing who is trustworthy and who isn't, which means that in all likelihood they'll end up with a "default" set of notaries. At that point, you're only marginally better off than you are right now with the CAs, in that several notaries would have to be compromised in order to "fool" everyone instead of just the one.
Re: (Score:2)
The fact that you can kick off some CA without breaking half of the internet is already much better than now. With convergence/perspectives websites aren't tied to single CAs like they are right now, so you get what they call "trust agility."
Regardless of who manages the notaries list, it's a big plus.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
For a mitm attack to succeed with Convergence, two notaries would have to collude.
No, it would be enough if a MITM can insert itself into the path from those two notaries to the target web server, and feed both notaries the same fake cert. No funny business by the notaries themselves is required.
===> so we better need the agreement of much more than just 2 notaries...
Even with a protocol needing all notaries to agree, a web server could be MITM'ed by its own ISP if it is single-homed (because paths from all notaries and visitors would go through that ISP). In order to prevent this,
Convergence could copy Adblock Plus's list model (Score:2)
Average users could simply subscribe to a list of notaries like most users do with the filter lists for Adblock Plus or IE9's Tracking Protection lists. Someone trustworthy who cares maintains the "EasyTrust" list that most users will subscribe to, and the community of knowledgeable geeks keeps an eye on that and cries foul if it gets taken over by a Sith lord or something.
But hell, even if the default list is maintained by the browser vendor, it's still way better than and more agile in response to proble
Re: (Score:2)
The problem with Convergence is, how does the average user know which notaries to trust?
How does the average user know which CA to trust?
in that several notaries would have to be compromised in order to "fool" everyone instead of just the one.
You can set the notary algorithm to be very aggressive. As in all (rather than just most) notaries need to agree before a site is deemed secure. The rogue notary will become very obvious (because it stops everybody going to any SSL website), and will be promptly removed from the browsers' lists of trusted notaries.
Two factor, three factor (Score:5, Insightful)
Who can trust a CA? Why would you trust a CA? How did a CA earn your trust?
Mozilla, it's time to own up. This is a bunch of nonsense. Stop treating self signed certificates like cancer, provide a way to see the fingerprint clearly, don't bother with the 'lock' icon and start working on some real innovation - how to do trust by having distributed lists of fingerprints, signatures, whatever. Something that doesn't rely on a signing authority at all.
You want to do real innovation instead of looking at hiding address bar from the users [pcworld.com]? Do this instead.
Re: (Score:1)
Re: (Score:2)
It"s actually a quite delicate matter that will take a long time to be resolved.
Therefore its only responsible to incite CA's to quintuple check their security measures. Web's SSL won't change overnight because some guy at Mozilla would code a super awesome alternative (although we'd still all wish that).
IMO the best option would be to have something that does away with the "must pay premium to have a cert that browsers trust".
Meanwhile, DNSSEC helps as well.
Re: (Score:2, Interesting)
Man, you are a broken record. We already talked about this a few days ago, but you are stubborn. I talked nicely then, but you really should leave security to people who have a clue. My karma can take the flak, so I'll be caustic.
Who can trust a CA? Why would you trust a CA? How did a CA earn your trust?
You trust CAs because the server you are talking with, by itself, can't confirm nor deny it is who it says it is: you need a third party and you said it yourself a few lines below. You trust those CAs because it's an audit-only club, and the friggin' web browser's company checked i
Re: (Score:3)
Because the organisation should be expected to have offices in every single city of every single region of every single country on the planet. And on top of that, the customer has to keep track of a post-it note or something storing these fingerprints. Screw that. Face it, it's a bad idea.
You know what would really happen? A market opportunity would open and we'd have companies start up which store and list all the fingerprints of big organisations who pay them money. Let's call them "Certificate Autho
Re: (Score:2)
You trust those CAs because it's an audit-only club, and the friggin' web browser's company checked it
Actually, only newcomers to those lists get audited (such as Cacert.org). Older CAs (such as Comodo et al.) are considered "too big to fail" and are grandfathered in. And so are CAs trusted by competing browsers because "we can't start throwing up scary warnings on sites which do not cause a problem to our competitors.
Let's suppose they even give me a fingerprint or signature or whatever... That means squat: a certificate from an impostor also has a fingerprint. With what/whom do I check it, then?
Checking the fingerprint is the entire point. But you're right: the general populace, including helpdesks at banks and elsewhere is just so clueless that they aren't even able to read you a 40
Re: (Score:1)
In other news AIDS does not exists, USA is most peaceful country in the world and there are no American tanks in Bagdad.
Self signed certificates are cancer. Your fingerprinting ideas won't work cause they abolish automatic verification of trustfulness, disable warnings on possible insecure situation, decentralize site verification and make verification laborious process.
You have to identify yourself to some authorities trusted by your browser. Stop brag
Re: (Score:2)
Stop treating self signed certificates like cancer, provide a way to see the fingerprint clearly,
Good luck making use of that. Ever tried to call the helpdesk of a server to verify its fingerprint? I'm pretty sure my bank would need to escalate such a request all the way up to the CEO, and still not be able to confirm the fingerprint...
Perhaps this will be the first positive change (Score:5, Insightful)
This may be the first REAL change in the CAs' assessments of the risk versus reward of building and maintaining good layered security systems. Until this week, the idea of a breach leading to delisting and the demise of the organization was an abstract idea. Now it is concrete, which makes all the difference (even though it shouldn't).
Perhaps some mid-level geek will finally, successfully make his case that the issuance process should be airgapped (or other similarly expensive measures).
Unfortunately, we haven't yet seen a change in the economics of issuing a certificate without proper vetting of the requestor. Right now it costs the CA almost nothing to issue a single certificate to somebody who isn't actually who they say they are. And vetting is a real-world activity involving meat and paper, so the MBAs in charge will never put money behind real vetting... until the economics change, anyway.
Re:Mozilla can't be trusted either (Score:4, Informative)
I was going to reply point by point to your complaints, but then I realized:
A) youre an AC, and probably trolling, and know that if you posted under your real handle your karma would tank because..
B) most of your complaints are garbage because...
C) they have all been addressed before in about a zillion threads, and
D) your entire post is off topic anyways.
Security theater - brought to you by the CAs. (Score:5, Informative)
It really is security theater now. I've had to get certs from various vendors for the .edu I work at. They need 'official' documents from 'someone important'. Like a letter on official looking letter head with a copy of a photo ID faxed to them. Yeah. Real secure. Lemme break out my copy of photoshop.
How about at the very least the verifications some sites use to show that you control a domain? For example, the CA says that in order to verify 'somesystem.somewhere.com' we're going to need you to put this arbitrary string in a TXT record on your DNS server for that host.
When setting up a domain on Google Apps or MS Live (or other places) they ask you to do this as one of the things to do to prove domain ownership. Yes - obviously if your DNS is owned this isn't a problem, but its a heck of a lot better than the process now.
Domain control certs already exist (Score:2)
At least with the issuing methods with more human involvement there is more possibility (not guaranteed of course) of a process involving a physical air gap between the key issuing machines an
mostly irrelevant (Score:2)
It mostly doesn't matter. First, the current failed CAs were audited and still failed. More to the point, the whole system is failure by design. Any CA can issue any cert for anything and there's not even a designed way to see that it's a dup.
Second, no matter how good a CA's practices are and how thorough the audit, if their government comes in with a goon squad and says "issue this cert NOW", they will.
Manditory Controls and Audits for CAs (Score:2)
Re: (Score:2)
slashdot untrusted (Score:1)