Google discovers new security holes in SSL — is the entire system fundamentally flawed?

Share This Article

Google has discovered that an intermediate certificate authority had issued unauthorized certificates for multiple Google domains. The problem arose because the intermediate authority, MCS Holdings, had issued certificates for the Google domains, despite not holding those domains itself.

The reason it’s critical that companies not mint certificates for websites they don’t operate themselves is because doing so breaks the function of SSL itself. Here’s how the system is supposed to operate:

Your PC contacts a Google server, which returns a certificate. Your computer uses that certificate to encrypt a data session. The server confirms that the key is good and establishes the secure session with your PC. When certificates are signed by third parties, it allows the false server to execute a classic man-in-the-middle attack.

In a man-in-the-middle attack, an intervening certificate authority can pretend to be the genuine issuing authority, particularly if the intermediate certificate company is given the full authority of an issuing CA, which is what happened here. That’s not supposed to happen, as Google points out — the original Certificate Authority, CNNIC (the Chinese Internet Network Information Center) should never have given such authority to MCS Holding in the first place.

Fixing the TLS/SSL system

The problem with the SSL system — in addition to all the bugs, at least — is that it relies on the idea that Certificate Authorities will always issue good certificates. History has proven this simply isn’t true — multiple Certificate Authorities have been hacked, including companies like VeriSign and the now-defunct DigiNotar. Google wants to revamp the process of issuing certificates with its Certificate Transparency initiative. This project would:

• Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
• Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
• Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.

Certificates would be logged, and the logs would be monitored by public servers that would periodically check to see if malicious or unauthorized certificates were being used across the net. For example, if Certificate Authority XYZ issued an unauthorized certificate for Gmail, a Certificate Transparency Monitor would detect the problem and alert Google itself. Finally, the logs and monitors would themselves be guarded by a cryptographic watchdog program, which would check to ensure that SSL certificates were properly logged and that the logs weren’t tampered with.

The other problem with the TLS/SSL system, beyond the fact that it relies on intrinsic trust, is that the system can be easily subverted. Unless certificates issued by a particular authority are revoked, those certificates can continue to be used to wreak havoc. This is why the recent Lenovo-Superfish debacle was so dangerous. Until Google, Microsoft, and Firefox updated their own software to reject the Komodo certificate, it remained available and functional — effectively end-running around any security that a website might try to provide.