Impact of the Diginotar hack

Last Updated on 2022-07-08 by Joop Beris

In June 2011 Diginotar, a Dutch provider of SSL certificates, was hacked. The hack was probably carried out by hackers working for the government of the sovereign nation of Iran for the purpose of obtaining forged SSL certificates for a number of high level domains, such as Google and Yahoo, among others. With the help of those forged certificates, it was possible to snoop on encrypted communication of Iranian citizens by using them in a classic “man in the middle” attack. While the successful hack is significant in and of itself, it has far-reaching implications for the entire world.

Cover up

Unfortunately, Diginotar kept the successful hack a secret, even though the follow up investigation by Fox-IT discovered that they were aware of the hack by June 19 and the abuse of forged certificates by July 28, possibly earlier. By not reporting the hack and compromised certificates to concerned parties such as browser manufacturers, government officials and the police, Diginotar acted irresponsibly and demonstrated extremely poor judgement. People rely on SSL certificates for their security and by not disclosing any details, Diginotar endangered supposedly secure processes and quite possibly the security and lives of Iranian citizens. What they did do though, was revoke a large number of forged certificates quietly, as many as 246.
As more and more details became available and more sources began to pick up on the hack and an abuse of one particular bogus certificate for google.com which was missed by Diginotar began to draw attention, GOVCERT.NL was notified by German CERT-BUND of the abuse. Diginotar continued to downplay the impact of the hack, claiming only one or two of its root CA’s were compromised and it’s PKI for the Dutch government was not affected. This was before the results of the Fox-IT investigation were known so it was too early to claim anything with certainty. And in fact the Fox-IT investigation concluded that the entire Diginotar PKI infrastructure as well as the internal network had been open to the hackers, including the government PKI. The Fox-IT report is so damning that it is safe to assume that the hackers probably had access to the company coffee machine and everything else as well. Read the entire report for the sordid details here.

Operation Black Tulip v1.0

Aftermath

As the details of the hack and the level of access the hackers enjoyed became clear, people quickly attempted to contain the damage. Mozilla, Microsoft and Google all issued statements that Diginotar certificates were no longer trusted and released updates that effectively blocked access to sites secured by a Diginotar SSL certificate. The Dutch government swooped in and took control over Diginotar assets. Dutch government agencies and representatives scrambled to exchange their Diginotar certificates for certificates from other suppliers, as did other organizations that relied on Diginotar. This process is ongoing at the time of writing. The name Diginotar has become all but worthless in the eyes of many. As a result of the trust revocation, plenty of websites and machine to machine services that relied on Diginotar stopped working or at least stopped being encrypted. This is also currently being worked on and I am sure that everything will be moved to new certificates shortly and all will be well again. Or will it?

Fundamental flaws

No, not really. If anything, the Diginotar hack has helped illustrate again that the current system of trusted SSL certificates is actually fundamentally flawed. An SSL certificate is really nothing more than a digital passport. And just as with a passport, its worth depends on your ability to check if it is valid. If you can not determine if it is or not, what good is a certificate or a passport? Ultimately, it all boils down to trust. Do I trust the issuer of the certificate? That’s where the so called “chain of trust” comes in. How does that work? Well, something like this. Suppose a friend comes up to you and wants to borrow a 10 Euro note. Do you trust your friend? Well, let’s say you do because you’ve been friends for many years and you know he’s good for it. The chain of trust is very short, only two links, so the identity of your friend and his trustworthiness are easily established by you yourself. This short chain of trust is very rare on the internet. The chain of trust is more like the following example. A friend of a friend, or a friend of a friend of a friend comes up to you and asks to borrow a 10 Euro note. Now, things get more complicated. You trust your friend, but what about this friend of a friend? Can he be trusted? Well, your friend says he can be, so you have to take his word for it. Do you? That’s up to you.

With SSL certificates, it is the same as above. You connect your computer to a website, say google. You want to log in to your Gmail account, so your browsers switches you to an SSL encrypted connection. Basically what happens is that the Google Gmail website says “Hi, I’m Google, here is my certificate”. Your browser checks the chain of trust and sees that the digital certificate is issued by the Google Internet Authority (your friend’s friend), so basically all it knows now is that Google trusts Google, which is not saying very much. However, the Google Internet Authority is trusted by the company Equifax (your friend, in this analogy). And herein lies part of the problem. Two companies of which, let’s face it, you know almost nothing about and one says that you can trust the other. Before reading this post, had you ever heard of Equifax? Perhaps not. So how much trust do you put in them assuring you that they trust Google? Fortunately, you do not have to check this chain of trust because your browser manufacturer supposedly has done this for you.

The chain of trust is only as strong as its weakest link. Suppose that, like Diginotar, Equifax was hacked and a number of certificates forged. If you connected to a server hosting a forged certificate, how would you know that you were not connecting to Google but to a malignant third party? Well, you wouldn’t. You wouldn’t because there is no way that you could confirm this, short of manually checking if the server had an IP address in a netblock issued to Google. And not even doing that would make you immune to a man-in-the-middle attack, because the party controlling your DNS server, also determines what you see when you query the DNS. The average internet user would never notice the difference, something which happened to the Iranian public. At best, SSL in its current form offers the illusion of security which is arguably worse than no security at all.

Change is needed

It is clear that the world at large can not rely much longer on the security offered by SSL certificates. The problem is though, that there is no real alternative for the current infrastructure. The problem of identity remains very urgent on the World Wide Web. What is needed is a way to securely determine the identity of the server or person you are communicating with, in a way that can be automated, is non-intrusive, is near impossible to compromise, is trivial and easy to implement. All the while preserving the privacy of people. In short, we need a silver bullet…