Internet users, including many security professionals, often blindly
rely on SSL/TLS to provide the confidentiality and integrity of our
personal data, at least when using our web browsers. We expect
SSL/TLS to do so even in the face of attackers with the ability to
hijack and redirect our network connections and DNS traffic (i.e., a
man-in-the-middle attack). To resist these attacks, our browsers rely
on a list of trusted certificate authorities to authenticate server
certificates. Browser vendors audit these certificate authorities,
but must presume that neither the trusted root authorities nor any
intermediate authorities chaining to a trusted root will sign a
certificate for an entity without first verifying that the entity
controls the domain name listed in the certificate.
Unfortunately, our faith in SSL/TLS is increasingly misplaced.
Accompanying the string of severe security vulnerabilities affecting
SSL/TLS libraries in recent years are three specific issues that
undermine our browsers' ability to verify a server's certificate:
- The list of trusted certificate authorities on a client device can
be customized. This is an issue in any situation where the user of a
device is not also the administrator. Corporate enterprises often use
this ability to add a custom, internally controlled CA to the list,
used solely to sign phony certificates for the purpose of SSL
- Some certificate authorities have allowed devices to be
constructed, containing an intermediate CA chaining to a trusted root,
for the explicit purpose of producing phony certificates on-the-fly to
perform SSL interception while avoiding certificate warnings or the
need to install a custom CA into each client device .
Large organizations can obtain and internally operate a sub-CA
chaining to a trusted root, allowing them to issue certificates to
their servers in bulk, rather than submit an individual requests to
the CA for each server . Frequently, no technical constraints
prevent an organization from using the sub-CA to issue certificates
for domains they do not own. Though legal agreements may preclude it,
these organizations can and at times do, without the root CA's
permission, load their sub-CA into an interception device to perform
man-in-the-middle attacks with phony certificates that appear
legitimate to browsers [4, 5].
In light of these issues, and the inability of browser vendors to
effectively police certificate authorities that fail to fulfill their
important responsibilities in the Internet security infrastructure,
technical solutions have been proposed to supplement or replace the
traditional CA-based model. Of those solutions that augment the
existing CA infrastructure, rather than replace it, nearly all are
fully client based (e.g., certificate pinning). The server still has
no way to detect and block attempted SSL/TLS interception attacks.
For some time, all significant web browsers have had the built-in
capability to generate public-private key pairs. Long known in
academia but rarely used in practice, this can be leveraged to achieve
mutual client-server authentication. The server acts as its own
certificate authority for the purpose of authenticating the client.
In doing so, we replace an SSL interception device's problem of
producing a phony server certificate to suppress warnings on the
client with the harder problem of fraudulently obtaining a client
certificate from the server. With a sufficiently secure process in
place for obtaining the client certificate, we allow the server to
resist, if not prevent, automated interception, or at least require an
interception device to perform attacks that may cross legal boundaries
in order to obtain the client certificate, such as phishing.
Routine SSL/TLS interception is rarely performed outside of enterprise
networks today. Still, just as hijacking failed DNS queries ,
advertisement code  have become routine and accepted behavior among
ISPs, we fear that interception could reach public networks in the
future, in light of certificate authorities' demonstrated willingness
to assist in performing it. Just as these three examples are touted
by ISPs as "helping" their users, SSL/TLS interception could be cast
in a positive light as an anti-malware or content filtering feature.
In this section, we provide enterprises' motivations to perform
interception and an overview of how it occurs, explore three recent
examples demonstrating public certificate authorities' role in
interception, and review the inability of browser vendors to
effectively prevent the authorities from doing so.
Large enterprises are justifiably concerned with the risk that
Internet connectivity presents. Potential unauthorized data egress
could lead to financial and reputational harm. In order to monitor
for this, many large corporations implement data loss prevention (DLP)
systems, which put proxy servers in place to monitor traffic for
sensitive data or malware.
In the past, many websites used HTTPS in exceptional cases, such as
the transmission of the password from a login page, or receiving
credit card information. Thus, the end-to-end security provided by
SSL/TLS was not a major issue for the DLP system. More recent web
applications use HTTPS to protect the entire site. The pervasive use
of HTTPS for webmail, social networking sites, forums, and chat
clients introduces a significant attack surface allowing incoming
malware or outgoing confidential data to travel through the network
without detection. Data loss prevention systems now include SSL/TLS
inspection as a feature; some vendors of these applicances claim that
an organization cannot be HIPAA or Sarbanes-Oxley (SOX) compliant
without SSL inspection .
The advent of bring your own device (BYOD) environments is challenging
and raises many questions. The use of SSL interception against these
devices, and the presence of mobile device management (MDM) in
general, mean that from security and privacy perspectives the device
is, for all intents and purposes, company owned. Particular issues
- How is personal and business use of the device distinguished to
ensure that only business traffic is intercepted and monitored?
- Who ensures that the interception stops if a user leaves the
- What stops the interception if a user gives a device to a family
member as a hand-me-down and buys another?
- Misunderstandings about the role of the device (treated as
personal by the employee outside of work hours, but as company
by the enterprise) could lead to significant issues, e.g., if confidential
employee communications with OHSA, the EEOC, the NLRB, or other regulatory agencies is inadvertently monitored and captured by the employer.
We concede that SSL interception in a business environment may be a
case of making the best of a bad situation, under certain conditions:
(1) the interception is facilitated using an internal certificate
authority that does not chain to a publicly trusted root, to preserve
the security model of public certificate authorities, (2) the
interception is performed only against company-owned or controlled
(BYOD) devices, and (3) users expressly consent to the monitoring
(e.g., through a network usage agreement) and truly understand
its implications. But corporate employees are just beginning to
become aware of the privacy implications of business security controls
, and thus we believe that an entity operating a web server should
be able to protect its users by detecting SSL/TLS interception, if
As long as publicly-trusted root certificate authorities (and all
intermediate certificate authorities chaining to those roots) fulfill
their role in the web's security model by refusing to provide signed
certificates to anyone other than a domain's owner, wide-scale, robust
SSL/TLS interception is not possible in the absence of unrelated
security vulnerabilities. Without the ability to produce trusted yet
phony certificates for servers while performing interception, a system
must use its own custom certificate authority to produce those
certificates, with one of two consequences: (1) the need to install
the custom authority as trusted on all machines affected by the
interception, or (2) the need to override certificate warnings on all
An important concept in the certificate authority industry is the
concept of a subordinate certificate authority (sub-CA), also known as
an external CA. Sub-CAs allow businesses who are not in the CA
business to act as a CA regardless, by obtaining a sub-CA that chains
to a trusted root. The purpose of sub-CAs is to allow businesses with
the need to issue large numbers of certificates to their own devices
to manage this process on their own, rather than interacting with a
public CA each time a certificate is needed. GeoTrust is one
certificate authority that issues sub-CAs; in order to obtain one, an
organization must have a five-million dollar net worth . Many
large companies own sub-CAs, including Aetna, EarthLink, Dell, Ford,
Fuji Xerox, General Electric, Google, and Wachovia .
The problem with sub-CAs is in preventing an entity with a sub-CA from
signing certificates for domains that it does not own. The X.509
field used to restrict the scope of domain names that a CA can sign,
name constraints, is not widely supported . In fact, a survey of
the entire IPv4 address space found 1,832 trusted (intermediate or
root) CAs, of which only 7 had name constraints imposed .
Consider how three recent examples involving sub-CAs being used to
produce phony certificates show that the classical root certificate
authority-based trust model is breaking down:
- Trustwave. In 2012, Trustwave issued a sub-CA to a private
organization . This sub-CA was to be loaded into a device
performing a man-in-the-middle attack, and its sole purpose was to
allow that device to generate trusted certificates for arbitrary
domains, allowing interception against all devices on the network.
This approach avoided the need to install a custom root certificate
across all device, and also prevented certificate warnings, by
chaining the phony certificates to Trustwave.
- TURKTRUST. In 2013, a sub-CA issued by TURKTRUST, a root
certificate authority based in Turkey, issued a phony certificate for
the google.com domain. The certificate pinning capabilities
added to Chrome by Google detected this certificate in the wild
- ANSSI. Also in 2013, ANSSI, a root certificate authority
controlled by the French government, issued a sub-CA to the French
treasury department, IGC/A, and IGC/A in turn used the sub-CA to
intercept and monitor employee web traffic .
Failure to Effectively Police Certificate Authorities
When failures in the certificate authority trust model keep occurring
each year, what consequences or penalties apply to the certificate
authorities? A legal analysis of certificate authorities found that
certificate authorities often use legal language to disclaim any
warranty for a party relying on one of their certificates, and the
case of an end user relying on a false certificate is untested in
court . Thus, the only effective recourse against misbehaving
certificate authorities is for browser vendors to remove those
authorities from the list of trusted CAs distributed with browsers.
As removing a trusted CA from browsers in response to a handful of
invalid certificates causes collateral damage (all sites using valid
certificates issued by that CA would begin receiving certificate
warnings), the browser vendors have been reluctant to do so. The only
prominent example was DigiNotar, whose trust was revoked only after
DigiNotar itself was compromised .
A review of Mozilla's security policy newsgroup [18, 19] illustrates
the frustration that many in the Mozilla security community have with
the inability to effectively police certificate authorities. Despite
the fact that ANSSI was non-compliant with Mozilla and CA/Browser
Forum policies, and the fact that both the TURKTRUST and ANSSI
compromises had to be detected by third parties, rather than caught
and self-reported by the CAs themselves, Mozilla determined that
removing these CAs from the trusted list would be too disruptive. It
is clear that there is little incentive for certificate authorities to
make the investment in improving their practices as long as even the
CAs with the poorest practices remain trusted.
When a compromise or abuse of a certificate authority does occur,
blacklisting the affected certificates on client devices may happen
only after a lengthy delay, if at all. The DigiNotar CA compromise
was detected on August 27, 2011 , but the first iOS release to
remove DigiNotar from the trusted store occurred on October 13,
2011—nearly three months later. On some older Android devices,
the end user could not control the built-in trusted certificate store
at all; a certificate blacklist feature was not added until the
Jellybean release (4.2) .
Since it is evident that the integrity of root certificate authorities
as a whole is unlikely to improve in the near future, many have worked
on developing solutions. Some propose to replace the CA trust model
entirely, such as the Convergence system by Marlinspike . Others,
such as Google, seek to build more defense-in-depth security checks
into the existing model.
Certificate pinning as implemented by Google Chrome  and Mozilla
Firefox  allows the browser to maintain a pre-loaded list of
acceptable public keys for a handful of high-profile websites, such as
Google, Twitter, and Facebook. This feature has already detected
real-world attacks . The limitation of certificate pinning (as of
this writing) is that each protected site must be explicitly built
into the browser, and requires cooperation with the browser vendors in
order to add a new site, so it is not scalable to any but the
highest-profile websites at this time. Other solutions, such as the
Certificate Transparency initiative , aim to improve certificate
authorities by having the authorities make a public log available
containing their signing actions.
Mutual Authentication and SSL Interception
A solution for resisting SSL interception without breaking
compatibility or requiring cooperation with third parties is needed.
The SSL/TLS protocol allows not only servers to authenticate
themselves using certificates, but clients as well. Client
certificates are widely popular in some government agencies and
countries, such as Estonia , but are not used by websites catering
to the general (US) public. Interestingly, client certificates allow
us to sidestep the interception problem.
First, enterprises have absolutely no control over the list of
trusted client certificate authorities present on third-party web
servers. Second, web servers can be set up to issue their own
certificates, rather than rely on a third party CA. Since an
interception device has no way to produce an acceptable client
certificate on its own, it can only obtain one by extracting the
certificate and key from an end user's device, or by subverting the
process used by a legitimate client to obtain a certificate in order
to frauduluently obtain one.
In fact, all web browsers include support for generating RSA key pairs
in order to facilitate the issuing of client certificates, and have
for many years. The HTML keygen tag causes the browser to
generate a key pair, retain the private key, and transfer the public
key to a server as part of a form submission. This tag is supported
by Chrome, Firefox, and Safari; Internet Explorer offers similar
functionality through the certificate enrollment control. After
receiving the public key, the server can generate a signed certificate
and return it to the browser. Then, the browser immediately adds the
certificate to its store of client certificates and allows it to be
used for authentication to the server.
How should the server verify a user's identity before issuing a
certificate? As in any PKI system, this is a difficult problem.
Since we are leveraging client certificate authentication only to
frustrate man-in-the-middle attacks, and not to truly verify a
client's identity, we could ignore this issue, and allow the server to
blindly sign any certificate requests that it receives. In fact, this
would be similar to the level of security provided by SSH: as long as
the very first connection to a server is not intercepted, a user would
receive and retain a valid certificate. The user would never again
need to go through the enrollment process unless the certificate were
deleted, the user moved to a different device, or the certificate
Instead, we have built a limited amount of identity verification into
our proposed solution. We simply have the server generate a 128-bit
enrollment key, and send it to the user through an out-of-band
channel. Then, as long as either the public key is encrypted with
this key before it is sent to the server, or the signed certificate is
encrypted with this key before it is returned to the client, a
man-in-the-middle cannot complete the enrollment process without
possessing the key. Thus, the man-in-the-middle must obtain the key
from the user, e.g. through phishing.
For Firefox and Safari, the solution works as follows:
- The user access the website in its original form,
e.g., mutual.securityevaluators.com, which does not require client authentication.
- The resulting page tests for the presence of a client certificate
by attempting to load an iframe from a mutually-authenticated server,
- If the iframe load succeeds, then the user must already have a
the user to the mutually-authenticated website.
- If the redirection has not occurred within a few seconds, then the
iframe load must have failed. Therefore, the user must not have a
certificate, and we begin the enrollment process.
- The user enters an e-mail address and CAPTCHA in order to receive
the out-of-band key.
- The keygen tag is used to generate a certificate request
and send it to the server.
- The server signs a certificate, encrypts it using the out-of-band
key, and returns the encrypted certificate back to the client.
uses it to decrypt and install the received certificate (entirely at
the client side).
- The user can then access the mutually-authenticated server.
The process for Chrome is similar, but as limitations in Chrome
prevent a certificate from being decrypted and then installed using
acknowledge that a MAC is a more correct solution for this purpose.
An example server implementing this solution is available at
Attribution and Acknowledgements
This research was conducted by Jacob Thompson
and directed by Stephen Bono.
Jarmoc, Jeff. SSL Interception Proxies and Transitive
Trust. Black Hat Europe 2012, Amsterdam, Netherlands.
Trustwave to escape 'death penalty' for SSL skeleton key
Trusted Root Signing Certificates
Enhancing digital certificate security
Further improving digital certificate security
DNS Hijacking - Manipulation by ISPS
UK government to activate adult content filters by default
Managing Encrypted Traffic
With Blue Coat Solutions
Mobile Workers: 'I Want My BlackBerry Back'
EFF SSL Observatory Map of CAs
Adventures in X.509: The Utterly Ignored nameConstraints
Analysis of the HTTPS Certificate Ecosystem
French gov used fake Google certificate to read its workers' traffic
The "Certificate Authority" Trust Model for SSL: A Defective Foundation for
Encrypted Web Traffic and a Legal Quagmire
DigiNotar Removal Follow Up
Revoking Trust in one ANSSI Certificate
blog, violations of CABF Baseline Requirements, any consequences?
Is This MITM Attack to Gmail's SSL? [sic]
Certificate Blacklisting in Jelly Bean
New Chromium security features, June 2011
Public Key Pinning
An update on attempted man-in-the-middle attacks
Practical Issues with TLS Client Certificate Authentication