P-W-U:CA Article

From Digibase Knowledge Base
Jump to: navigation, search

The Fractures of SSL - Part 1 (The Problem)

While many are not aware of it, there is an ongoing concern in the field of InfoSec. Secure Sockets Layer (SSL) is the protocol suite that underpins many security implementations. It provides encryption between anything from customers and their financial institutions, to employees and their employer's secured systems containing trade secrets and process, or even simple things such as checking email. SSL provides protection against MiTM (Man in The Middle) attacks, eavesdropping.

However, when it comes to some implementations of SSL, say that of which is on your web browser or email client, there is currently a weakness, the Certificate Authority (CA) system. Certificate Authorities are the trusted ("trust" is a key word here) organizations that cryptographically sign certificates for internet services for identity verification (that green bar with the lock you see on your browser). This is done by each CA having a private key and a public key. A service operator, such as a web site owner, submits a certificate signing request to the CA. The CA signs it with their private key and is verifiable with their public key, which is installed into browsers/operating systems.

The original intent of this system was to provide users a means to verify that a website or service to which they are connecting is really the website or other service they are desiring, not a forgery, and that their communications are secured through SSL. It is a "certificate of identity" as it were signed by an authority which was deemed by the Internet operations community as trustworthy. Back when the Internet was smaller, the system worked, as the CAs each had a smaller clientele and were more readily able to be held to account for discrepancies.

Now, the CA system induces a weakness because it depends too heavily upon a third party (the CAs) to be trustworthy and to have adequate controls on their internal signing systems and not to be subjected to adversaries. There have been many occasions to date where these CA systems have been broken into and have had their signing systems compromised, even high-profile industry names such as Adobe. The difficulty is that, with enough trust, or if a CA has large enough clientele, they can never have their technological trust (which is the root certificates installed into operating systems and browsers) pulled, regardless if their social trust within the information security industry has ended. This leads to situations where CAs can become "Too big to fail".

One may think, "I can just have a CA sign for my domain and nobody else can forge." Not true. The CA system is not like the domain name system (DNS) where names are unique and there is a defined hierarchy. Within the CA system, two CAs can both have separate certificates for the same domain which are equally verifiable as correct. This has indeed happened with high profile sites like Google, Yahoo, Wordpress, and many other domains from the DigiNotar incident (10 July 2011), where Iranian users had their traffic compromised and were fooled by the malicious DigiNotar-issued certificates despite other certificates already existing.

Comodo's CA division has a similar incident on March 31, 2011 where an alleged state-sponsored attack was performed against it. An attacker attempted to obtain signed certificates for many communications-related sites to, again, perform a MiTM attack on the users' traffic.

There is no telling in today's world, where authoritative trust is becoming harder and harder, when said authorities can be coerced or otherwise compromised criminally (for whatever cause). The difficulty is that many of these trust mechanisms are embedded so far into various technological mechanisms it will take many years before alternatives even make PoC (Proof of Concept) demonstration to interested development audiences for prompt deployment of new suites. It is, therefore, our opinion that SSL is weakened, if not broken, until then.

We will be continuing this two-parter on this issue soon, the next part will be what a solution should entail and for what reasons.