DigiNotar SSL certificate compromise

August 30, 2011 3:14 PM

Two days ago a user asked Google about a strange warning he was getting when trying to access Gmail from Iran. Turns out he was getting a fraudulent SSL certificate that was issued incorrectly for *.google.com by DigiNotar, a Dutch certificate authority. It seems likely this was a deliberate man-in-the-middle attack to snoop email in Iran. This attack is the second SSL certificate compromise in a year (previously), pointing to a fundamental design flaw in Internet security.

Every web browser has a list of hundreds of certificate authorities representing entities around the world. All CAs are equally trusted: if any one CA has a security breach or deliberately issues a bad certificate then every site in the world can be impersonated. DigiNotar was compromised on July 19. Today, August 30, Google, Mozilla, and Microsoft have all removed DigiNotar's authority via a patch, closing this hole in their desktop browsers. Until the next time a CA is compromised.

posted by Nelson (45 comments total)

I removed the DigiNotar root CA cert from my Keychain on my Mac. No problem. But as an iOS user, I'm at a loss for what to do.
posted by cobra libre at 3:20 PM on August 30, 2011 [1 favorite]

How to manually delete the DigiNotar cert in Firefox.

Mozilla is updating Firefox without the DigiNotar cert in question as I write this. If you browse with Firefox, please be sure to update when prompted.
posted by gen at 3:56 PM on August 30, 2011 [2 favorites]

I'm not sure there's a fundamental design flaw in internet security. I think there's a fundamental design flaw in living in Iran.

I recognise that's not easily fixed, but it's easily recognised.
posted by edd at 4:03 PM on August 30, 2011 [4 favorites]

cobra libre, how did you remove it from your keychain?
posted by jcrbuzz at 4:05 PM on August 30, 2011

I went looking for Apple's response and haven't found any info on when they will have Safari updates for MacOS. Also no idea when iOS or Android will receive the necessary updates. Another piece of this story I didn't research is the certificate revocation infrastructure built in to browsers. There's a protocol for a CA to say "this certificate is no longer valid": in fact, DigiNotar claims they revoked other bad certificates that were fraudulently issued. But for a variety of technical reasons I don't really understand revocation is not always considered sufficient. Hence the patches for browsers. (In this case, it seems likely the browser companies are unimpressed with DigiNotar's handling of the breach.)

I stand by my claim that the trust model of SSL is a design flaw, whether you live in Iran or not. The entire purpose of SSL is to prevent a man-in-the-middle attack. Twice this year we've seen it's failed because of browsers' promiscuous trust architecture. In practice, in an actual clumsy attack. I expect the browser manufacturers will end up designing something more robust. Indeed Google already seems to have something: their announcement claims the fraudulent certificate was detected in Chrome.
posted by Nelson at 4:21 PM on August 30, 2011

I'd say that around 80% of the time I get any browser message about a certificate, usually because of expiration, it's on a US .mil domain. This bugs me because it inures me via these not-really-false positives to not really care much when I do see an expired certificate anywhere else. I assume this is largely because of the sheer number of sites and certificates that the Pentagon uses, but still, it seems like it shouldn't be happening at all.

Anyway, you have to wonder how many people were getting these errors and not reporting it.
posted by dhartung at 4:22 PM on August 30, 2011

I've always been bothered by the role of the Certificate Authorities in the SSL scheme. They exist solely to help people decide if a site is trustworthy or not, but in order to do so they take money from the company that wants to prove their trustworthiness. That leads to a conflict of interest.

This article explains the situation better than I can...

We now face a closed loop of continuous deterioration in the trustworthiness of certificates. Occasionally, a CA takes one small shortcut to keep an edge over its competition, practically setting a new, lower, standard. The other CAs, who will all lose from the impact of the shortcut taken by their peer (in terms of reduced public confidence) anyway, just follow suit to compete.

The other side of this is the number of CA's that are out there now. That number is going to increase. Can we trust all of their security practices? Clearly not. But as web users we have no choice, we just have to hope for the best.
posted by rouftop at 4:25 PM on August 30, 2011 [2 favorites]

Noted security researcher, Moxie Marlinspike's recent blog post, SSL And The Future Of Authenticity, is worth perusing. He goes into great detail as to why the current CA-based system is broken.
posted by gen at 4:32 PM on August 30, 2011 [5 favorites]

I wonder which government was doing the snooping: U.S., Israeli, or Iranian?
posted by longdaysjourney at 4:39 PM on August 30, 2011

As far as removing the DigiNotar certificate from your OSX Keychain, I (Snow Leopard/10.6.8) did it via: Applications -> Utilities -> Keychain Access. Select System Roots, scroll down to the DigiNotar certificate, click Get Info, open up the Trust Menu (via the 'disclosure triangle'), then select Never Trust (you'll be asked for your admin username/password). I tried deleting the cert, but wasn't able to.
posted by foonly at 4:39 PM on August 30, 2011 [6 favorites]

Thanks for that tip, foonly. I would have tried to delete it. I know Apple will do something in their next security update but I'd rather deal with it now.
posted by immlass at 4:47 PM on August 30, 2011

But for a variety of technical reasons I don't really understand revocation is not always considered sufficient.

It relies on browsers either regularly downloading certificate revocation lists from the CAs (which I don't think they do, poking around in Firefox it seems possible only to manually import a CRL) or verifying certificate status with OCSP (which Firefox does, but only for certificates that specify an OSCP server; and it looks like it defaults to trusting the certificate if it cannot reach the server).

Pushing a software update that revokes the certificate sidesteps all that -- and Firefox have been aggressively moving towards the Chrome update model of frequent incremental automatic updates so they have the infrastructure in place to do it. Microsoft also push root certificate updates through Windows Update which most people have set to update automatically.
posted by We had a deal, Kyle at 4:59 PM on August 30, 2011

Moxie also spoke on this topic (why SSL is broken, not DigiNotar) at Black Hat 2011. There is a video of his presentation available but I don't have the url handy.
posted by gen at 6:55 PM on August 30, 2011

Ah found Moxie's video url on his twitter feed.
posted by gen at 7:08 PM on August 30, 2011

Related: Mozilla's Bug 647959 - Add Honest Achmed's root certificate.

If your browser will show you the list of trusted certificates, take a look even if this "problem" has already been resolved by your browser's manufacturer. Holy crap, there's a lot of stuff in there. How can you possibly trust all of those authorities to both be honest and unhacked? Just the list of the ones starting with "A" can't all be seen without scrolling.
posted by jepler at 7:48 PM on August 30, 2011

This really does raise questions about CAs and the SSL certificate system in general. It was only this past March that Comodo was also breached, through an Italian reseller, in an incident also linked to Iran. Comodo was breached in 2010 too, if I remember right. I don't think that they have discovered exactly how DigiNotar was compromised, but the fact that a number of web defacements have been live on their site since as early as May 2009 doesn't indicate very good things...

The scope might be huge, too. Chrome has removed almost 250 non-Google certificates issued by DigiNotar. The question is if that's just a precautionary measure, or if sites like Skype, Windows Live and Yahoo (which were targeted in the March Comodo breach) were also targeted this time.
posted by gemmy at 7:59 PM on August 30, 2011 [1 favorite]

Government IDs aren't terribly secure either. In a hypothetical world where every CA checks for ID before issuing a certificate to anyone, the gain in security is marginal.
posted by LogicalDash at 8:03 PM on August 30, 2011

around 80% of the time I get any browser message about a certificate, usually because of expiration, it's on a US .mil domain.

This is because, as a general rule, the Pentagon is much more picky about its SSL certificate providers than the rest of the world. It basically has constructed its own trust chain, up from a variety of root certificates, that are used to secure public-facing .mil sites.

If you interact with the Pentagon or .mil space, you should probably install the DoD Root Certificates, which will keep you from getting certificate warnings all the time.
posted by Kadin2048 at 9:22 PM on August 30, 2011 [2 favorites]

A lot of certificates used by the Dutch Government are at risk - for example, the DigID is used for just about all communications between citizens and the government, including tax submissions.

Yesterday morning I heard a great one on dutch news radio – a tech journalist was telling the radio station he was called back in the middle of the night by the ministry spokesperson to state there was no problem at all with government web sites. Reaction by news radio host: “he called back in the middle of the night? Wow, they really must have a problem!”
posted by DreamerFi at 11:32 PM on August 30, 2011 [3 favorites]

MIT was (and maybe still is) the same way with its internal network. Install their root CA and all the warnings go away. It was one of the first steps in the getting-started-on-the-network guide. I imagine they did that because they had to sign assloads of certs (including personal ones for each computer of each user) and it would have been brutally expensive to pay some third party.
posted by breath at 11:33 PM on August 30, 2011

Wow who imagined this, CA internet security is an illusion, hehe...
Nice that the fixed the hole, are we all safe again?
Don't really thinks so, Ill bet you is going to happen again in the future, CA will be compromised again before we know it and browsing be unsafe. :(
Hmm but I like living life on the edge!! Thus I surf a lot.
posted by MarkusEllek at 12:52 AM on August 31, 2011

Hackers may have stolen over 200 SSL certificates: Sources say DigiNotar breach generated fraudulent certs for Mozilla, Yahoo and Tor, not just Google
posted by homunculus at 10:25 PM on August 31, 2011

Still no patches for MacOS or iOS from Apple, their release cycle must be a little slower. Also: Mac OS X Can't Properly Revoke Dodgy Digital Certificates. "Users can revoke a certificate using Keychain, but if they happen to visit a site that uses the more-secure Extended Validation Certificates, the Mac will accept the EV certificate even if it's been issued by a certificate authority marked as untrusted in Keychain."

Also no comment from DigiNotar/VASCO beyond the original press release. Their entire business is authentication, it's remarkable how poorly they've handled this breach.
posted by Nelson at 9:09 AM on September 1, 2011

A lot of corporations go the private-CA route too. (Hell, I do it with my LAN at home.) The public CA model doesn't add any security versus being your own CA on a closed network, and it costs a shitload of money for that zero benefit.

The commercial, public CAs charge ridiculous amounts for a certificate that delegates out authority and lets you sign other certificates (even though in the original ideas for the whole CA model, this sort of delegation was supposed to be a big part of it). Naturally, they want you to have to go to them every time you want to roll out a new server and get a certificate for it. So instead of doing this, you just act as your own CA, create your own root certificate, and push it out to all your clients ... verifying it (hopefully) over a secure side-channel. This way you can create all the internal certificates that you want.

If you have managed client machines that you push software out to (or are made from a common base image) this is pretty trivial to achieve. You just include the internal certificate as part of the image and things 'just work' for all the company computers.*

If you don't have control over the client machines it's a bit harder, but what some places do is purchase one certificate from a well-known public CA, to use on their public-facing web site. (E.g., they go to Verisign and buy a cert for www.bigcorp.com.) And then from that site, they let you download their private root CA. Basically they use the public CA infrastructure as a way to securely (in theory) hand out their private root cert, after which they sign things using the internal CA rather than paying each time for a public one.

What's dissapointing and dangerous is when institutions encourage people to download and install a private root CA from an unsecured page (like this one). It wouldn't be trivial, but nor would it be impossible, to conduct a MITM against the original certificate download, allowing an attacker to insert their own certificate into the victim's root store. In fact, I'd bet that if you set up an open wireless AP at a coffee shop in Cambridge around this time of year, and did nothing but watch for requests of that certificate file in particular and inserted your own hostile one, you might be able to do some interesting stuff. Though you'd probably want to include the real certificate alongside the poisoned one so that victims wouldn't notice as easily that they'd been duped ... but that's not that hard and I suspect a lot of users wouldn't be alarmed at having two certs in the bundle.

* Incidentally, it also lets you, if you wanted to, MITM secure connections from those computers by creating a bogus *.google.com or similar cert. Don't ever think that you're hiding from your employer just because you're using HTTPS, if you've installed corporate certs. And it also provides an easy way for governments to monitor citizens' internet access, if they want to: just make installing a government CA a requirement for paying taxes or something, and then use that root CA to issue bogus certs for your MITM wiretapping.
posted by Kadin2048 at 11:05 AM on September 1, 2011 [1 favorite]

Dutch media are reporting that the Minister of the Interior of the Netherlands is planning a news conference (some say "statement") on what is being described as "the security of government websites". It is nearing 1 AM here. I have never seen a government news conference after midnight, except for the few times a squabbling coalition finally announced its resignation in the wee hours.

This must be important news indeed — or Minister Donner just wants to be in time for the American evening news. Either way, I'll keep you guys posted.

My guess is it's related to this.
posted by goodnewsfortheinsane at 3:47 PM on September 2, 2011

The Minister has spoken! (It started around 1:15 AM CEST.) The gist, paraphrased, translation mine:

• It can no longer be guaranteed that users of NL govt sites are genuinely interacting with the intended agency.

• There are two types of DigiNotar certs: a "house brand", and a PKI range named "PKIoverheid" used by government agencies. The house ones are already no longer (automatically) trusted. NL govt will phase out DigiNotar certs, including the PKIoverheid ones, over the next few days.

• NL Govt sites will remain available to the public, but main browsers are expected to block DigiNotar certs within hours. Not only Dutch sites use these certs. [Unclear who uses them apart from NL govt, unclear if he means the PKIoverheid certs.] Users may find their browser alerts them to the site in question not being trusted. It would be advisable for users not to log in with the site until new certificates are in place.

• Donner dodges reporter's question on Iran govt involvement: "not clear, cannot be excluded, exact scope of breach currently unclear." Says hundreds of sites use DigiNotar certs.

Again, note that these are paraphrases, I don't have a transcript.
posted by goodnewsfortheinsane at 5:05 PM on September 2, 2011

English news article from Radio Netherlands.
posted by goodnewsfortheinsane at 5:15 PM on September 2, 2011

VASCO offers Dutch Government Joint Approach of Diginotar Incident

OAKBROOK TERRACE, Illinois and ZURICH, Switzerland – September 02, 2011 – VASCO Data Security International, Inc. (Nasdaq: VDSI; www.vasco.com) today announced that it has invited the Dutch government to jointly solve the DigiNotar incident. As part of its proposal, VASCO invites the Dutch Government to send staff to work together to jointly assess and remedy the problem.
“It is our firm belief that cooperating with VASCO is the right decision for the Dutch Government. We are convinced that together we will solve this issue,” said Ken Hunt, VASCO’s Chairman & CEO.

posted by finite at 4:02 AM on September 3, 2011

DigiNotar Removal Follow Up from Mozilla security blog

DigiNotar Compromise longer blog post by Mozilla employee Gervase Markham
posted by finite at 4:14 AM on September 3, 2011

OAKBROOK TERRACE, Illinois and ZURICH, Switzerland – September 02, 2011 – VASCO Data Security International, Inc. (Nasdaq: VDSI; www.vasco.com) today announced that it has invited the Dutch government to jointly solve the DigiNotar incident. As part of its proposal, VASCO invites the Dutch Government to send staff to work together to jointly assess and remedy the problem.
“It is our firm belief that cooperating with VASCO is the right decision for the Dutch Government. We are convinced that together we will solve this issue,” said Ken Hunt, VASCO’s Chairman & CEO.

Does that read a bit like a ransom note to anyone else?
posted by Sys Rq at 7:55 AM on September 3, 2011

I think one thing we ought to consider is splitting the aspects of authentication and encryption. It might be good to make it easier for sites to setup SSL without providing any credentials other then their IP address (and maybe the fact that the browser has seen the certificate before) -- Right now you get a big warning that might scare off non-technical users.

The other thing I was thinking about: I wonder if there's a way to make man in the middle attacks -- especially mass MITM less feasible. One way would for the client machine to do a proof of work thing, like hashing a value a large number of times and returning the 'smallest' hash (i.e. the one with the most leading zeros).

(The client machine would keep running this in the background while the connection is open, gradually becoming more and more secure)

Then in order to spy on N machines with an average power of X the attackers would need N*X flops of computing power. (And users could install powerful GPUs to make themselves harder to hack)
posted by delmoi at 3:21 PM on September 3, 2011

I'm not sure there's a fundamental design flaw in internet security. I think there's a fundamental design flaw in living in Iran.

so there are 174 trusted root CAs in my system (there were 175 until I deleted these jokers). any one of them can issue a certificate for google.com, or microsoft.com, or paypal.com, or whatever. that's 175 companies around the globe that I need to trust to maintain their system security, and god knows how many employees I need to trust to be honest and vigilant at all times. and if any of those companies or employees fail, then I can't trust anything on the web to be who it claims to be.

the security model is broken.
posted by russm at 10:34 PM on September 3, 2011 [2 favorites]

Rogue SSL certs were also issued for CIA, MI6, Mossad
posted by homunculus at 12:15 PM on September 5, 2011

DigiNotar Certificate Authority breach (FOX-IT Interim Report)
“Operation Black Tulip” [PDF]

Based on the logging mentioned above from the OCSP responder, we were able to extract the following
information. On August 4th the number of request rose quickly until the certificate was revoked on August
29th at 19:09. Around 300.000 unique requesting IPs to google.com have been identified. Of these IPs
>99% originated from Iran, as illustrated in figure 1.9

FOX-IT's map of OCSP requests over time (about the rogue google cert)

In his latest post, Comodohacker claims that he is the one that hacked DigiNotar as well. He also claims he still has access to four other "high-profile" CAs and is still able to issue new rogue certificates (including code signing certificates).

QFT:

if any of those companies or employees fail, then I can't trust anything on the web to be who it claims to be.

the security model is broken.
posted by finite at 12:39 AM on September 6, 2011 [1 favorite]

russm: you're quite right. There's clearly a problem although I don't see how to fix it. However, if I were a user in a country hostile to my ability to securely browse the web then I've got a much more severe problem - how am I supposed to bootstrap myself into a legitimate train of trust securely? If I can't guarantee that the browser I get to start with is legitimate how can I trust anything I view or download with it?
posted by edd at 7:57 AM on September 6, 2011

edd: the big difference is you only need to bootstrap your chain of trust once. sneak a single bootable USB stick into Iran (or wherever) and you can provide a secure communication channel for an arbitrary number of people, *IF* you can trust your certification path validation to not be subverted.

but of course you can't trust that, as has been demonstrated twice so far this year.

as far as solutions go, if DNSSEC was ubiquitous I'd like to see a world without CAs where any organization could publish its root cert data in the DNS and browsers would trust that for the relevant domain and any subdomains. not that it'll ever happen.
posted by russm at 4:24 PM on September 6, 2011

Mozilla has announced new requirements for CAs, including an audit and that CAs "Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance".

Apple still has not issued a fix for Safari. There are also no fixes yet for either Android or iOS.
posted by Nelson at 7:57 AM on September 9, 2011

Bitch and ye shall receive! MacOS security update 2011-005 was just released and disables the bad cert on Lion and Snow Leopard. Requires a reboot.

It's clear from Google, Microsoft, Mozilla, and Apple's fixes that SSL revocation as currently practiced is entirely broken. At least desktop computers have a solution; there's still no solution for phones.
posted by Nelson at 11:29 AM on September 9, 2011

Bitch and ye shall receive!

Words to live by.

Now they can focus on the mystery of vanishing iTunes credit.
posted by homunculus at 1:58 PM on September 9, 2011

Hacker Rattles Security Circles
posted by homunculus at 11:38 PM on September 11, 2011

I think one thing we ought to consider is splitting the aspects of authentication and encryption.

They have always been split. Unencrypted can be authenticated (HTTP Basic, Telnet, Rlogin, etc.) and SSL can be (is) unauthenticated. Do you mean removing certificate authorities?
posted by Threeway Handshake at 7:37 AM on September 13, 2011

Threeway Handshake - I think that's about authentication of the server to the client, not of the client to the server. (as in "it really is GOOG you're sending your credentials to, not some monkey-in-the-middle")
posted by russm at 5:10 PM on September 13, 2011

Technical Analysis from EFF: A Post Mortem on the Iranian DigiNotar Attack
posted by finite at 5:25 PM on September 16, 2011

as far as solutions go, if DNSSEC was ubiquitous I'd like to see a world without CAs where any organization could publish its root cert data in the DNS and browsers would trust that for the relevant domain and any subdomains. not that it'll ever happen.

hmmm, it looks like that might actually happen after all - DNS-based Authentication of Named Entities.
posted by russm at 12:25 AM on September 19, 2011

SSL And The Future Of Authenticity (linked earlier by gen) is a must-read blog post which explains why DNSSEC and DANE don't solve (and in fact actually worsen) the lack of trust agility, which is really the fundamental problem.
posted by finite at 7:37 PM on September 19, 2011