Problem Areas for SSL
The security of the transactions for much of the consumer Internet relies on the Secure Socket Layer (SSL) protocol. SSL and its Public Key Infrastructure (PKI) are critical Internet infrastructure. Most consumer Web, email, and VoIP traffic relies on SSL for security as does substantial portions of enterprise Internet traffic both from SSL enabled Web applications and SSL-based VPNs.
Fundamental problems increasingly put this infrastructure at risk. Significant risks include flawed implementations of the SSL protocol and PKI, inadequate verification mechanisms for certificate issuance, limited implementation of revocation mechanisms, and involvement by state actors in the issuance process. There are no viable alternatives to the mainstream use of SSL that are currently widely accepted or deployed.
Cryptographic Flaws
The first analyses of problems with the protocol focused on the cryptographic aspects of the implementations, which largely stabilized with the release of TLS 1.0/SSL 3.1 in 1999. The IETF (Internet Engineering Task Force) released the last version of SSL in 1996, which it superseded with the Transport Layer Security (TLS) protocol released in 1999. Still the protocol is primarily referenced as SSL.
TLS versions 1.1 and 1.2 added further security refinements, although they are not yet widely implemented or deployed. Recent flaws target weakness in the SSL framework and not the encryption itself. One notable exception is the 2008 discovery of weakness in the MD5 cryptographic hash function that allowed security researchers to create a false Certificate Authority certificate that could sign other valid SSL certificates.
User Interface Problems
The second phase focused on user interface and user experience aspects of SSL. In particular, people simply ignored the large number of security warnings about SSL certificate problems no matter what their severity. Users are more vulnerable to both hijacking and phishing attacks when they become desensitized to certificate warnings. The Mozilla Foundation investigated usability problems and experimented with multiple user interfaces to prevent and train users from navigating to sites with invalid SSL certificates.
Implementation Flaws
The OpenSSL toolkit is widely used to generate cryptographic keys for SSL certificates and SSH keys. In 2006, a developer on the Debian Linux distribution team modified the OpenSSL source to eliminate errors generated by a debugging tool. The change had an unintended side effect that eliminated most of the entropy destined to seed the pseudo-random number generator, which caused the modified version of OpenSSL to produce weak cryptographic keys for the Debian version of OpenSSL. Another Debian developer discovered the flaw in 2008. In the intervening time, flawed versions of OpenSSL created an estimated 25,000 weak and easily compromised SSL keys.
In 2009, researchers discovered the potential for man-in-the-middle type attacks by targeting the renegotiation feature of SSL, which allowed changes to keys in-connection to accomplish tasks such as upgrading the key strength. I described the problem in “A Practical Attack and Fixes for Current SSL/TLS Vulnerabilities.”
Moxie Marlinspike published a series of man-in-the-middle-based attacks on SSL starting in 2002 with the sslsniff tool, which exploited a vulnerability that allowed leaf certificates to act as signing certificates. In 2009, Marlinspike published a new tool called sslstrip, which could forcibly downgrade HTTPS connections to insecure HTTP connections. He also published a “null prefix attack” that could trick some browsers such as Firefox into accepting specially crafted certificates as wildcard certificates. Finally, he published an attack on the Online Certificate Status Protocol (OCSP), which allowed him to present revoked certificates as valid. Marlinspike and others have created widely available software and techniques to compromise the security of SSL via man-in-the-middle attacks.
Infrastructure Constraints
The implementation flaws highlight the problem that the SSL and PKI infrastructure is both distributed and constructed from many different implementations of SSL, which can be difficult to patch or upgrade quickly. The large number of SSL implementations for embedded devices further compounds the problem.
The tools to verify the integrity of digital certificates, certificate authority roots, and the chain of trust between them are not widely deployed. While modern browsers increasingly include support for certificate revocation, the support is uneven. Many non-browser implementations of SSL do not check for revoked certificates. Recent large-scale surveys of SSL certificates have found substantial numbers of certificates with intentional and unintentional errors, including a significant number of possibly malicious certificates.
Problems with Certificate Issuance
There are a limited number of root certificates that are widely accepted by nearly every browser, which can be highly profitable for the certificate authorities that own them. At the same time, there is a financial incentive to offer certificates with the least possible overhead. Because of this, many certificate authorities require only limited verification to issue certificates.
This type of limited validation called domain validation typically only requires that the certificate requestor be able to receive email to certain administrative email addresses. Limited validation periodically results in attackers devising ways to inappropriately request certificates for domains that may not be legitimate.
Extended Validation certificates are an attempt by certificate authorities to offer higher cost certificates with substantially higher verification requirements to ensure that only legitimate requests receive certificates. Still, the process of purchasing certificates is overly complex and many sites do not have SSL certificates, even when they would be well served by them. I discussed some of the difficulties in purchasing certificates in “No Frills SSL Certificates Are Inexpensive and Useful.”
Root Certificate Bundles
Root certificate bundles or root certificate stores contain the collection of root certificates that the browser or other SSL enabled service will automatically accept as trusted. However, root certificate bundles often contain many certificates without detailed provenance information. In April 2010, the Mozilla project discovered a root certificate that had been included in the root certificate bundle for many years, but whose owner was unknown. Eventually, Mozilla determined there was a miscommunication and that the root certificate belonged to RSA, but the situation underscored the tenuous provenance of some of the certificates of the bundles.
There are a number of widely used certificate stores on a single machine that are controlled by multiple entities. For example, while Microsoft Windows and Mac OS X offer system wide root certificate stores, Firefox uses a certificate bundle maintained by the Mozilla Corporation. Server applications, especially on UNIX systems may contain their own root certificate bundle.
The policies for inclusion in certificate stores vary widely and the influence of payment is unclear. The Microsoft Windows root store may load new certificates on demand, meaning that there is no precise list of valid root certificates.
Influence by State Actors
There is growing and widespread awareness of the policy and political dimensions of SSL certificates, especially as we find that state actors may have undue influence over some certificate authorities. State actors may compel vendors, carriers, or paid attackers to insert additional certificates into the root certificate stores either openly or surreptitiously. Christopher Soghoian and Sid Stamm published an analysis of what they call a “compelled certificate creation attack” in their paper “Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL” (PDF).
Root certificates are high value targets as they can produce certificates that can decrypt communications and effectively verify identities of individuals with client certificates and for entities with host certificates.
In 2010, the EFF petitioned the Cybertrust division of Verizon to revoke the certificate for Etisalat in the United Arab Emirates after the telecommunications company issued a BlackBerry firmware update that included surveillance software. Also in 2010, there was a significant debate on the Mozilla policy list about the inclusion of a root certificate for the China Internet Network Information Center (CNNIC) certificate authority in the Firefox certificate store. The argument was that while CNNIC was affiliated with an academic institution, it was not free of government influence.
The problem is that any certificate authority may issue a certificate for any domain on the Internet. The problem is further complicated by the fact that each browser, operating system, and a great many server applications may use independent root certificate stores that may contain an unknown collection of root certificates, which will automatically trust any SSL certificate signed by that root.