Why there are 3652 organizations that can read everyone's encrypted traffic

Why there are 3652 organizations that can read everyone's encrypted traffic

You may not be aware of this but if you are browsing the web or running IoT devices in your business or at your home, you are being protected by a 30-year-old security infrastructure. In this post, we will uncover the history of the internet PKI that holds most of the internet together today and highlight some of the most obvious threats and known flaws. This article is the first in a series investigating the current state of PKI and the events leading up to the first Diode concept.

In 1994, Netscape started to make the Web secure and created, with the SSL protocol, the first stepping stone for today’s Internet security. With it came the adoption of HTTPS - The secure version of the HyperText Transmission Protocol and the public key infrastructure based on the X.509 standard.

The Internet, being a rich archive, we can quickly find the first public version of the Netscape Navigator 1.0 from 1994, using “Wine,” a Windows emulation software, it is even possible to run Netscape Navigator version 1.0 today:

Netscape Navigator 1.0 was developed in 1994 by a team led by Marc Andreessen, who later went on to found Andreessen Horowitz

Unfortunately, there are hardly any websites that can still be viewed using this ancient browser, but let’s dig deeper!

Downloading the executable and seeing the RSA logo confirms that this version has SSL support, for the first time on the Internet. Using Linux command line commands strings and grep, we locate the embedded root certificates of this very first version. Here they are in all their base64 glory:

34a9c1e0f8d4650ede0c4b5ec8bae1ad  NETSCAPE.EXE

$ strings NETSCAPE.EXE | grep MII

We want to make them human readable and find out which organizations were here so early in the game. Unfortunately, these certificates from 1994 are not yet the X.509 standard certificates that we would be able to decode using the OpenSSL command line tools. But they still are ASN1 encoded, so we can dump them one by one with dumpasn1 and check their organizationName.First, we have to get from base64 to binary-asn1, and then to readable text. So in one bash command something along this line.

base64 -d - | dumpasn1 - 2>&1 | grep -m1 -A1 ' organizationName '

This takes a line of input from above and spits out the first line matching “ organizationName” as well as one line directly after that. Now to combine that with the previous command, we need one more tool. xargs will help us to split each of the four certificates and call the above decoding command for each one of them:

$ strings NETSCAPE.EXE | grep MII | xargs -I % -n1 sh -c "echo % | base64 -d - | dumpasn1 - 2>&1 | grep -m1 -A1 ' organizationName '" | grep -oE "'.+'"
'Netscape Communications Corp.'
'RSA Data Security, Inc.'
'RSA Data Security, Inc.'

There are a total of four certificates in the Netscape 1.0 binary belonging to three companies. Netscape itself, RSA Data Security, and MCI. At the time, MCI was a large telecommunications company that supported Netscape with a $7 million deal to build an online marketplace. For more on that background story, there is nice coverage directly between Marc Andreessen and Vint Carf at minute 24:00:

In 1994, there were only four root certificates. Each root certificate could be used to create entity certificates for websites. Subordinate intermediate certificates were introduced soon after, allowing organizations to keep the root certificates in secure cold storage while only using the subordinate intermediate certificates for creating new website certificates. At that point in time, the Internet had Internet PKI with fundamentally the same structure as today.

The name SSL coined by Netscape for this new protocol had to change after SSLv3 to TLS. Even though the protocol differences between SSLv3 and TLS were rather small, Microsoft, at that time competing with Netscape in the browser wars, required the name change in order to join the new standard.

From there to today, adoption of SSL/TLS, and with that, the internet PKI was slowly but surely gaining traction. While in 1994 there were only four trusted certificates, today we’re looking at a total of more than 3,600 known certificates with around 72% percent of all Internet traffic being transmitted in encrypted form. It has become a commodity.

In today’s Internet, setting up a domain and securing it with PKI is straightforward - in some cases, fully automatic.

This wide availability of trusted third party certificates has allowed the web to grow into all regions of the planet-we have trusted certificates from hundreds of organizations across more than 50 countries. But the system doesn’t scale: at its current size, the number of trusted certificates has become too large.

Oversight and governance of these certificates is largely a manual task across the whole Internet. Misuse of trusted certificates, as well as industrial espionage, are on the rise. To fight this angle of attack, new certificates are being issued for shorter and shorter validity periods, but this increases the maintenance efforts on the owner’s side who want to protect their communication. The recent US government shutdown showcased that again. During the relatively short shutdown period, multiple US government websites became effectively unprotected because the current Internet PKI system forced a renewal action, but operators we’re not able to renew the short lived certificates during a government freeze.

The Internet PKI as introduced by Netscape was an amazing achievement. It started the widespread adoption of secure communications. This achievement is even more impressive given that this type of distributed trust system, now spanning thousands of organizations, was developed years before blockchain based consensus was invented. However, the system is clearly showing it’s age. Having over 3,600 copies of what essentially are master keys around the globe doesn’t scale, and more importantly, does not sufficiently guarantee security anymore. This brings us back to the headline. Every single one of these certificates can be used to issue valid certificates for all domain names worldwide, and any one of them might do so in order to tap into your traffic at any time. Your browser, your operating system or the operating system of your IoT devices will not be able to tell the difference, because all these certificates are equally valid, yet you might be compromised.

Today we have much better tools to handle distributed consensus and are able to create security without thousands of master keys. In the upcoming posts of this series, we will be looking into some of the trust problems arising from this system, and conclude with why we are determined to move the internet and IoT especially beyond the current PKI structure to adopt blockchain technology for anchoring certificates and ownership instead.