Over the last couple of weeks, DigiNotar, a Dutch Certificate Authority, has been in the news following a breach back in July. This was a major story because it showed a real life example of a very serious security problem that could affect everyone online. This happened just months after an earlier similar event, where a Comodo subsidiary also had a breach, and fraudulent certificates were issued. Here, I’ll briefly go over what happened, some basics on how certificates work, and what you as an IT professional can do to protect your users from these breaches and other similar ones.
First, you probably know that for an SSL connection to occur, a certificate has to be involved. These certificates can’t be issued on their own, otherwise they will not be trusted by anyone. Those are called Self-Signed Certificates and are of no use to production environments. Instead, an administrator who wishes to create a secure site will create what’s called a Certificate Signing Request (CSR) which has very specific information about the site they run, their identity as an individual or company, and their contact information. Then, they transmit that request to a trusted Certificate Authority (CA).
That CA, or more often one of its subsidiaries, will then generate the signed certificate using its own private key, after verifying that you are authorized to have a certificate for that domain name. In turn, their own certificate may be trusted by a higher CA, which in turn is trusted in all of the popular web browsers. That’s what’s called a Certificate Hierarchy.
Figure A
And that’s where the problem lies. There are hundreds of such trusted CAs in our browsers, and each of them can produce certificates for any website on the web. That means if any of them gets hacked, and their private key released in the wild, the hacker can create a certificate for any website they want, and all of our browsers will see it as valid. Worse, they can make certificates for any use, including signing email, encrypting VPN connections, etc.
But what is the attack vector on this? To be able to use such a certificate, the hacker would need to intercept traffic and insert their own fake certificate in a Man-in-the-Middle (MitM) attack. In the case of DigiNotar, that’s exactly what happened. The Iranian government has proxy servers through which all of the country traffic transits. With such a certificate, it meant that they can suddenly access every single user’s Gmail account, bank account, or any encrypted connection they want in the country, since they had the private key of a trusted authority, and could then issue CSRs for any website they wanted.
The real solution to this is complicated, such as wide use of Online Security Certificate Protocol (OSCP) or using trust networks, and would require a major redesign of the way the Internet works. For now, browser makers are in the business of patching up after an event occurs. Since the DigiNotar breach, every popular browser has been updated, and the trust in this CA has been removed. This means websites that have a certificate signed by DigiNotar will no longer work in Firefox, Chrome, IE or Safari. But this is hardly a good solution. It took over a month between the initial breach and the patches.
Mitigating the threat
In the mean time, there are things that can be done. First, if you’re in a locked-down location, where people are expected to go only to very specific sites, it makes no sense for their browsers to trust the Hong Kong post office, the China certification authority, or the countless other places that your browser currently trusts. You can manually go in and remove the trust in everything but the top few CAs.
Figure B
But even that isn’t a sure way to prevent such a hack. That’s why there are extensions out there that do a site-by-site check to ensure that certificates aren’t changed for no reason. One such extension is CertPatrol for Firefox. Every time you go to a secure website, it stores the certificate fingerprint. Then, when you go back, it compares the current certificate with the one it stored. It will then alert you if something suspicious happened. For example, if the certificate of a site had 6 months still before expiring and suddenly it was changed, that may be suspicious. Worse, if you went to a site that was signed by VeriSign, and now it’s signed by a Norwegian company you never heard of, that’s a big red flag.
Another useful security measure was something the Chrome developers added. All Google sites are signed by a few trusted authorities, and Chrome knows about them. For example, Chrome will not allow you to connect to Gmail if it was signed by the wrong CA. If your organization uses Google Apps, this may be a good reason to switch to Chrome.
Finally, it’s important to remember that this kind of security problem isn’t something that has to be fixed in a single place. To exploit it, the hackers have to also inject themselves somehow, either on the user computers through malware, on your network by breaking through firewalls, or by changing the DNS of your users. Each of these attack vectors has to be secured. There are things you can do like set static addresses in your DNS servers for sites your users have to access often, such as partner companies, payroll portals, and so on, which will prevent anyone from using a fake certificate to fool someone into connecting to the wrong site.
The DigiNotar breach will happen again. With hundreds of CAs trusted all around the world, it’s a juicy target, and hackers never give up. But even if such things get hacked, it doesn’t have to mean you or your organization has to be vulnerable. By doing some of the things I listed, you can greatly reduce the chance that such a problem may affect your users.
