Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Four CAs Have Been Compromised Since June

Soulskill posted more than 2 years ago | from the four-whole-californias-wow dept.

The Internet 87

Trailrunner7 writes "The EFF, through the use of its SSL Observatory, has taken a look at the data from certificate revocation lists for SSL certificates in recent months, and found that there were four separate CAs compromised in the last four months. The only widely known CA compromise since June is the attack on DigiNotar this summer that completely compromised that company's CA infrastructure and eventually led to it being shut down. All of the major browser vendors were forced to revoke their trust in the DigiNotar root certificates and the attacker who claimed credit for the attack said that he also had compromised several other CAs. There are apparently three other CAs that have discovered compromises since June, but have not made them public."

cancel ×

87 comments

Sorry! There are no comments related to the filter you selected.

Hmm. (1)

Anonymous Coward | more than 2 years ago | (#37873150)

There are apparently three other CAs that have discovered compromises since June, but have not made them public.

That certainly strengthens my trust in the SSL certificate system.

Re:Hmm. (1)

MatthiasF (1853064) | more than 2 years ago | (#37873250)

System is broken. De-centralize website security NOW!

obligatory references (2)

Onymous Coward (97719) | more than 2 years ago | (#37873460)

Another CA system is broken article?

Consider an alternative model based on notaries:

Other resources of note: Moxie Marlinspike's article on "trust agility" [thoughtcrime.org] , his Black Hat Conference talk on this topic [youtube.com] .

Yes, but the reputation problem hasn't been solved (2)

Colin Smith (2679) | more than 2 years ago | (#37873724)

I actually agree. Same with DNS.

However, there is a problem with reputation. How do you know that the name, or cert you have from someone is actually from the real person and not counterfeit?

We've tried central authorities. You have all seen the results. It mostly works, as long as you trust the central authority. How do you make a completely distributed system work? It requires some sort of reputation about people and companies you have never been in contact with.

Note, we haven't solved this problem in real life either.
We have brands, certifications, social networks, tests but we don't have a way to say that Xs reputation in terms of Y is Z when you don't know X.

Re:Yes, but the reputation problem hasn't been sol (1)

Anonymous Coward | more than 2 years ago | (#37874562)

I actually agree. Same with DNS.

However, there is a problem with reputation. How do you know that the name, or cert you have from someone is actually from the real person and not counterfeit?

Decentralize it! Open it! Fixes everything!

We've tried central authorities. You have all seen the results. It mostly works, as long as you trust the central authority. How do you make a completely distributed system work? It requires some sort of reputation about people and companies you have never been in contact with.

You don't MAKE it do anything! What part of "decentralize it" don't you understand? It's magical! Wave a magic decentralize wand around and crowdsourcing will solve everything! They're all reliable! There's no risk of some anonymous trolls coming by to piss everyone off and spoil the trust of the system!

Re:Yes, but the reputation problem hasn't been sol (1)

DavidTC (10147) | more than 2 years ago | (#37879140)

Uh, there is a trivial way to decentralize SSL now that we've got signed DNSSEC working. Simply put the SSL fingerprint (Or even the entire public key) in a DNS record, which is then, along with the rest of the DNS records, signed by the DNS server.

Look, it is magic, and just as secure as before. (Because, frankly, if you have access enough to their DNS registrar to alter records, you can secretly point their mail at you long enough to grab a signed SSL key.)

This puts 'I can prove I own this domain name' back into the system that actually exists to keep track of who owns what name, DNS. What a strange and odd idea.

Oh, and as an added bonus, it lets people who have purchased domain names from others remove all previously authorized SSL keys, which there is currently no way to do. (Unless you can somehow telepathically deduce every single cert they might have issued and make them revoke them.)

Likewise, it allows for actual working certificate revocation, which right now works in theory but is utterly broken.

Re:Yes, but the reputation problem hasn't been sol (1)

Snorbert Xangox (10583) | more than 2 years ago | (#37883480)

Parent post hits nail squarely on head. Just because Random Hopeless CA X is still in a browser's trusted root CA list, should not mean that they can issue certs against my domain that anyone should trust. Placing signed cert public key fingerprints (or even the public key fingerprint of the root CA that actually issues your cert, if you really trust that CA) would make it much harder for an attacker to compromise a well-run, high-value web site (such as gmail.com or a banking web site).

Google did this unilaterally in their own browser, by only trusting the small set of CAs that Google uses when accessing its own web sites. Neat, but not at all scalable, even if Google were motivated to extend that feature to high-value web sites run by other companies.

Grid computing had a similar idea - if you wanted to get your CA's certificate into the bundle of trusted CAs distributed with common Grid software bundles like Globus or VDT, your CA had to have a "signing authority" that limited what certificate subjects it could sign for, which was part of the CA certificate. This meant that even if I compromised Random Trusted Grid CA X, I could not issue a cert that claimed I was from, say, Fermilab, because that cert would not match against the signing authority for that other Grid CA. Commercial CAs would never agree to similar provisions, because that would restrict who they could sell certs to, but the parent post's idea devolves that signing authority down to the people who actually pay for the certificate, which is naturally where that authority should reside.

Best of all, to implement this scheme, you just need to create an appropriate DNS record, add the check to your preferred open source web browser, and start selling the idea to the browser users and web site operators. With luck, the public support for the idea gets it adopted by web site operators (it costs them almost nothing), CAs have nothing to object to because they can still sell certs to whoever they were already selling certs to, and browser users put pressure on the developers to support the scheme. You don't have to persuade everyone to swallow a barrel of crypto-anarchist-libertarian "decentralise everything, storm the Winter Palace, power to the people, right on!" Kool-Aid and destroy the existing PKI CA architecture in order to save it.

Remember, politics is the art of the possible.

Re:Yes, but the reputation problem hasn't been sol (1)

DavidTC (10147) | more than 2 years ago | (#37890358)

I find the way it works now completely absurd.

It's like if someone wanted to be able to prove they owned a car, they had to print up a piece of paper that said they owned it, and then go to a random 'Car Authorities' and have them stamp it.. The CA would then call up the DNS, I mean the DMV, ask for that car owner's mailing address, and mail the paper to them.

Occasionally, someone forges a stamp, or slips an extra stamp into the 'list of acceptable stamps' that people check again, or sneaks into a CA at night and use their stamp, or exploits a security issue at the DMV's address checking, or steal the mail, or a government takes over the CA, etc, etc. And everyone gasps in horror, because no one has actually looked at the system and said 'Hey, wait, if the DMV knows who owns what cars, why the fuck aren't they stamping those pieces of paper?'

It is, frankly, a little astonishing how utterly stupid and nonsensical the entire idea of SSL signing as a business is. I'm sorry, when it was being invented, someone should have looked around and said 'Wait, what are we trying to do again? We already have a system for the actual domain owner to be looked up...it's called DNS. It already exists. Granted it's insecure, but wouldn't it make more sense to come up with a secure way of getting the cert info to people, instead of all this other nonsense?'

If people still want to operate signing agencies to confirm who the owner of the domain is, whatever. Although such a thing does not, and has never, required SSL at all. (Although obviously SSL is required to assure that you're talking to whoever the owner is.) It just requires a database somewhere. And I'm not sure letting random third parties put such things in that database makes sense.

It might make more sense to have, for example, a 'United States Bank' database that the Federal Reserve Board runs or something, keeping track of a domain name for every banks, which it gives out to browser manufacturers. And customers could be taught that their bank should say 'BANK' next to the URL.

The way it is now is utter nonsense. We have a system that's piss-poor at verifying that you are talking to the legit owner of a domain (Because the security of the system depends on utterly random third parties.) and has been extended to cover who the owner is, which it isn't very good at either.

Re:Yes, but the reputation problem hasn't been sol (4, Insightful)

jd (1658) | more than 2 years ago | (#37875186)

This is something that has deteriorated over time. I won't say the original cert system was perfect (there were flaws you could drive a 40 tonne truck through) but Grade I certification required significant documentation proving identity plus some form of actual (ie: non-written) contact. That was not a bad idea, the problem was they also offered Grade III certification (a note saying "it woz me" on a napkin) or even grade IV (the request sufficed as proof it woz you) and corporations naturally gravitated towards the cheaper options which you can fly an Airbus 400 through with enough space for 40 tonne trucks on either side.

The problem was that you still had to trust the CA and this is a major frailty in the CA system. Being assured that the applicant is who they say they are is a major thing - Verisign issued hackers with a signed Microsoft key at one point, because they were asked to in a fax, and DNS registrars are notorious for complying with bogus transfer requests - but it isn't everything. If the CA is compromised, then you have major problems even if all the officially distributed keys are legit.

Obviously, a Grade I cert system helps to some extent as requiring a thorough screening of applications means you aren't doing live cert distribution which in turn means the master key need not be on any online computer whatsoever. If the master key is behind a sneakernetwall, then hackers will have a harder time signing anything with it. (A sneakernetwall differs from an airwall in the level of competence of those moving stuff from one machine to another.) Obviously, given that eCommerce security holes repeatedly demonstrate corporations can't even put sensitive data behind a meager firewall and the VA is forever losing unencrypted laptops, there's a big difference between "need not" and "is not".

A way to side-step the issue - to a degree only - would be to require that keys be counter-signed by at least one other CA. It is less likely that two CAs have been cracked by the same person, after all. Or, well, it would be if it weren't for the fact that it probably WAS the same person who broke into all four CAs and there's been an alleged confession that the person did break into two. That person would have been able to counter-sign a key with another CA's master key and since these were the cheapo kind of CAs that probably would indeed keep the master key on an online computer even if they needn't or legally shouldn't, a "Web of CA Trust" is not enough to be 0.45 bullet-proof but is probably 0.22 bullet-proof. The current system apparently falls over if you show it a picture of a bullet.

IPv6 may help, since violations of strict hierarchical addressing are not only commonplace in IPv4 but actually a necessity due to the limitations of the addressing scheme. In IPv6, routing relies heavily on sub-domains having IP addresses with a prefix equal to the prefix of the domain plus two byte identifier unique within that domain. This means you can identify where things are. Yes, there are privacy issues for personal machines and that's been a major complaint against IPv6, but it means that you've a lot more confidence that a server is in roughly the right place. If you then add DNSSEC or any of the other DNS locking schemes out there, OR mandate an IPSec mode using certificates in a way that would offer equal guarantees that the server is who it says it is, it would help but you're starting to get into the diminishing returns then.

Of course, this might be the wrong approach entirely. This is trying to find a technical solution to what is ultimately a social problem. Social solutions are usually far better for such things. One social solution would be to regulate cross-border traffic such that eCommerce vendors (CAs included) that wish to conduct cross-border traffic (whether into the country or between boundaries within it) have to publicly declare all actual security breaches and may be held 100% liable for any loss due to unreported breaches. That's definitely not going to sit well with those against regulations, and as it would have to be an international effort on an unprecedented scale (the EU's privacy directives would pale in comparison, for example, and the US openly ignores those anyway) it would never happen in practice.

Nonetheless, no amount of encryption can fix a flawed ideology and the ideology here that is broken is the one that says security is for wimps and nerds.

Re:Yes, but the reputation problem hasn't been sol (1)

countertrolling (1585477) | more than 2 years ago | (#37876872)

One social solution would be to regulate cross-border traffic such that eCommerce vendors (CAs included) that wish to conduct cross-border traffic (whether into the country or between boundaries within it)...

A much better social solution would be to tear down the borders. They're only there to perpetuate the slave trade anyway. Making them more restrictive is exactly the opposite of what is needed.

Re:Yes, but the reputation problem hasn't been sol (1)

jd (1658) | more than 2 years ago | (#37877086)

Ah yes. I can just see the US assigning full sovereign authority to the UN, which is what tearing down all the borders would ultimately imply. One world government, a new world order and all that. Half the country would be in flames and the other half would claim it should be entitled to be.

I don't dispute that borders are a problem, I certainly don't dispute that insular pockets take themselves far too seriously, but that's never going to work as a solution. Even if you didn't take it to the logical limits (Europe eliminated certain borders but not others, causing as many problems as it prevented), you're going to have all kinds of groups screaming blue murder over whatever borders you scrap claiming that you're usurping their rights and other groups whose borders aren't scrapped screaming blue murder claiming that they're being constrained unfairly. The only thing that's certain is that nobody will like it.

Getting back to the issue of SSL, border controls would be the only way that you could impose any kind of enforceable standards. In a global economy, the company doesn't need to care where its HQ is so it can always pick the area with the standards that make it the most money. The only way to circumvent offshoring is to say that companies that want to do business in your area have to meet your minimum standards no matter where they are. However, jurisdiction limits how you can do this.

So what happens if you have a voluntary system? Well, you get the current mess and no reporting of compromised root keys, which is definitely worse than what we have right now. (It's easy to say you have choice, but you can't exactly choose to buy books at Borders any more, Paypal is still about the only generic solution to eCommerce payments and I don't see a whole lot of book retailers that offer their own Kindle or Nook versions of their merchandise. In short, lock-in has become the norm and whilst it's the norm "choice" is nothing more than a prettily-painted illusion.)

But won't people steer clear of defective stuff? Well, Citibank didn't declare bankruptcy after it was revealed that you only needed to log into your own account in order to be able to have total access to absolutely everybody else's. Veterans still sign up to the VA, despite those laptop losses. Windows still exists, despite the notoriously fragile security. So, no. People knowingly buy lemons because defects only happen to other people.

The free market? Only works if you assume rational customers. See point above. Customers aren't rational. I'm not even sure I'd rate them as highly as irrational. The free market is correct as a starting point, but you need to add something to ensure integrity as nobody else is going to.

Workaround (partial) (2)

Mathinker (909784) | more than 2 years ago | (#37873254)

For the paranoid/cautious: there exist extensions to FF which monitor suspicious changes to certificates (i.e., possible MITM attacks). I use Certificate Patrol [psyced.org] .

Make Public = Out of Business? (3, Interesting)

SydShamino (547793) | more than 2 years ago | (#37873238)

Short of the companies wanting to the good/legal thing, how do you get them to make it public if it quickly puts them out of business? This is the same problem as with any security breach, except aggravated because the CAs basically have just five "customers" (the five major browsers), all of which compete in the realm of being the "safest" and so all five have to pull the root certificate for anyone who announces a problem.

Re:Make Public = Out of Business? (4, Insightful)

Eponymous Coward (6097) | more than 2 years ago | (#37873430)

Almost every decision Diginotar made around the breach, was a bad one. Other CA's have had breaches and made responsible disclosures and they are still around. That doesn't mean there are zero consequences (nor should there be), but responsible behavior goes a long way in convincing their 5 customers that they are still worth trusting.

Re:Make Public = Out of Business? (0)

Anonymous Coward | more than 2 years ago | (#37873482)

I think it's more likely that other CA's were used by far more websites and couldn't be as easily replaced.

Re:Make Public = Out of Business? (1)

hairyfeet (841228) | more than 2 years ago | (#37877644)

Exactly! Mistakes get made folks, nobody is perfect, but the way to tell a good company from a bad company is how they react when the poo hits the fan which is why I still use Comodo products even though they did have a breach last year. Once they found out they had a compromise they were updating Comodo Dragon browser to revoke those keys as well as sending updates to the other browser teams, they even got MSFT to release an out of cycle patch for windows that revoked those keys.

So it all comes down to how they react when a breach has been found, do they do everything they can to fix the problem ASAP, or do they try to cover it up and bury it? If they do everything they can to fix the problem and repair the weakness that caused the breach I'd say they are still a trustworthy company, if they try to hide their mistakes then some sort of punishment should be looked into. But until we can find some sort of replacement system (which I haven't seen any proposed yet that would be completely workable or not put the net at risk of greater government control) all we can do is see how companies react to breaches and decide whether or not to trust them based on those reactions.

Re:Make Public = Out of Business? (1)

Anonymous Coward | more than 2 years ago | (#37873434)

DigiNotar didn't make anything public. They tried to hide it, and that's what killed them. In fact, DigiNotar claimed nothing was wrong even on the day the Dutch government pulled their privilege to generate certificates to communicate with various government offices. I have witnessed this first hand because I work for a company that relied on DigiNotar's certificates (not by our choice).

Re:Make Public = Out of Business? (2)

shentino (1139071) | more than 2 years ago | (#37874560)

And that's what killed them.

The big bad government had to step in.

Business will ALWAYS misbehave unless it is watched.

Made you look. (0)

Anonymous Coward | more than 2 years ago | (#37874734)

You're saying regulations are necessary?! That's not possible!

Re:Make Public = Out of Business? (1)

msauve (701917) | more than 2 years ago | (#37873436)

Much of the reason Diginotar is out of business is precisely because they weren't timely, upfront and open about the issue. They delayed any notification until after it was known by other means. They understated the extent of the issue, and AFAIK, never did admit to the full scale of the compromise. Quite simply, their own actions showed they could not be trusted.

That's why other CAs should have learned from that event, and should quickly be public and open about any compromises they may discover.

According to the article:

The data that the EFF looked at was a summary of the reasons that specific certificates were revoked by CAs, as reported by the CAs themselves in CRLs. When a certificate is revoked, the CA specifies a reason for the action, and the EFF looked through the data collected in its SSL Observatory database and found that a scan of CRLs in June showed that 10 individual CAs reported that they were revoking 55 total certificates because of a CA compromise.

I'm not knowledgeable about exactly how such revocations are marked, do they actually distinguish between the compromise of a certificate due to customer error and a cert revoked due to a compromise of the CA's infrastructure? A certificate being revoked due to a "compromise," may not actually reflect poorly on the CA - a customer could have let the private key escape, notified the CA of the compromise, and the CA simply responded as it should.

Re:Make Public = Out of Business? (1)

St.Creed (853824) | more than 2 years ago | (#37875062)

Much of the reason Diginotar is out of business is precisely because they weren't timely, upfront and open about the issue. They delayed any notification until after it was known by other means. They understated the extent of the issue, and AFAIK, never did admit to the full scale of the compromise. Quite simply, their own actions showed they could not be trusted.

That's why other CAs should have learned from that event, and should quickly be public and open about any compromises they may discover.

Also, the resulting investigation uncovered a gigantic mess. They built a castle, locked the gates, had it certified, then made huge holes in the walls because the gates were delaying the traffic... they didn't understand security at all and that was the final straw, IMO.

Re:Make Public = Out of Business? (0)

Anonymous Coward | more than 2 years ago | (#37873472)

The one CA which is out of business now is the one which tried to keep the breach under wraps. Everybody else is still in the trusted CA lists.

Browser makers can't just pull CAs, because that would not only inconvenience their users but also put them at risk: Users would have no way of securely communicating with important web sites (other than doing things that no non-crypto-expert understands). If CAs handle breaches reasonably well and show signs of learning from their mistakes, they are in no danger of being shunned.

Re:Make Public = Out of Business? (3, Insightful)

sjames (1099) | more than 2 years ago | (#37875382)

Is Comodo out of business? They are not, because they disclosed their compromise responsibly and took the necessary steps to correct their failure.

Diginotar swept it under the rug for as long as they could, and in the end said themselves that their audit trails were so poor there was no choice but to remove their root cert.

Re:Make Public = Out of Business? (2)

Opportunist (166417) | more than 2 years ago | (#37877246)

Making it public doesn't put you out of business. Watch the recent events in the certificate blunders and you'll notice that CAs who went public had worries, but could rather easily recover. Issuing new certs is fairly easy.

DigiNotar went under exactly for NOT going public and having any trace of trust eroded due to it.

Useless (3, Insightful)

OverlordQ (264228) | more than 2 years ago | (#37873258)

This post is useless without naming them

Re:Useless (2)

elsurexiste (1758620) | more than 2 years ago | (#37873304)

At least it's useful for us to know that SSL has serious issues....

Re:Useless (0)

Anonymous Coward | more than 2 years ago | (#37873364)

At least it's useful for us to know that SSL has serious issues....

I'm pretty sure the majority of people on this website knew that already.

Re:Useless (1)

Riceballsan (816702) | more than 2 years ago | (#37873418)

wow... next thing you know we're going to learn security by obscurity is not 100% effective, facebook and google may lead to concerns for privacy, and some virus's might not be detected by norton antivirus... Shocking.

Re:Useless (4, Insightful)

Fished (574624) | more than 2 years ago | (#37873464)

The data for the study came from x.509 certificate revocations. Do you really want to punish the CAs that did the right thing and filled out the certificate revocation correctly? That will just encourage fraud.

Re:Useless (1)

jpiratefish (1690054) | more than 2 years ago | (#37873990)

Agreed. Kind of like Fox News...

Only one way, if you're serious about it: (1)

Anonymous Coward | more than 2 years ago | (#37874006)

Delete ALL certificates in your browsers.
Then only add them, if you PERSONALLY trust them because you have checked them. Or at least have a more trustworthy third party that trusts them than "$browserMaker.randomResponsiblePerson".

The concept is rotten at its core, as there is no such thing as a global "authority". It's the opposite of natural human webs of trust.

Re:Useless (1)

MichaelKristopeit352 (1968160) | more than 2 years ago | (#37874244)

this entire website chatroom message board is useless.

slashdot = stagnated

Re:Useless (1)

Vellmont (569020) | more than 2 years ago | (#37874452)


This post is useless without naming them

I'd say the exact opposite is true. It's FAR more useful to NOT name the CAs. Why? It points out that the CA system is entirely broken. If the CAs had been named, the compulsion would be to simply point at the 4 "bad guys", hope they go out of business, and everything is back to "business as usual". Then wait for the next group of CAs to get own3d. Rinse, repeat. In short, it doesn't matter which 4 were hacked, because the problem isn't bad apples, the problem is the trust system itself.

The entire world can't rely on a security system where the weakest link makes everyone in the world vulnerable to MITM attacks. If the CA system depends on any one entity being perfectly secure, or perfectly trustable, then the game is over. That will never be the case.

Re:Useless (1)

jd (1658) | more than 2 years ago | (#37875288)

You are entirely correct - rot is never confined to the "bad apples" that you spot - and the spreadsheet only shows the "bad apples" that actually sent messages saying that they were bad. It says nothing about CAs who simply revoked individual certificates that they know were unauthorized when it was a master key that was compromised. And you know that's bound to have happened. The disparity between bogus certs and compromised CAs was too great. Even there, you know that not all bogus certs get revoked, so even those numbers (which are way too large) are underestimates. That means that name-and-shame will simply create false confidence in unknowing victims and will create a greater atmosphere of concealment amongst CAs.

(Every instance of name-and-shame that we know of has produced that result. Except for such programs involving red light districts, where it's been used as free advertising by the streetwalkers.)

It'd be nice to have a wiki for secret info (1)

witherstaff (713820) | more than 2 years ago | (#37874776)

We need some sort of wiki for exposing flaws and hidden information that should be public. It'd be handy to see what secrets governments held. Also banking institutes. And it should be run in such a way that it doesn't make a rock star of the person running it while only actually leaking a few things. Maybe someone should get around to that someday...

Seriously, fuckedcompany had more corporate leaks than wikileaks ever has. Too bad pud sold out (Can't blame him for making money but it's a shame it's gone)

Re:Useless (0)

Anonymous Coward | more than 2 years ago | (#37877108)

Would the recent Debian update for CAs help?


ca-certificates (20111025) unstable; urgency=low

    * Update mozilla/certdata.txt to latest (NSS branch version 1.64.2.13)
        Certificates added (+) and removed (-):
        + "AffirmTrust Commercial"
        + "AffirmTrust Networking"
        + "AffirmTrust Premium"
        + "AffirmTrust Premium ECC"
        + "A-Trust-nQual-03"
        + "Bogus Global Trustee"
        + "Bogus GMail"
        + "Bogus Google"
        + "Bogus kuix.de"
        + "Bogus live.com"
        + "Bogus Mozilla Addons"
        + "Bogus Skype"
        + "Bogus Yahoo 1"
        + "Bogus Yahoo 2"
        + "Bogus Yahoo 3"
        + "Certinomis - Autorité Racine"
        + "Certum Trusted Network CA"
        + "Explicitly Distrust DigiNotar Cyber CA"
        + "Explicitly Distrust DigiNotar Cyber CA 2nd"
        + "Explicitly Distrust DigiNotar Root CA"
        + "Explicitly Distrust DigiNotar Services 1024 CA"
        + "Explicitly Distrusted DigiNotar PKIoverheid"
        + "Explicitly Distrusted DigiNotar PKIoverheid G2"
        + "Go Daddy Root Certificate Authority - G2"
        + "Root CA Generalitat Valenciana"
        + "Starfield Root Certificate Authority - G2"
        + "Starfield Services Root Certificate Authority - G2"
        + "TWCA Root Certification Authority"
        - "AOL Time Warner Root Certification Authority 1"
        - "AOL Time Warner Root Certification Authority 2"
        - "DigiNotar Root CA"
        - "Entrust.net Global Secure Personal CA"
        - "Entrust.net Global Secure Server CA"
        - "Entrust.net Secure Personal CA"
        - "IPS Chained CAs root"
        - "IPS CLASE1 root"
        - "IPS CLASE3 root"
        - "IPS CLASEA1 root"
        - "IPS CLASEA3 root"
        - "IPS Timestamping root"
        - "Thawte Personal Freemail CA"
        - "Thawte Time Stamping CA"
    * "Bogus *" CAs above address Comodo MITM 03/11 Closes: #619587
    * Update CAcert-Class 3-Subroot-certificate Closes: #630232

  -- Michael Shuler Sun, 23 Oct 2011 23:16:57 -0500

Insert naïve kneejerk response here... (0)

Anonymous Coward | more than 2 years ago | (#37873504)

If you've got nothing to hide why use encryption?

Who has nothing to hide? (1)

WD (96061) | more than 2 years ago | (#37875692)

You say this as if there is a significant number of people who fall into the category. Or as if it's a bad thing. Most people do have things to hide. Like a credit card number, for example.

Re:Insert naïve kneejerk response here... (1)

Opportunist (166417) | more than 2 years ago | (#37877280)

If you got nothing to hide, you're an idiot. And while I'll assume you're not entirely serious in this post, allow me to use it as a soapbox against the whole "got nothing to hide" crowd out there.

Everyone has "something to hide". And it doesn't even have anything to do with the internet. Actually, as soon as you remove "teh Intarnets" from the equation, people start to understand that they do. Who can sensibly say that they have never answered "none of your business" to any questions they have ever been asked? How many people get uncomfortable if they get asked trivial matters like age or weight? And neither is even something that you "should" sensibly hide from anyone, it's not like the knowledge of either has any tangible effect on you.

It's called privacy. And everyone's entitled to it. Actually, studies have shown that stripping someone of any semblance of privacy increases his stress level considerably. Being under constant surveillance is stressful. Ever had a police car drive behind you? You didn't do anything wrong, you're going the speed limit, you're driving safely, yet you feel uncomfortable because you feel like they're watching your every step and wait for a slip. Even though almost invariably they don't care in the least about you and are just happening to go the same way.

Hence the question is the wrong one to ask. Not "why encrypt if you have nothing to hide". Rather "why do you wanna stick your nose in my business if you don't expect me to be a crook". And if you DO ... well, only crooks think everyone's a crook...

1. reduce the number of CAs to a handful (0)

circletimessquare (444983) | more than 2 years ago | (#37873592)

2. those that remain, put them under very heavy regulation, that they fund

3. anyone who wants to open a new CA must jump through a ridiculous number of hoops

the CAs are just too important to leave to the "hey man, the market takes care of itself" stupidity

Re:1. reduce the number of CAs to a handful (2)

MobyDisk (75490) | more than 2 years ago | (#37873622)

I think we need to do the opposite - have thousands of CAs. What we have seen from this is that putting power in the hands of a small specially designated group is very risky. A public-key system can't rely on a hierarchy where a few organizations can bring down the entire web of trust.

Re:1. reduce the number of CAs to a handful (1)

medv4380 (1604309) | more than 2 years ago | (#37873680)

If even 1 of the thousand gets completely compromised and doesn't tell anyone you're in the same boat as having only a few organizations. The difference is the number of opportunities for it to occur. A better option would be to get rid of the system entirely but coming up with a viable replacement seems to be still in the air.

You don't seem to understand the problem (1)

WD (96061) | more than 2 years ago | (#37875726)

The CA architecture as it is used in web browsers is only as strong as its weakest link. It only takes one compromised CA to make the whole system worthless. Having thousands of CAs would make the problem significantly worse.

Re:You don't seem to understand the problem (1)

MobyDisk (75490) | more than 2 years ago | (#37898094)

If one CA is compromised, then you revoke the certificates generated by that authority and the rest of the system remains safe. The way it is now, each authority is so big they there is hesitation to revoke the certificates because so many sites then have invalid certificates.

Re:1. reduce the number of CAs to a handful (0)

Anonymous Coward | more than 2 years ago | (#37873658)

Yes, 'cause we all love a good monopoly in a market with extremely high barriers to entry.

Re:1. reduce the number of CAs to a handful (1)

TubeSteak (669689) | more than 2 years ago | (#37873720)

I don't have a problem with turning the CAs into a regulated utility....
BUT, for that to work it would have to be everywhere/everyone at once,
including internationally, and that never happens in the real world.

Re:1. reduce the number of CAs to a handful (1)

John Hasler (414242) | more than 2 years ago | (#37873854)

I don't have a problem with turning the CAs into a regulated utility....

Regulated by who?

Re:1. reduce the number of CAs to a handful (1)

shentino (1139071) | more than 2 years ago | (#37874632)

Especially when you have to deal with other nation-states that may well have a vested interest in playing nice just to get an opportunity to stab you in the back.

Re:1. reduce the number of CAs to a handful (0)

Anonymous Coward | more than 2 years ago | (#37873798)

Heavy regulation means only the companies that make the proper contributions (political) can do business legally

Of course by "they fund" you mean we pay higher prices for their services

Wait....hoops....I thought you wanted more regulation

Of course once the state "takes care of" it, then it just works....why, because they say so

And if not we can just vote with our dollars and reward a different state for its solution.....oh wait

Re:1. reduce the number of CAs to a handful (1)

shentino (1139071) | more than 2 years ago | (#37874644)

The problem with "voting with your dollars" is not getting OUT voted by organizations whose interests run counter to your own.

You can shout with every decibel of your wealth, but it does no good if the 800 pound gorilla can drown you out just by whispering briefcases full of cash.

Re:1. reduce the number of CAs to a handful (0)

Anonymous Coward | more than 2 years ago | (#37874542)

>the CAs are just too important to leave to the "hey man, the market takes care of itself" stupidity

Nonsense! The market will handle this quite nicely, as any Libertarian can explain. If you're one of the victims whose life-savings is stolen due to a compromised CA, you can just choose to manually remove the offending CA from all your own browsers. And when a few thousand people make this individual, free-will decision, the "invisible hand" will bring the force of the market on those CA's to become more competitive or go out of business.

See, the free market works every time.

Re:1. reduce the number of CAs to a handful (1)

Opportunist (166417) | more than 2 years ago | (#37877288)

Free market works in a world of level headed, sensible and perfect human beings. But then we could as well switch to communism, it would work too.

Re:1. reduce the number of CAs to a handful (1)

shentino (1139071) | more than 2 years ago | (#37874616)

The problem with the CA market is that the hierarchial nature stifles competition. The guy at the top of the chain has pretty much omnipotent power and is effectively an oligopolist or worse a monopoly. His ability to say to his inferiors "see that X is dropped or *I* will drop *you*" is a very large club that can and will be used, and even if it isn't, it being possible is enough of a threat that often those lower in the chain dare not even think of defying their will. So the market of CAs is really the market of root CAs, which is much smaller.

Re:1. reduce the number of CAs to a handful (1)

countertrolling (1585477) | more than 2 years ago | (#37876884)

...put them under very heavy regulation...

Yes, let's hand that over to the DHS

Re:1. reduce the number of CAs to a handful (1)

Opportunist (166417) | more than 2 years ago | (#37877290)

He said regulation, not circle-jerk security theater. We got enough of that in the CA business already.

Why aren't the compromised CA's known? (1)

hawguy (1600213) | more than 2 years ago | (#37873756)

There are apparently three other CAs that have discovered compromises since June, but have not made them public.

I don't know how CRL's work, but if you have a list of certs that were revoked, can't you tell who revoked them? Doesn't the revoking CA have to sign the revocation request? Or do the researchers know who they are, but they chose to not make them public?

Re:Why aren't the compromised CA's known? (0)

Anonymous Coward | more than 2 years ago | (#37874450)

You pretty much just have a Certificate Serial Number that has been revoked, with no other identifying information.

If you find the Certificate matching the CRL entry's Serial Number then you find the CA.

Re:Why aren't the compromised CA's known? (1)

hawguy (1600213) | more than 2 years ago | (#37874586)

You pretty much just have a Certificate Serial Number that has been revoked, with no other identifying information.

If you find the Certificate matching the CRL entry's Serial Number then you find the CA.

If the CRL is not signed, how do you know it came from the CA and not from a random hacker? Revoking CRL's from big name sites seems like it would be an attractive target. How is a CRL entry validated? How does a CRL make it to my browser?

The Wikipedia article just says that it's published by the CA and is "usually" signed, but doesn't tell how the makes its way to my browser.

http://en.wikipedia.org/wiki/Certificate_revocation_list#Publishing_Revocation_Lists [wikipedia.org]

A CRL is generated and published periodically, often at a defined interval. A CRL can also be published immediately after a certificate has been revoked. The CRL is always issued by the CA which issues the corresponding certificates. All CRLs have a lifetime during which they are valid; this timeframe is often 24 hours or less. During a CRL's validity period, it may be consulted by a PKI-enabled application to verify a certificate prior to use.
To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory.
The certificates for which a CRL should be maintained are often X.509/public key certificates, as this format is commonly used by PKI schemes.

Re:Why aren't the compromised CA's known? (0)

Anonymous Coward | more than 2 years ago | (#37877174)

> How does a CRL make it to my browser?

Your browser has the capability to download a published CRL ( manual task ) or to use OCSP to transparently query the CA's web service to determine the state of a particular cert.

Usually OCSP is disabled in the config because it (1) takes time and (2) can confuse the user if the cert has been revoked.

Try reading outside Wikipedia.

They're KNOWN, & 3/4 run LINUX, lol (0)

Anonymous Coward | about 2 years ago | (#37886656)

No wonder they went down (inferior Linux security) http://tech.slashdot.org/comments.pl?sid=2499020&cid=37879884 [slashdot.org]

Toss on yet another CA breached recently (0)

Anonymous Coward | more than 2 years ago | (#37957144)

I don't trust CAs (1)

nebular (76369) | more than 2 years ago | (#37874190)

This is why I don't trust Certificates I haven't generated myself. In fact my prof for one of my security classes (I'm in Computer Security and Investigations at Fleming College) actually told us that untrusted certificate situations are more trustworthy, as the majority of attackers will go about getting a certificate through fraudulent means to avoid the scary pop-up window.

Re:I don't trust CAs (1)

Opportunist (166417) | more than 2 years ago | (#37877296)

He is right. But only in rather specific circumstances, and only due to the problems CAs have.

There's nothing more trustworthy than an "untrusted" certificate if, and only if, truster and trustee have some kind of preexisting relationship. But only as long as this becomes "common knowledge" and everyone does it, because then suddenly it becomes very interesting for an attacker to issue "untrusted" certs, since it's heaps easier than forging one and he can use the reliance of people on those "untrusted" certs as the same vector for trust as he does not with forged "trusted" certs.

Self Signed Certificates (1)

roman_mir (125474) | more than 2 years ago | (#37874516)

Put them all out of business and lets work on the actual issues. Browsers should be fixed to treat self signed certificates like normal encrypted channels and not viruses and there is a need for a new form of distributed authentication procedure that doesn't depend on a signing authority.

Re:Self Signed Certificates (1)

Opportunist (166417) | more than 2 years ago | (#37877304)

If you want to fix the problem, start lower in the OSI layer. HTTP has never been designed as a secure protocol, and HTTPS is a crutch rather than a solution.

Re:Self Signed Certificates (1)

JohnnyBGod (1088549) | more than 2 years ago | (#37885116)

I disagree. A self-signed cert can only assure you no one is able to eavesdrop, not that you're talking to the right server. However, self-signed certs should be treated like any plain old HTTP connection, since they're more secure than those, even though browsers make them feel less secure than those.

Re:Self Signed Certificates (1)

roman_mir (125474) | more than 2 years ago | (#37885332)

Trust me, I had this discussion here often enough with the same faulty points are being regurgitated over and over.

http://it.slashdot.org/comments.pl?sid=1690388&cid=32611676 [slashdot.org]

http://it.slashdot.org/comments.pl?sid=2417038&cid=37328184 [slashdot.org]

http://it.slashdot.org/comments.pl?sid=2382470&cid=37111036 [slashdot.org]

http://it.slashdot.org/comments.pl?sid=2053436&cid=35611648 [slashdot.org]

http://tech.slashdot.org/comments.pl?sid=2419404&cid=37345104 [slashdot.org]

http://tech.slashdot.org/comments.pl?sid=2403804&cid=37250882 [slashdot.org]

http://tech.slashdot.org/comments.pl?sid=2419404&cid=37345104 [slashdot.org]

No, I am not arguing that self signed certificates themselves are good enough to fix the problem. Yes, I am arguing that HTTP and HTTPS with self signed certificates should be treated equally (but in the address bar it would be useful to have a quick way to view certificate hash keys - fingerprints).

My point is that the current model is outdated and very flawed because:
1. It relies on central authority to get certificates and authenticate them.
2. The browsers mistreat the self signed certificates without even trying to understand why that is in fact the wrong behavior if they cared about a switch to a safer web and better user experience.

I BET EACH RAN LINUX (-1)

Anonymous Coward | more than 2 years ago | (#37874946)

See subject-line above... it explains it all, as to WHY they were compromised (the inferior Linux security).

Bet you're right (0)

Anonymous Coward | more than 2 years ago | (#37875374)

You're downmodded's why, lmao. Means you told a truth Penguins can't handle's all. Hahaha, makes them look stupider than ever, like they're trying to hide something you hit upon.

Comodo.com runs Linux (0)

Anonymous Coward | more than 2 years ago | (#37879748)

Comodo's running Linux http://uptime.netcraft.com/up/graph?site=comodo.com [netcraft.com]

DigiNotar.nl runs Windows Server 2003 + IIS6 (they should upgrade to Windows Server 2008 & IIS7) http://uptime.netcraft.com/up/graph?site=diginotar.nl [netcraft.com]

What were the others that were compromised??

(That way, we can "settle the bet", because so far, it's a 50/50 split, nobody "wins", yet at least).

StartCom, Comodo, & GlobalSign run LINUX (0)

Anonymous Coward | more than 2 years ago | (#37879884)

http://uptime.netcraft.com/up/graph?site=StartCom.com [netcraft.com]

&

http://uptime.netcraft.com/up/graph?site=GlobalSign.com [netcraft.com]

So far, you're winning the bet!

You're MOSTLY correct that 3/4 known compromised CA's use Linux (along with Comodo.com http://uptime.netcraft.com/up/graph?site=Comodo.com [netcraft.com] ).

Each was compromised, per this article's proof thereof -> http://itproafrica.com/technology/security/cas-hacked/ [itproafrica.com]

(The only one that doesn't was diginotar.nl, & they either didn't update properly, and ought to use Windows Server 2008 + IIS7 (vs. Windows Server 2003 + IIS6)).

Toss on yet another CA breached recently (0)

Anonymous Coward | more than 2 years ago | (#37957152)

We gotta stop outsourcing trust (1)

Anonymous Coward | more than 2 years ago | (#37875366)

While we do it almost daily in our lives, what use do we really have for CA's? They're simply not trustworthy - not by technical skills, and sure as hell not by trustworthiness; CA's willingly co-operate with intelligence agencies, for example.

Wouldn't it be much better that we re-establish trust as a two party concept? For example, in order to make money transactions via bank, I would first go to a bank's website, my browser would tell me I'm being offered the bank's public key or similar, and I would then have to confirm via another channel to the bank - by going to the branch office, or by a phonecall - that it is the key my bank uses and that I trust it. This way, the trust would be between me and my bank only, and if something goes wrong, my bank will be responsible instead of some certificate "authority" that has no responsibility whatsoever.

Re:We gotta stop outsourcing trust (1)

grahammm (9083) | more than 2 years ago | (#37875730)

I wonder how may bank telephone helplines for on-line banking could tell a caller the fingerprint of, or even which CA issued, the certificate for their on-line banking service. I suspect that not many could.

Re:We gotta stop outsourcing trust (0)

Anonymous Coward | more than 2 years ago | (#37876286)

I wondered as well. So I called up my banking telephone helpline and asked them. They had the information available and even let me know that the current certificate expires in 18 days and so a new one will go into use shortly and I was welcome to call them up to verify the new one when it appeared. Admittedly I bank with a small local credit union that mainly has tech companies for it's business constituents.

This is why I love IT (1)

CAIMLAS (41445) | more than 2 years ago | (#37876922)

It's shit like this which makes me wish I'd picked another career. Plumbers aren't held liable or responsible if a specific fitting they installed is found to be defective or prone to corrosion; electricians aren't considered idiots for installing something which, at the fault of others, causes power failure to their TV.

Hell, even the dipshit developers are regarded with higher esteem than IT.

Bah CA's (1)

snowshell (2495332) | more than 2 years ago | (#37877416)

Why the hell would people pay for a CA from a signer like VeriSign or Comodo when both of those corporations retain the rights to the security certificates issued to you in the first place. It is far easier to employ your very own CA and remove both of these signing authorities from the picture entirely. After all lets face it if your not sharing your SSL keys with the entire world, then it really is a lot harder for people who should not have a copy of them gaining one.

Re:Bah CA's (1)

snowshell (2495332) | more than 2 years ago | (#37877448)

I've been using my own PKI for about a year now.. Capable of spawning RSA+SHA512@4068bit how is an attacker going to steal a copy of my CA? It's mine, so therefore you cant steal what I don't share!

Re:Bah CA's (1)

Jon Stone (1961380) | more than 2 years ago | (#37877488)

The CAs never see the private key material. When you apply for a certificate, you generate the private key and a certificate signing request (CSR). It's the CSR which gets sent to the CA to sign, not the private key. All the CA has a copy of is the CSR and certificate, which is public knowledge anyway.

Re:Bah CA's (1)

snowshell (2495332) | more than 2 years ago | (#37877504)

Yes and I can sign my own CSR as well.. So that removes the CA from the picture in it's entirety!

Re:Bah CA's (1)

snowshell (2495332) | more than 2 years ago | (#37877516)

Thats what I mean by become your own Certificate Authority.. Once you can create all the certificate signing requests, manufacture the certificates, sign the certificates, enroll them as PKS1,2,3,4,5,6,7,8,9,10,11,12 then you are truly laughing and giving two fingers to any other third party who presumes to sell you there SSL CA solution. CSR, CRL, SCEP, XPI, Attribute Cert... The list goes on and on... VeriSign & Comodo have had their day... Time for them to move out of the way...

Re:Bah CA's (1)

snowshell (2495332) | more than 2 years ago | (#37877568)

Would you like me to draft you a signed CA by me with 2048bit Data Encipherment complete with a revocation Certificate, how long would you like it to last as an Server SSL CA? Is until the year 3000 long enough!?!

Re:Bah CA's (0)

Anonymous Coward | more than 2 years ago | (#37877734)

ROFL go for it snow..

Re:Bah CA's (0)

Anonymous Coward | more than 2 years ago | (#37877756)

Thats really epic, this is why CA's are kind of like a law unto themselves, the fact you can produce your own signing key's and certs does indeed make CA's redundent. An lets not forget they charge people a small fortune to re-issue those SSL certificates as you quite rightly point out, on an almost yearly basis.

So fair play if you can indeed make your own CA. The BlackHat presentation on SSL & The future of authenticity preseted in the USA made a big who-ha of downloading Convergence and Convergence uses it's own self-signed CA which gets attached to the firefox NSS keyring. So SSL is in effect not really broken, they're just having their Certificates stolen and signed by other parties that can also sign their own CSR.

I think people have missed the alternative to CAs. (1)

DavidTC (10147) | more than 2 years ago | (#37879362)

It's discussed here [freedom-to-tinker.com] .

Basically, with DNSSEC, DNS cannot be tampered with. All you have to is have the DNS then itself provide the cert [faqs.org] , which the registrar then signs.

Basically, instead of having to send a CA our public key, and having them sign it and email it back, we just use the existing fact that, under DNSSEC, DNS records are signed, and stick so we just our public key in there. And unsigned keys can be checked there. Actually, it might be smart to have a specific mark on those keys, saying 'Check against DNS'.

This requires DNSSEC to actually roll out everywhere, of course, and requires client support. (And it requires DNS server support if we're actually going to use CERT records, but instead it could be something like SPF does...just use specially marked TXT records, and maybe just use the key fingerprint instead of the entire key.)

This actually has advantages over the current system. For example, it's trivial to revoke keys, whereas now, not so much. Domain owners can even 'revoke' keys they don't know about, like when they buy a name from someone else who still has SSL keys for it. The rules is: Whatever key is in the DNS work, if there's a security issue, just take that key out, put a different one in.

Of course, for a while, both DNS keys and CA keys would need to both work, but I actually think that, at some point, we should stop letting random frickin third parties in Belgium or Korea or wherever decide who is authorized to run an encrypted version of our domain name. The only person who is authorized to talk about what my domains are doing is my registrar and anyone they've delegated to! But certs could still be signed on top of that, to certify stuff like mailing addresses and company names and stuff. (Aka, the 'domain verification' signing would still be useful.)

Re:I think people have missed the alternative to C (1)

psydeshow (154300) | more than 2 years ago | (#37897400)

Yes, let's please use DNSSEC so that our domain registrar becomes our effective CA. I'm not kidding. It would simplify things enormously, and greatly improve security, especially for high-risk domains.

After all, I can go to any corrupt or government-operated CA and get a certificate for Google.com. But in order to to spoof DNSSEC I need to compromise Google's specific registrar, who has a very strong business incentive to not sign my fake google.com zone. The bigger the domain, the bigger the incentive to protect it.

You might not like the ICANN bureaucracy or the mechanics of DNSSEC, but compared to the existing CA/Certificate mess we have now, domain registration is a well-oiled machine.

Re:I think people have missed the alternative to C (1)

DavidTC (10147) | more than 2 years ago | (#37900806)

And while the registrar would 'sign' the keys, it wouldn't be a process like currently works. No one needs to send anything in and get it emailed back. DNSSEC is supposed to be completely automatic. And the internet is implementing DNSSEC anyway, because of other security issues.

So once that's in place, you would just log into your registrar and paste in a copy of your public key into the host management area, or you'd point BIND at a copy of your public key, or whatever. That's it. The key actually used by the web server is not signed by anyone, it's just confirmed to be correct via that secured DNS record.

And, hell, letting people secure sites without CA signing would be a great way to force registrars to get off their ass and implement DNSSEC, or risk customers moving elsewhere.

And, oh, hey, fun fact. This would have taken care of the stupid one IP per SSL site problem without worrying about that non-implemented new thing. How? Easy. People running web server could just make a single SSL cert that covers *, and then put it as the key to every domain they have. In fact, I don't see why that wouldn't be the standard anyway.

Instead? A completely nonsensical system, where J. Random Company is randomly allowed to issue certs for everyone in existence.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>