Should we trust certificates?

People often think that if a website is equipped with a certificate it is legitimate and secured.
Many people(and sadly, many AV vendors) also think that if an application is signed(once again, with a digital certificate) it is safe to run.

But wait, does it really that hard to acquire a digital certificate? And even if it is – are certificates so secure that we should trust them so much?

Modern certificates usually have a long encryption key and a well proven signing and encryption algorithms(SHA1/RSA), so breaking
them should be very hard. But there are some ways other than super computers and math geniuses to defeat strong certificates.

Comodo and Diginotar Incidents

Last year, a hacker broke into a server belonging to a reseller for Comodo, a well known security company and certificate authority. The attacker issued himself some certificates for site such as Gmail, Hotmail, Yahoo and others. With these certificates in his hands he could effectively disable the advantage of SSL and eavesdrop on users of those services. These certificates were revoked quickly.

Later that year, another attack was made(some say that even by the same attacker). This time the target wa the Dutch certificate authority DigiNotar. Several certificates  was issued, mainly for google.com and its subdomains. There were also some reports that these certificates was spotted in many man-in-the-middle attacks in Iran. DigitNoar has revoked the certificate several weeks after the attack.

So wait. You cant really handle sophisticated targeted attacks against root CA’s. It seems rational. Besides that, the certificates were revoked quickly and everything is back to be secured… Or is it?

OCSP

OCSP stands for Online Certificate Status Protocol. From Wikipedia:

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The “request/response” nature of these messages leads to OCSP servers being termed OCSP responders.

Just think about it for a minute. When an application uses a certificate(lets say, your browser) a revocation check is initiated to make sure that the certificate is still secure. It seems legitimate,
but what happens when the OCSP servers could not be reached?

Many companies and network are behind proxies and firewalls which allows only specific traffic to pass through, for example – only traffic to a certain server on specific ports. In such cases, the revocation check will fail. You might think that your browser will probably alert you about this serious problem, but you’ll be surprised to discover that most of the major browsers do almost nothing about this:

• Microsoft’s Internet Explorer provides no indication at all about it.
• Mozilla’s Firefox removes the EV(Extended Validation) marker. It’s pretty good, but 99% of the users won’t spot the difference between a site with Extended Validation and a site with only Domain Validation(DV).
• Google’s Chrome does the most and puts a little triangle on the padlock icon. If you click on it, it says that chrome was “unable to check whether the certificate has been revoked”. Once again, 90% of the users won’t spot this. They’ve told that if the site starts with https and a padlock appears next to the site address, they are 100% secure…

Even if the user isn’t behind a firewall or a proxy, a sophisticated attacker can use one of the stolen certificates and actively prevent users from accessing OCSP servers(assuming he controls the network, as in the Iranian story).

Hey, I’m “Trustme Solutions inc.”, Give Me a Certificate Please

Many AV’s treat signed files as legitimate. Modern AV’s often uses heuristic algorithms that gives “trust grade” to files according to some predefined variables. Most of these AV’s gives a very high “trust” grade to files that are signed with certificates – even if the certificate is issued to an unknown company. As long as the certificate authority is legit, the file is considered to be safe(or at least a lot safer than it would be without certificate).

But what prevents a malicious attacker from creating a cover company with no real identity, and buy a certificate for his needs?
Yes, this procedure used to be complicated, but buying a certificate nowadays its not that hard.

So just think about it – certificates, in my opinion, are not that safe as some organization think.

Until next time,