The attack intent on Google proves one of the weaknesses of Public Key Infrastructure: Certificate Authorities

On August 29th, Google made public onits official blog that they detected a “Man in the Middle” (MITM) attack intent that could had been used to intercept information between all their web services (Gmail, Gdocs, search, etc) and some Iran ISPs.

The blog post also states that the attackers used a Digital Certificate (issued to *.google.com) from a Dutch Certificate Authority (or CA) called DigiNotar, which according to Google, it is not used by them. This is a proof of concept of one of the weaknesses in Public Key Infrastructure (or PKI).

This incident forced Google and Microsoft to remove DigiNotar as a Trusted CA by updating their operating systems and Internet browsers.

What are Digital Certificates, Certificate Authorities and Public Key Infrastructure?

A Digital Certificate is a documented issued by a third party (called Certificate Authority) that authenticates a person or entity and it is used to create secure (or encrypted) connections with the use of SSL (or Secure Socket Layer) protocol through Internet. A Digital Certificate contains information like: name, permitted use, issuer, issued to, encryption algorithms, serial numbers, expiration dates, dates issued, etc.

We can compare a Digital Certificate with a passport, which is a document with international validity used to identify its holder.

Certificate Authorities are Organizations whose mainfunction is to issue or revoke Digital Certificates. Before issuing them, they must perform a due diligence in order to validate the persons or entities that request them (known as requestors) and then issue them by applying their digital signature on their certificate.

Going back to our passport example, they must be issued by a government agency. In order to obtain or renew one, each requestor must provide proof of their identity by showing a national identity card or similar document. Once the government validates the identity, they issue the passport with their signature and corresponding formats.

Public Key Infrastructure is an authentication framework that involves a set of programs, data formats, procedures, communication protocols, security policies and public encryption mechanisms that working together allow disperse persons or entities to communicate in a predictable and secure manner.

In order for persons or entities to participate in a PKI, they must possess a Digital Certificate issued by a “Trusted CA”. A trusted CA is one that is considered as such by an operating system, Internet browser or user. Normally, operating systems are configured by default with a list of trusted CA. This is what allows persons or entities that possess Digital Certificates issued by different CAs, and that have never met, authenticate and communicate in a secure manner.

Going back to our passport example, it will be considered internationally valid if it was issued by an official and authorized entity. This means that different immigration services will check for a specific passport who is the authorized entity to issue it and will validate our document and identity by trusting that entity.

How was the attack intent on Google performed?

Google did not give out details on the attack itself, but with the Digital Certificate issued by a trusted CA to *.google.com and information found on the case, we can establish the following attack vector:

1. The attacker, by executing a DNS poisoning attack, modified the DNS cache entries of some ISPs from Iran. This allowed them to redirect all traffic to Google services to another server. Remember that a DNS resolves domain names into IP addresses, and each time it does this, it stores the resolutions in a cache for faster access. The DNS poisoning attack modifies the resolutions in the cache by injecting data that did not originate from authoritative (or original) DNS sources. 
2. Then, the attacker configured a Proxy server with which he can receive, modify (or sniff) and redirect traffic to others servers. Here is where our trusted Digital Certificate comes into play: When the users connect to the Proxy server (redirected thanks to the DNS poisoning), it authenticates to them by using the Digital Certificate obtained. Since it was issued to *.google.com and it was a trusted Certificate, browsers and operating systems will treat the proxy server as a legitimate Google site (their browser will show gmail.google.com and hence match the issued certificate).
3. Finally, the attacker will redirect traffic to the legitimate Google site. All traffic returning from Google to the user will go through the same Proxy Server, allowing the attacker to sniff it and thus obtaining passwords, reading mails, documents and search strings. 

There is information that indicates that steps 1 and 2 were executed, but this was never confirmed by Google. Moreover, the attack was detected and stopped by Google’s Internet browser (Chrome), which detected that the Digital Certificate was a fraud; hence, step 2 of the attack must have taken place.

The immediate action taken by Google and Microsoft was to remove DigiNotar as a trusted CA from their operating systems and browsers. This implies that all web sites that use certificates issued by this CA to authenticate or encrypt data, will receive an error from Internet browsers stating that the certificate in use was issued by a non-trusted CA.

Conclusion 

PKI is still a good authentication framework to Exchange information between unknown entities, but like all things, it has its weaknesses:

• Like it was demonstrated in this incident, the Dutch CA issued a certificate without doing a due diligence on the identity of the requestor, thus putting in danger the confidentiality of the information of group of Google users. 
• More than one CA can issue a Digital Certificate to the same person or entity. In this case, Google works with Verisign and not DigiNotar. 
• If the private key with which the CA digitally signed the certificate is compromised, all certificates issued must be revoked. 

What to do to avoid these incidents?

• CAs must perform a due diligence on the identity of the requestor.
• There should be a register, like the one used with domain names (registrars), that would allow a CA to detect if a requestor is already using or possess a Digital Certificate. By having this, fraudulent certificate issuing (like what happened to Google) could be avoided. 
• PKI should incorporate a new figure in its framework that incorporates the previous register. This register should be an independent entity that validates identities with authorized CAs. 
• Finally, browsers and operating systems should incorporate an additional control to use the new register suggested. A good example of this is Chrome, which uses this sort of controls only for their google.com domain.