Hackers May Have Nabbed Over 200 SSL Certificates

CWmike writes "Hackers may have obtained more than 200 digital certificates from a Dutch company after breaking into its network, including ones for Mozilla, Yahoo and the Tor project — a considerably higher number than DigiNotar has acknowledged earlier this week when it said 'several dozen' certificates had been acquired by attackers. Among the certificates acquired by the attackers in a mid-July hack of DigiNotar, Van de Looy's source said, were ones valid for mozilla.com, yahoo.com and torproject.org, a system that lets people connect to the Web anonymously. Mozilla confirmed that a certificate for its add-on site had been obtained by the DigiNotar attackers. 'DigiNotar informed us that they issued fraudulent certs for addons.mozilla.org in July, and revoked them within a few days of issue,' Johnathan Nightingale, director of Firefox development, said Wednesday. Looy's number is similar to the tally of certificates that Google has blacklisted in Chrome."

Comments

Boring

[Mensa Babe]

All of the news about the SSL security flaws are starting to get boring. We had a related scandal just yesterday. The problem with SSL (or TLS, actually) is that it uses X.509 with all of its problems, like the mixed scope of certification authorities. It's like using global variables in your program - it is never a good idea. I can only agree with Bruce Schneier, Dan Kaminsky and virtually all of the competent security experts that we have to completely abandon the inherently flawed security model of X.509 certificates and finally fully embrace the DNSSEC as specified by the IETF. It is both stupid and irresponsible to have a trust system used to verify domain names in 2011 that is completely DNS-agnostic - and in fact designed in the 1980s when people were still manually sending the etc/hosts files around! There could be a lot of better solutions than the good old X.509 but in reality the only reasonable direction that we can choose today is to use the Domain Name System Security Extensions. Use 8.8.8.8 and 8.8.4.4 exclusively as your recursive resolvers. Configure your servers and clients. Define and use the RRSIG, DNSKEY, DS, NSEC, NSEC3 and NSEC3PARAM records in all of your zones. Use and verify them on every resolution. Educate people to do the same. This problem will not solve itself. We have to start acting.

Re:Boring

[Gerald]

"If you think it's nice that you can remove the DigiNotar CA, imagine a world where you couldn't, and they knew you couldn't. That's DNSSEC." -- Moxie Marlinspike

Re:Boring

[Anonymous Coward]

Those are Google's nameservers.

As long as we're distrusting authority you might want to mention that.

Using DNS provided by an advertising firm isn't exactly the healthiest thing for your privacy, maybe not now, but when those become the new 4.2.2.[1-3] and Google can monetize them.

Anyone who cares about his privacy should never rely on a Google product.

Re:Boring

[the_enigma_1983]

In response to DigiNotar incidences, some people are removing the root CA for DigiNotar from their computers. This way your computer will not trust _anything_ signed by DigiNotar.

With DNSSEC, if the people in charge of your DNS have an incident (hackers, malpractice or otherwise) which changes the "certificate" (for lack of a better word) for your website, you are stuck. There is no "root" certificate that you can remove.

Re:Boring

[dgatwood]

"If you think it's nice that you can remove the DigiNotar CA, imagine a world where you couldn't, and they knew you couldn't. That's DNSSEC." -- Moxie Marlinspike

That's a fundamental mischaracterization of DNSSEC. You can't realistically remove individual DNS registrars now, but they all feed into registries, and you generally either trust those registries or you don't. If you don't, then you don't go to those TLDs. More to the point, this argument incorrectly tries to model the security of all websites at the same time, whereas the user only cares about the security of a single website—the one he or she is trying to access.

With DNSSEC, you as the domain owner are in control. No one can take control over your domain in one place without fully taking control over your domain worldwide. You therefore choose your registrar based on having good security. As long as the registrars do not screw up and accidentally turn over control of a domain to someone else, you are safe. However, you are provably no less safe than you are now even if they do screw up in that way; most domain certificate issuance is now validated based solely on whether you have control over the domain name. Thus, if you take over the account for the domain name, you can get a cert from any major CA. Therefore, this attack vector is unaffected by DNSSEC.

What DNSSEC provides is a reduction in the attack surface. With DNSSEC, the trust that people place in a domain is solely trust in the owner of that domain and in the services (registrars) that the owner of that domain trusts. By contrast, with the current system, anyone can hijack a domain on a local network by forging DNS replies. If they can trick any registrar into issuing a certificate, they can then masquerade as that domain. Thus, because the certificates are not tied to the domain name system, by trusting a domain under the current system, you are trusting not only the domain owner and the providers that the domain owner trusts, but every other CA out there. So instead of someone having to trick a single registrar to compromise a domain, they could trick any of dozens of CAs. It only takes one.

Worse, with many (possibly all) browsers, the trust model is completely broken. If you trust a certificate, you trust a certificate. If that certificate has signing authority, you now trust every certificate that it signs. This means that all a website needs to do is trick you into accepting a self-signed certificate for some innocuous site, and from that point on, it can use that cert to sign forged certs for any other site. So in order to trust any single website, you not only have to trust every CA that your browser supports, but also every self-signed cert that you have ever accepted.

With DNSSEC, you need only trust the server, its registrar, and the relevant root registries. And even in the worst case, if a registrar started signing fake DNS entries, you are still better off than before because DNS signatures are only valid for a few minutes instead of a few years like SSL certs, and odds are such a problem would eventually be noticed, the registrar would fix the security hole that allowed this, and a few minutes later, any bogus records would cease to validate.

Thus, moving to DNSSEC dramatically narrows the amount of trust you are giving out when you access a domain name. This is inarguably a good thing according to any reasonable security analysis.

Re:Boring

[Zeinfeld]

Oh I know what he is trying but he has no clue what the threat model is.

The threat model in this case is a well funded state actor that might well be facing a full on revolution within the next 12 months. It does not matter how convergence might perform, there is not going to be time to deploy it before we need to reinforce the CA system. [Yes I work for a CA]

I think it most likely we will be seeing the Arab Spring spreading to Syria with the fall of Gaddafi. We are certainly going to be seeing a major ratcheting up of repressive measures in Syria and Iran. Iran knows that if Syria falls their regime will be the next to come under pressure. In many ways the Iranian regime is less stable than some that have already fallen. There are multiple power centers in the system. One of the ways the system can collapse is the Polish model, the people of Poland didn't have a revolution, they just voted the Communist party out of existence. If the Iranian regime ever allows a fair vote the same wil happen there.

Anyone think that we will have DNSSEC deployed on a widespread scale in the next 12 months? I don't and I am one of the biggest supporters of DNSSEC in the industry. DNSSEC is going to be the biggest new commercial opportunity for CAs since EV. Running DNSSEC is not trivial, running it badly has bad consequences, the cost of outsourced management of DNSSEC is going to be much less than a DNS training course ($1000/day plus travel) but rather more than a DV SSL certificate ($6 for the cheapest).

The other issue I see with Convergence is that it falls into the category of 'security schemes that works if we can trust everyone in a peer to peer network'.

Wikipedia manages a fair degree of accuracy, but does anyone think that they really get up to 99% accurate? Until this year the CA system had had three major breaches, all of which were trapped and closed really quickly plus about the same number of probes by security researchers kicking the tires. Until the Diginotar incident anyone who had revocation checking in place was 100% safe as far as we are aware, not a bad record really.

There is a population of about 1 million certs out there, even 200 would mean 99.95% accuracy.

Running a CA is really boring work. Not something I would actually do personally. To check someone's business credentials etc takes some time and effort. It is definitely the sort of thing that you want a completer-finisher type to be doing. Definitely not someone like me and for 95% of slashdot readers, probably not someone like you either.

The weak point in the SSL system is not the validation of certs by CAs, they are (in order) (1) the fact that SSL is optional (2) the fact that the user is left to check for use of SSL (3) the fact that low assurance certificates that have a minimal degree of validation result in the padlock display.

The weak point being exploited by Iran is the braindead fact that the Web requires users to provide their passwords to the Web site every time they log in. I proposed a mechanism in 1993 that does not require a CA at all and avoids that. Had RSA been unencumbered I would have adopted an approach similar to EKE that was stronger than DIGEST but again did not require a cert.

Certs are designed to allow users to decide who they can share their credit card numbers with. That is a LOW degree of risk because the transaction is insured. Certs are not intended to tell people it is safe to share their password with a site because it is NEVER safe to do that.

Re:Boring

[Zeinfeld]

Unfortunately the registrar system is rather less trustworthy than you imagine. We have not to date encountered an outright criminal CA. We do however know of several ICANN registrars that are run by criminal gangs.

The back end security model of the DNS system is not at all good. While in theory a domain can be 'locked' there is no document that explains how locking is achieved at the various registry back ends. A domain that is not locked or one that is fraudulently unlocked is easily compromised.

The part of the CA system that has been the target of recent attacks is the reseller networks and smaller CAs. These are exactly the same sort of company that runs a registrar. In fact many registrars are turning to CAs to run their DNSSEC infrastructure since the smaller ones do not have the technical ability to do it in house. In fact a typical registrar is a pure marketing organization with all technical functions outsourced.

There are today about 20 active CAs and another 100 or so affiliates with separate brands. In contrast there are over a thousand ICANN registrars.

Sure there are some advantages to incorporating DNSSEC into the security model. But to improve security it should be an additional check, not a replacement. Today DNSSEC is an untried infrastructure, it is grafted on to a legacy infrastructure that is very old and complex and security is an afterthought.

The current breach is not even an SSL validation failure. The attacker obtained the certificate by bypassing the SSL validation system entirely and applying for an S/MIME certificate that did not have an EKU (which it should). That makes it a technical exploit rather than a validation issue. DNSSEC is a new code base and a very complicated one. Anyone who tells you that it is not going to have similar technical issues is a snake oilsman.

Re:Boring

[Lennie]

Moxie meens dat with the current CA-system, you have several CA's. With DNSSEC you in a way have just one CA. So if one CA messes up, with the current system, you can remove that one CA. But with DNSSEC you can't remove that one CA, because it is the only one.

It is all more complicated ofcourse, but that is his message.

Re:Boring

[Lennie]

1. Actually, revocation checking does not solve the problem, alteast if someone had the CA private key, they could generate the same ID's as other existing certificate. OSCP/revocation lists only checks id's not names, which makes it not useful for all possible problems.

2. I also think DNSSEC can be useful, it would be really helpful for the domain-owner to be able to make it clear that his website uses cert X and cert Y (which implies CA A and CA B). And not any other cert or CA. Deployment of DNSSEC is very slow though at the moment.

We need at least 2 things:
- a fallback method that browser makers want to adopt where DNSSEC hasn't been deployed by the ISP or when you are stuck in a "hotel network" or your OS does not support and so on. Because the browser needs to get the keying material to be able to check the if the data is properly signed. It do not think it even matters where it got it from, any old fallback channel might probably do. For OSCP http is used, so maybe that is good enough here too ?

- much better industry support for automating the keyrollover communication with TLDs. If I get my domain at some provider and run my own DNS-server there is hardly any provider, if any, which support EPP or whatever to communicate my DS-record to the TLD. Many TLDs that have deployed some DNSSEC don't (yet) even support DNSSEC in their EPP from their direct customers/members.

3. Can you be a bit more specific about what you proposed in 1993 ?

Re:Boring

[Zeinfeld]

1. Actually, revocation checking does not solve the problem, alteast if someone had the CA private key, they could generate the same ID's as other existing certificate. OSCP/revocation lists only checks id's not names, which makes it not useful for all possible problems.

Neither CRLs nor OCSP are intended to mitigate a CA private key breach.

The only control in the system is to revoke the CA root and that can be effected on Windows by issuing a new CTL (as happened to revoke the Diginotar root) that drops the compromised root. The other browsers have similar mechanisms.

2. I also think DNSSEC can be useful, it would be really helpful for the domain-owner to be able to make it clear that his website uses cert X and cert Y (which implies CA A and CA B). And not any other cert or CA. Deployment of DNSSEC is very slow though at the moment.

The war could well be over by the time DNSSEC is deployed. The Iranian group have developed new attacks and dramatically escalated the sophistication of their attacks. The time between attacks has been weeks, not years. There is simply no prospect of large scale DNSSEC deployment in the next 6 months. the Iranian 'elections' are in March. I can't even see any possibility of deployment ahead of the next presidential election.

We need at least 2 things: - a fallback method that browser makers want to adopt where DNSSEC hasn't been deployed by the ISP or when you are stuck in a "hotel network" or your OS does not support and so on. Because the browser needs to get the keying material to be able to check the if the data is properly signed. It do not think it even matters where it got it from, any old fallback channel might probably do. For OSCP http is used, so maybe that is good enough here too ?

Working on both of those.

- much better industry support for automating the keyrollover communication with TLDs. If I get my domain at some provider and run my own DNS-server there is hardly any provider, if any, which support EPP or whatever to communicate my DS-record to the TLD. Many TLDs that have deployed some DNSSEC don't (yet) even support DNSSEC in their EPP from their direct customers/members.

3. Can you be a bit more specific about what you proposed in 1993 ?

Not without sounding really whinny.

At this point its water under the bridge, I have changed my mind on what the approach to security should be and so has the industry.

The browser that an Iranian dissident should be using is probably not the same as the one your granny uses to shop online for sex toys. There are security concerns in both cases but the risks and issues are totally incommensurate.

Re:Boring

[Tomato42]

3. Can you be a bit more specific about what you proposed in 1993 ?

There is a Secure Remote Password protocol that allows you to authenticate both server to you and yourself to server at the same time. There's also a RFC 5054 aimed to incorporate it to TLS, unfortunately without any client support AFAIK.

Diginotard

[utkonos]

So, I still say that if trust is lost once, nothing that Diginotard touches can ever be trusted.

Re:Diginotard

[sjames]

It's quite easy to do actually, but in this case, the vendors are taking care of it. The update went out on debian-security today. IIRC, mozilla is planning an update as well.

That's it, fuck CAs

[GameboyRMH]

CAs are done, stick a fork in 'em. Just generate your own certs. A CA cert only increases your chance of getting MITM'ed (since you don't have sole control over distribution), and without a big store of certs in one place, they'll be harder to steal.

Fuck CAs, install Convergence / Perspectives, call it a day.

Re:That's it, fuck CAs

[Karl Cocknozzle]

Couldn't agree more. Links for the lazy: Convergence and Perspectives.

Enjoy.

X.509 is fundimentally broken

[subreality]

How long until we collectively admit that centralized SSL certs are actually causing more problems than they solve?

The SSH model works great: connect to a site once; verify the fingerprint once if you consider a MITM to be a reasonable concern; cache the key and know that forever after you're connecting to the same site as you did the first time. That narrows the attack vector to active MITM attacks where Mallory can intercept your first connection (if they want to actually get your data) and every connection thereafter (if they don't want to be noticed). It makes widespread surveillance impossible (they'd be noticed) and targeted attacks very unlikely to succeed.

You can even add a CA to that model: have the first-time dialog be "[ nobody | ] certifies that is . Does that sound OK to you? (looks good) (hell no)". In other words, just make self-signed certs less scary, and CA-signed certs more scary... Which would accurately reflect the actual level of security you're getting: both are probably OK, and one is a little more certified but certainly not golden. Only pop up the BIG SCARY WARNING when the cert changes, even if it's signed by the CA.

Interesting thought

[93 Escort Wagon]

Let's say you were hoping to insinuate yourself unnoticed into traffic destined for a particular site - for the sake of argument, let's use the Tor project. What would be the best way to do this without someone suspecting you had a specific target in mind? Stealing a couple hundred certs all at once, only one of which is related to your project, comes immediately to mind.

It's not like similar approaches haven't been taken before, even in the non-digital world. I seem to recall that was one explanation John Muhammad gave for the DC Sniper attacks - he really wanted to kill his ex-wife, and hoped killing a bunch of other people would keep suspicion from him.

I don't get this

[HBI]

Chain of events as follows:

1) Fraudulent issue of certificate
2) Revocation of certificate
3) Clients find out...how?

As an example, I downloaded the cert Google offered up on encrypted.google.com. It had no OCSP specified, but it did have a CRL specified. Now, is Firefox checking the CRL embedded in the cert or not? I think it is, but the only way to confirm would be to actually try to hit a site with a revoked cert. FF by default is configured to only use OCSP if the cert has the information embedded in it, which this Google cert didn't. Which doesn't give me the warm fuzzy about other certs, either. I checked a few others. The Verisign sites, including RapidSSL, have an OCSP URI embedded. So that's better.

My point is that the whole revocation business remains slipshod and saying that you 'revoked' the certificate doesn't mean a hell of a lot in reality.

Re:I don't get this

[BZ]

Yes, this is why browsers are also shipping updates with certs explicitly distrusted.... and why the fact that DigiNotar did not tell browsers about the problem a month and a half ago when it happened is such a huge issue.

Re:Wait a second...

[bill_mcgonigle]

...wouldn't the certs be useless without the associated private keys?

No, the government of Iran generated a key and a CSR for *.google.com, had Diginotard sign them (not sure if this was social or technical hack) and then deployed them inline for a MitM attack on the residents of the area their organization controls.

They have the key and the cert. They didn't get Google's key or cert, they have their own.

I wonder how many dissidents have died because of this sloppy CA and the reliance on the CA system.

Re:It's not "boring". It's an important lesson.

[sjames]

If you keep a spare house key on your front porch in a metal box marked spare house key you'll be robbed sooner or later. This is not a flaw of the lock and key security.

The public key system is working fine. What is not working so well is the trust model. The current system is fatally flawed in that security depends on none of the many many CAs failing. It doesn't matter if you choose a high quality CA to sign a cert for your site, your users can still be fooled by a backwater CA you've never heard of before and wouldn't trust to guard a dime.

Don't forget about BGP hijacking

[NevDull]

Realize that the "area their organization controls" can be vastly increased, like China Telecom showed. http://bgpmon.net/blog/?p=282

Re:There are always tradeoffs

[Zeinfeld]

DNSSEC has its place, even for key distribution. But it does not provide a basis for trust because mere holdership of a DNS domain does not mean you are trustworthy.

The big win for DNSSEC is to distribute security policy in a scalable fashion. See my CAA and ESRV Internet drafts.

Imagine that you are visiting slashdot, wouldn't it be better to use SSL than en-clair if the site supports it? Wouldn't it be better to have encryption with a duff cert than no encryption at all? [*]

DNSSEC allows a site to put a flag in its DNS to say 'always use SSL when visiting slashdot on http'. Now the server knows that if it is going to slashdot and it is not encrypted there is a man in the middle. Same for Twitter, Google etd.

DNSSEC can also be used to ensure that the only certs trusted for a domain are ones authorized by the domain holder. This provides an independent trust path to CA issued X.509. If used in combination, security can be improved.

[*] The catch is that showing the user the padlock icon for a duff cert is going to make them less secure. That is why I would like to see the browsers remove the padlock icon completely for DV certs. the only reason the padlock is required is to allow the user to check that SSL is in use. Since the user can't and won't do that reliably it is a poor control anyway. But it is in any case a control that should be enforced by the browser not the user and DNSSEC security policy allows that to happen.

On key distribution, well sure, for typical Web services and for promiscuous security, DNSSEC validated keys are just fine. It is not going to be a money saver. It does not justify a padlock icon (neither does a DV cert). But it is perfectly adequate for most applications.

Unfortunately it is likely that making use of DNSSEC for key distribution is going to be delayed for at least a year due to IETF politics. I blame the people behind the DANE proposal. They have been less than forthcoming about their real agenda from the start and have shown absolutely no willingness to accept any input from other parts of the IETF. The IETF is a consensus based organization but the test is IETF consensus, not working group consensus. If a clique wants to change the rules for handling PKIX certs they have to get an IETF consensus that this should be done.

DANE could have easily been designed in a way that allowed security policy and key distribution to be completely separate. Unfortunately the ruling clique insists these be joined. The result is a spec that is in my opinion undeployable because the transition strategy for a scheme providing positive trust (key distribution) is by necessity very different to that required for a scheme that provides negative trust (key revocation, security policy, etc.).

Manually Remove DigiNotar as a CA!

[trawg]

Can't see anyone having posted this, but Mozilla have instructions on how to remove DigiNotar as a trusted CA in your Firefox. I'm sure other browsers have similar processes.

I also note they've just released a new Firefox (and Thunderbird) version that has removed the CA entirely - good response:

Because the extent of the mis-issuance is not clear, we are releasing new versions of Firefox for desktop (3.6.21, 6.0.1, 7, 8, and 9) and mobile (6.0.1, 7, 8, and 9), Thunderbird (3.1.13, and 6.0.1) and SeaMonkey (2.3.2) shortly that will revoke trust in the DigiNotar root and protect users from this attack. We encourage all users to keep their software up-to-date by regularly applying security updates. Users can also manually disable the DigiNotar root through the Firefox preferences.

maybe this will help you make sense of it

[Onymous Coward]

SSL And The Future Of Authenticity, Moxie Marlinspike:

Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility. As unrealistic as it might be, I or a browser vendor do at least have the option of removing VeriSign from the trusted CA database, even if it would break authenticity with some large percentage of sites. With DNSSEC, there is no action that I or a browser vendor could take which would change the fact that VeriSign controls the .com TLD.

If we sign up to trust these people, we're expecting them to willfully behave forever, without any incentives at all to keep them from misbehaving. The closer you look at this process, the more reminiscent it becomes. Sites create certificates, those certificates are signed by some marginal third party, and then clients have to accept those signatures without ever having the option to choose or revise who we trust. Sound familiar?

The browser CA model is screwed up. DNSSEC is screwed up. What's the answer?

I think Marlinspike was smart to start with defining the problem. And now, with Convergence, he's also trying to address it. Check it out. (And check out Perspectives. Perspectives is the project he based Convergence on.)

et tu; get your terms right

[Onymous Coward]

"He's resorting to name calling, which means he's wrong" is itself an ad hominem.

Public key crypto is not the same thing as the current browser HTTPS CA trust model. Make the distinction and you'll be better able to understand him.

DigiNotar root cert revoked in Firefox 6.0.1

[Torodung]

http://www.mozilla.org/en-US/firefox/6.0.1/releasenotes/

Expand "what's new" to see the change.

Update immediately if this is worrysome to you.

These certs were revoked yesterday in an out-of-band patch.

Re:It's not "boring". It's an important lesson.

[Hijacked Public]

No, it is a flaw of lock and key security because the human who operates the system is as much a part of it as the lock and the key. Though you might not blame the lock or key for that specific incident it is still a problem.

This is not to say that it is convenient or even possible to design a flawless security system, only that there is progress to be made in keeping one's eyes open as to the ways they can go wrong.

Re:There are always tradeoffs

[Zeinfeld]

No seriously, the "trust" in "trusted third party" has nothing to do with the trust that you put in the second party (i.e. the server or business with which you are communicating). It has all about to do with the trust you put in the third party (the certification agency), that it correctly does its job (only giving certificates to properly identified entities and appropriately securing their infrastructure so that hackers and spies can't just "help themselves"). The threat that SSL certificates are supposed to protect against is wiretapping, not rogue businesses. I'm sure, all of those shady banks that failed in the 2008/2009 crisis had valid SSL certificates, and rightly so!

Let me explain. I have been working on Web security now for 19 years. I was present at the original meetings at which the SSL system was proposed, I convened several of the relevant meetings.

At no time was government wiretap a design consideration for SSL. NEVER. In fact to claim this was totally ridiculous since at the time we were fighting a running battle with the FBI and the NSA who were trying to stop us using strong cryptography at all. The original SSL design was limited to 40 bits and was very clearly crackable.

SSL is not designed to be wiretap proof, my proposal and the EIT proposal were stronger in that regard. But at the time the criteria was whether shopping online could be made as safe as shopping in a store. That was the design criteria by which SSL was judged and the design criteria it passed (after they eventually hired some competent crypto people). I was the person who stated the design criteria at the meeting.

Re:It's not "boring". It's an important lesson.

[sjames]

That's a splitting of hairs that's worse than useless. We might as well cease looking for fault and just declare it all human error. Since we can't rid ourselves of that, we can then stop trying.

Or, we could actually try to make useful distinctions.