Steven B. Roosa is a Partner in our New York office.

Many of the media reports around the recent Superfish debacle completely miss the main issue.

First, though, let's recap what's been alleged about Superfish and similar types of pre-installed software. The allegation is that because a "root certificate" for Superfish was installed on the devices, Superfish was, among other things, able to get inside encrypted traffic from Facebook and other sites to display ads to the end-user. 

Okay, so what is a "root certificate" and why does my computer (or browser software) trust them? Root certificates are typically issued by third parties known as "Certificate Authorities" or "CAs," and come to reside on laptops, desktops, and all mobile devices because of agreements between, on the one hand, the device manufacturer/platform, or the company that makes the browser software, and the CA on the other. So far, so good.

How the Whole Authentication Thing Works

Root certificates are then used to verify the authenticity of a site because the CA also issues a separate set of certificates (called SSL or TLS certificates) to the websites. Any website with the option for HTTPS protected browsing (SSL/TLS) purchases such certificates from a CA.  These certificates are specific to each website/domain. 

When an end-user visits such sites, his or her browser software (or other software on the computer or phone, as the case may be, "the client software") checks its on-device repository of trusted roots. If it finds a root cert issued by the same certificate authority that issued the SSL/TLS cert, the client software will use some really fancy math to cryptographically prove to itself that the same CA issued both sets of certs. If this is successful, the client software will "trust" the website as being legitimate. We've bypassed some technical details, but this is basically the process.

Why the CA Trust Model Itself is Flawed

The most fundamental problem with the entire authentication regime is that any CA can issue a technically valid—yet totally unauthorized—SSL/TLS certificate for any domain on the web. So, in practice, to take a purely hypothetical example, XYZ CA could issue a technically valid, but totally unauthorized, SSL/TLS certificate to the National Security Agency (NSA) for Facebook.com. However, Facebook.com doesn't use XYZ CA and instead uses a different CA, namely DigiCert. Unfortunately, this doesn't matter one bit.  The only thing that has to happen for the NSA to read all the encrypted traffic, is for the XYZ root CA to have been included in the root repository for the browser software.

The upshot is that the end-user, for the entire Internet, doesn't trust just one CA to refrain from issuing bogus SSL/TLS certificates, but instead trusts ALL the CA's in the repository to refrain from such activity (there are some solutions to this issue, like cert pinning, but they aren't that widely deployed. Facebook, for example, doesn't use cert pinning, but apparently plans to at some point).

Okay, okay, so how bad is it? How many different CA's are in the trust repository for my browser or mobile device? The answer is a big boatload of them. What's worse, is many of the CAs have their principal place of business in various geographic locations around the globe where the CA is subject to governmental control by a government you may not trust (or at least not trust to refrain from wiretapping your communications).  Almost all browsers and mobile devices, for example, trust the root cert issued by the CA "CNNIC." CNNIC is a CA located in China and subject to control by the Chinese government. 

The end-result is that when I visit Facebook, I not only trust DigiCert to refrain from issuing bogus certificates, I also trust CNNIC and the many other CAs, in some cases, hundreds, to refrain from issuing bogus certificates, because my browser will trust them all equally. 

If you have a sensitive app or website, it's worth looking into this issue and employing countermeasures and additional safeguards for your end-users. The bottom line is that, irrespective of any particular allegation regarding SuperFish, there are more fundamental issues at play that warrant attention.

For further discussion on this topic, see "Trust Darknet: Control and Compromise in the Internet's Certificate Authority Model."

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.