Digital Certificates: Who Can You Trust?

10	Digital Certificates: Who Can You Trust? 9:26 am (UTC-7)   |    by Hitomi Kimura (Security Specialist)

Digital certificates are the backbone of the Public Key Infrastructure (PKI), which is the basis of trust online. Digital certificates are often compared to signatures; we can trust a document because it has a signature, or certificate authority (CA) by someone we trust. Simply put, digital certificates are a reproduction of a simple model which occurs in the real world.
Incidents involving digital certificates have been in the news recently. Issues surrounding digital certificates and CAs are not always clear or noticeable to end users. However, IT managers, software developers, and other security professionals need to understand these problems so that the risks can be properly managed.
So who or what can we trust online?
Every computer connected to the Internet contains a list of trusted root CAs. These root CAs issue certificates, which can be used to either sign certificates for other CAs or to servers. There needs to be a “chain of trust” from any certificate that the system sees to any of the root certificates that it trusts.
What does “trusted” mean?
If a secure connection or signed file is “trusted”, this generally equates to an absence of warnings. Digital certificates are used to secure websites using SSL/TLS, identify and validate executable files using code signing, and secure email via Secure/Multipurpose Internet Mail Extensions (S/MIME). If a browser accesses an HTTPS server with an untrusted server certificate, it will generate a warning. If an unsigned or untrusted executable file is run, a warning message may be generated. A user may see these messages and avoid potentially risky behavior.
HTTPS is widely used as a way to assure users that connections to sites are authentic. Many users view the “green bars” that browsers use to mark HTTPS addresses as a sign that their connections are safe.
This trust is based on two things:

1. CAs are not supposed to issue certificates to inappropriate users.
2. Users (e.g. PC, browsers or mobile devices) should not add any inappropriate CA to the list of trusted CAs.

Unfortunately, the basis of this trust is now being challenged. Institutions and organizations that may not necessarily be trustworthy are widely thought of as such.
Here are several cases that highlight the problems, in today’s trust-based CA system.
Trust lost: CAs issuing certificates to inappropriate users
CAs need to have a good track record when it comes to securing their own systems to ensure they don’t issue improper certificates. However, they have been incidents where their own security and processes were targeted.
In 2011, an attacker calling himself the ComodoHacker was able to penetrate the systems of Diginotar, a Dutch CA. The attacker issued multiple fraudulent certificates. The loss of confidence in Diginotar’s security led to major operating system vendors removing them from their lists of trusted CAs. This eventually led to Diginotar shutting down as a business.
While Diginotar was a relatively minor player in the CA market, the attacker also claimed to have access to the networks of Comodo, which was a far larger CA.
More recent cases are just as troubling. In March 2015, Comodo issued a certificate for the live.fi domain to an unauthorized party. This domain was the Finnish domain of the live.com online services, which is a part of Microsoft. How was this the case?
Comodo issued what are known as Domain Validation certificates to Microsoft. These types of CA require the site owner to verify that he does control the domain he wants a CA for. The most common method is to send an email from that domain with one of several possible email addresses, namely:

• admin@
• administrator@
• postmaster@
• hostmaster@
• webmaster@

The live.fi domain is used by Microsoft to provide free email… and a clever Finnish man found that the address hostmaster@live.fi was available. He was able to acquire this address and use it to obtain certificates for live.fi that would have been trusted by any browser, but was not under the control of Microsoft. In interviews, the Finnish man stated he had already reported the problem to Microsoft and Finnish authorities in January of 2015.
The certificate could have been used to mount man-in-the-middle (MITM) attacks with a certificate that would have been verified by any browser in use. This would have fooled many users into giving up their credentials. Comodo cancelled the certificate, and Microsoft released a separate update for Windows as well.
Fortunately, there was a silver lining. Only one fraudulent certificate was created, and it could not be used for other purposes. This is because the allowed uses are defined in the certificate (Extended Key Usage). Certificates for SSL servers can only be used for server verification; code signing certificates are limited to that specific purpose as well.
Later in the month, Google had their own certificate snafu. They discovered that an Egyptian ISP (MCS Holdings) held a digital certificate that could be used for MITM attacks via a proxy. Generally, these proxies require that a certificate be installed in devices to be transparent. However, in this case, the MCS Holdings certificate was signed by the China Internet Network Information Center (CNNIC), which was included in root stores. This means that any certificates issued with the MCS Holdings certificate would be seen as valid by systems, even if they had no “right” to issue that certificate (i.e., for domains they did not own).
As in the case of Diginotar, this incident has resulted in serious consequences for the CAs involved. The certificate issued by MCS Holdings has been blacklisted by Google, Microsoft, and Mozilla. In addition, CNNIC itself has been targeted for action as well.
Both Google and Mozilla have indicated that moving forward, certificates issued by CNNIC would no longer be trusted. This means that while organizations that currently rely on CNNIC-derived certificates can still use them, once these certificates expire, new certificates (with a different CA) will need to be acquired.
These cases highlight the inherent risk in a CA-based model: attacks targeting CAs can occur, and if these certificates fall into the hands of attackers with strong motives to intercept communications, user information could be put at risk. For the CAs themselves, any lapse in the process of how certificates are issued can result in a swift blacklisting, instantly ruining what can be a profitable business for the CA.
Mistrust added: inappropriate CAs among trusted CA lists
The most recent case of a CA being added to user systems was Superfish, where adware capable of monitoring HTTPS traffic was preinstalled on Lenovo PCs. Due to the (poor) way it was implemented, in a nutshell, anyone could issue any certificates.
This means on any PCs with Superfish installed, the trust placed in HTTPS might well be misplaced: phishing by making a malicious sites appear to be secure, intercepting communications using MITM attacks, signing malware so that users would run it, making users believe that signed mail was legitimate.
It is difficult, if not impossible, to use the Internet if there is an underlying current of distrust. If we can’t tell if our visits to Gmail, Facebook, Twitter or online banking sites are safe, we can’t even browse websites. If we can’t tell if the program we’re try to run is real or not, even opening what we think is Notepad entails a risk.
What should users and CAs do?
CAs need to ensure that their own systems are secure to minimize the possibility of fraudulent certificate issuance. They should also be careful about issuing certificates to widely recognized and popular domains, especially since the effects if such a wrongly issued certificate becomes public may be significant. A system based on trusting institutions (such as CAs) only functions well if the said institutions are actually trustworthy.
CAs should consider verifying via other means of communication (such as the phone) requests for certificates from domains, as this is a step cybercriminals may have difficulty meeting. Recipients of certificates with more privileges (such as the one issued to MCS) should be subject to tighter controls to prevent potential abuse.
Site owners who want to ensure that fraudulent certificates are not issued in their name should consider pre-registering the email addresses frequently used for website verification, to ensure they stay under the control of the site administrator. Alternately, those addresses should be set aside and not registered at all.
The current CA-based system of trust is not perfect, and relies on both certificate authorities and users to exercise good judgment and prudence. It is far from perfect, but it is what we have now. Additional safeguards can improve the security of SSL certificates. As more and more sites become HTTPS-only, this issue will become more prominent in the coming years.