Why Do We Trust Certificate Authorities?
In August 2011, an Iranian internet user reported a browser warning when trying to log into their Gmail account. The Chrome browser user contacted Google directly in a forum and asked whether it could be a MITM attack on the encryption. Google subsequently investigated the situation and confirmed the suspicion: there were attacks on the encryption of the communication, primarily affecting internet users in Iran. The certificate authority DigiNotar had, among other things, issued unauthorized certificates for google.com, which were accepted by browsers without question. It was thanks to a security feature published shortly before the incident in the Chrome browser that the misused certificate was noticed. For the Google email service Gmail, the new security feature checks not only whether the certificate is valid, but also whether it was issued by an authorized certificate authority.
In Chrome and other browsers, all certificates issued by DigiNotar were immediately revoked. The certificate authority, which had known since July 2011 about the unauthorized certificates for domains of Google, the CIA, the Mossad, the MI6 and others, was placed under the supervision of Dutch authorities and an investigation was initiated.
Why we are dependent on certificate authorities
The DigiNotar case is serious and raises the question of why certificate authorities exist at all. To understand this, let's first look at encrypted communication in general. If two communication partners, Alice and Bob, want to communicate securely, they must first agree on an encryption method that is considered secure by today's standards. This means that no methods are known that can break the encryption in an acceptable amount of time. Subsequently, both must agree on a secret key (for example, a password consisting of letters and numbers). There are methods by which Alice and Bob can agree on a common key without meeting in person or exchanging the key via a messenger. With the key that Alice has received through such a method, she could now send Bob encrypted information. But one question remains with these methods: does the key actually come from Bob?
Figure 1 shows a situation in which keys are exchanged. Alice receives a key and assumes that it comes from Bob (and vice versa from Bob's perspective). In reality, however, the attacker Mallory intercepts the communication and sends Alice and Bob their respective keys. Alice and Bob have no way of determining with certainty whether they possess the correct key.
This authenticity problem can be solved by trustworthy certificate authorities that all communication participants trust. Each participant has their key signed by the certificate authority. The participants send the key and the signature as a certificate to the opposing party. The latter can then check the signature and confirm the authenticity of the key. Figure 2 shows this situation for Alice and Bob: Bob has his key signed by the certificate authority and sends it to Alice. Alice trusts the verification by the certificate authority; she can be sure through the signature that she has received Bob's key. Mallory cannot pose as Bob with her key because she cannot present a valid certificate for this.
In the World Wide Web, the exchange of keys for secure communication takes place in a similar way. A website operator proves ownership of their domain, for example example.com, to the certificate authority. The latter issues a certificate to them, which the website operator uses for encrypted communication with their users. Since the users (rather their browsers) trust all valid certificates of the certificate authority, they can confirm the authenticity of the key and use it.
Certificate authorities are an essential component in this trust model. There are several dozen of them worldwide. Firefox browser users, for example, implicitly trust 92 certificate authorities (as of 20.03.2017). But as mentioned in the DigiNotar example at the beginning, there are certificate authorities that – intentionally or unintentionally – issue unauthorized certificates. The DigiNotar case is not an isolated incident; other examples are DigiCert (2011), the National Informatics Centre of India (2014), Comodo (2015), Thawte (2015), Symantec (2017), WoSign (various) et cetera. The reasons for issuing unauthorized certificates are diverse. They range from a disregard for standards to hacked certificate authorities and abuse by secret services or governments.
If an attacker gains possession of an unauthorized but valid certificate, encrypted connections are no longer secure. The attacker would place themselves between two communication partners using a Man-in-the-Middle attack and present the valid certificate. This is accepted because the client trusts certificates from the no longer trustworthy certificate authority. The communication is eavesdropped.
Protection against false certificates
The problem with certificates is not new. For this reason, several possibilities for protection against false certificates have been proposed in the past. These can be divided into the following four classes:
- DNS-based approaches
- Certification Authority Authorization (CAA)
- DNS-based Authentication of Named Entities (DANE)
- Notary-based approaches
- Perspectives
- Convergence
- Pinning-based approaches
- HTTP Public Key Pinning (HPKP)
- Trust Assertions for Certificate Keys (TACK)
- DNSChain
- Transparency-based approaches
- Certificate Transparency (CT)
- Sovereign Keys
The listed methods are described in subsequent articles and compared with each other.
Blind trust in certificate authorities?!
In this post, it was explained what role certificate authorities play for encrypted communication. They confirm the authenticity of keys through certificates. However, the past has shown that unauthorized certificates have also been issued and therefore obviously not all certificate authorities are trustworthy. Blind trust in these entities would therefore be wrong, which is why new methods are being developed to improve the system. These methods will be presented and discussed in future posts in the aramido blog .
