Analyzing Forged SSL Certificates in the Wild

Lin-Shung Huang∗ , Alex Rice† , Erling Ellingsen† , Collin Jackson∗

∗ Carnegie Mellon University, {linshung.huang, collin.jackson}@sv.cmu.edu
† Facebook, {arice, erling}@fb.com

Abstract—The SSL man-in-the-middle attack uses forged SSL the attacker’s certificates were signed by trusted CAs, standard
certificates to intercept encrypted connections between clients browsers cannot simply distinguish the attacker’s intercepting
and servers. However, due to a lack of reliable indicators, it is server from the legitimate server (unless the forged certificate
still unclear how commonplace these attacks occur in the wild. In
this work, we have designed and implemented a method to detect is later revoked). Hypothetically [9], some governments may
the occurrence of SSL man-in-the-middle attack on a top global also compel CAs to issue trusted SSL certificates for spying
website, Facebook. Over 3 million real-world SSL connections purposes without the website’s consent.
to this website were analyzed. Our results indicate that 0.2% Furthermore, even if the attacker cannot obtain a trusted
of the SSL connections analyzed were tampered with forged certificate of legitimate websites, it is still possible to intercept
SSL certificates, most of them related to antivirus software and
corporate-scale content filters. We have also identified some SSL SSL connections against some users (that ignore browser secu-
connections intercepted by malware. Limitations of the method rity warnings). Historically, browsers tend to behave leniently
and possible defenses to such attacks are also discussed. when encountering errors during SSL certificate validation,
Keywords-SSL; certificates; man-in-the-middle attack; and still allow users to proceed over a potentially insecure
connection. One could argue that certificate warnings are
I. I NTRODUCTION mostly caused by server mis-configurations (e.g. certificate
Secure Socket Layer (SSL) [1], or its successor, Transport expirations) rather than real attacks, therefore browsers should
Layer Security (TLS) [2], is an encryption protocol designed let users determine whether they should dismiss the errors.
to provide secure communication and data transfers over the However, designing an effective security warning dialog has
Internet.1 SSL allows clients to authenticate the identity of been a challenging task for browser vendors. A number of
servers by verifying their X.509 [3] digital certificates, and usability studies [10], [11], [12], [13] have shown that many
reject connections if the server’s certificate is not issued by users actually ignore SSL certificate warnings. Note that
a trusted certificate authority (CA). SSL is most popular for users who incautiously ignore certificate warnings would be
enabling the encryption of HTTP traffic between websites vulnerable to the simplest SSL interception attacks (using self-
and browsers, but also widely used for other applications signed certificates).
such as instant messaging and email transfers. An SSL man- Despite that SSL man-in-the-middle attack attempts have
in-the-middle attack is an interception of such an encrypted previously been observed in the wild (e.g. in Iran [8] and
connection between a client and a server where the attacker Syria [14]), it is unclear how prevalent these attacks actually
impersonates the server through a forged SSL certificate — are. Several existing SSL surveys [4], [15], [16], [17] have
that is, an SSL certificate not provided or authorized by the collected large amounts of SSL certificates via scanning public
legitimate owner. We explain how this is possible below. websites or monitoring SSL traffic on institutional networks,
In practice, certificates issued through hundreds [4] of yet no significant data on forged SSL certificates have been
CAs are automatically trusted by modern browsers and client publicly available. We hypothesize that real attackers are
operating systems. Under the current X.509 public key in- more likely to perform only highly targeted attacks at certain
frastructure, every single CA has the ability to issue trusted geographical locations, or on a small number of high-value
certificates to any website on the Internet. Therefore, CAs must sessions, therefore, previous methodologies would not be able
ensure that trusted certificates are only issued to the legitimate to detect these attacks effectively.
owners of each website (by certifying the real identities of Unfortunately, detecting SSL man-in-the-middle attacks
their customers). However, if any of the trusted CAs suffers a from the website’s perspective, on a large and diverse set
security breach, then it is possible for attackers to obtain forged of clients, is not a trivial task. Since most users do not use
CA certificates for any desired website. In other words, a client certificates, servers cannot simply rely on SSL client
single CA failure would allow the attacker to intercept all SSL authentication to distinguish legitimate clients from attackers.
connections on the Internet. In fact, multiple commercial CAs Furthermore, there is currently no way for a web application
(DigiNotar [5], Comodo [6], and TURKTRUST [7]) have been to check the certificate validation status of the underlying SSL
found to mis-issue fraudulent certificates in the past. Some of connection, not even when an SSL error has occurred on the
these CA incidents actually resulted in real man-in-the-middle client. Also, it is currently not possible for web applications
attacks against high-profile websites such as Google [8]. Since to directly access the SSL handshake with native browser
networking APIs, like XMLHttpRequest and WebSockets, to
1 For brevity, we refer to SSL/TLS as SSL in this paper. validate SSL certificates on their own.
 In this paper, we first introduce a practical method for Browser HTTPS server
websites to detect SSL man-in-the-middle attacks in a large
scale, without alterations on the client’s end (e.g. custom
browsers). We utilized the widely-supported Flash Player
plugin to enable socket functionalities not natively present in ClientHello
current browsers, and implemented a partial SSL handshake
on our own to capture forged certificates. We deployed this ServerHello, Certificateserver, ServerHelloDone
detection mechanism on an Alexa top 10 website, Facebook,
ClientKeyExchange, ChangeCipherSpec, Finished
which terminates connections through a diverse set of network
operators across the world. We analyzed 3, 447, 719 real-world ChangeCipherSpec, Finished
SSL connections and successfully discovered at least 6, 845
(0.2%) of them were forged SSL certificates.
Our contributions can be summarized as follows:
• We designed a novel method for websites to collect Fig. 1. A basic SSL handshake with no client certificates
direct evidence of man-in-the-middle attacks against their
SSL connections. We further implemented this detection
method on Facebook’s website. the cipher algorithms and parameters to be used. Figure 1
• We conducted the first analysis on forged SSL certificates
depicts a basic SSL handshake using the RSA key exchange
by measuring over 3 million SSL connections. Our results with no client certificates. First, the client sends a ClientHello
show that 0.2% SSL connections are in fact tampered message to the server, which specifies a list of supported
with forged certificates. cipher suites and a client-generated random number. Second,
• Based real-world data, we categorized the root causes
the server responds with the ServerHello message which
of forged SSL certificates. We showed that most of contains the server-chosen cipher suite and a server-generated
the SSL interceptions are due to antivirus software and random number. In addition, the Certificate message contains
organization-scale content filters. the server’s public key and hostname, digitally signed by
• We provided evidence of SSL interceptions by malware,
a certificate authority, in which the client is responsible of
which have infected users across at least 45 countries. verifying. The client then encrypts the pre-master secret using
the server’s public key and sends the pre-master secret to the
The rest of this paper is organized as follows. Section II
server over a ClientKeyExchange message. Both the client
provides background information and surveys related work.
and server can hence derive the same session key from the
Section III details the design, implementation, and experimen-
pre-master secret and random numbers. Finally, the client
tation of our plugin-based detection method. Section IV gives
and server exchanges ChangeCipherSpec messages to notify
an analysis of the forged SSL certificates that were observed.
each other that subsequent application data within the current
Section V surveys possible mitigations. Section VI concludes.
session will be encrypted using the derived session key.
II. BACKGROUND As mentioned in Section I, the SSL protocol allows clients
In this section, we provide an overview of the SSL protocol, to authenticate the identity of servers by verifying their SSL
and how the SSL man-in-the-middle attack works. We then certificates. In practice, commercial SSL certificates are often
survey related work, and discuss existing tamper detection signed by intermediate CAs (a delegated certificate signer),
techniques that may be used by websites to detect network instead of directly signed by a trusted root CA (which are kept
interceptions. offline to reduce the risk of being compromised). Therefore,
the server’s Certificate message normally includes a chain
A. The SSL Protocol of certificates, consisting of one leaf certificate (to identify
The Secure Socket Layer (SSL) protocol was designed the server itself), and one or more intermediate certificates (to
to ensure secure communications between two entities over identify the intermediate CAs). Each certificate is cryptograph-
untrusted networks. The SSL protocol provides authentication ically signed by the entity of the next certificate in the chain,
based on the X.509 public key infrastructure, protects data and so on. A valid certificate chain must chain up to a root
confidentiality using symmetric encryption, and ensures data CA that is trusted by the client. Note that SSL certificates are
integrity with cryptographic message digests. SSL is com- by design transferred in plaintext since the integrity can be
monly used for securing websites and mail servers, preventing verified by signatures. It is critical that clients must validate
passive network attackers from eavesdropping or replaying the every certificate in the chain. In the following section, we will
client’s messages, and is generally considered security best explain why validating SSL server certificates is necessary.
practice for websites. By enabling encryption, websites can
easily prevent the eavesdropping of unencrypted confidential B. The SSL Man-in-the-Middle Attack
data (e.g. Firesheep [18]). The SSL man-in-the-middle (MITM) attack is a form of
To establish an SSL connection, the client and the server active network interception where the attacker inserts itself
performs a handshake to authenticate each other, and negotiate into the communication channel between the victim client and
 Browser Man-in-the-middle HTTPS server between them (decrypting messages from the client, and
then re-encrypting them before sending to the server).
Now, the attacker can read and even modify the en-
crypted messages between the client and the server.
ClientHello ClientHello As soon as the client accepts the forged SSL certificate, the
ServerHello ServerHello client’s secrets will be encrypted with the attacker’s public key,
Certificateattacker Certificateserver which can be decrypted by the attacker. Note that regardless of
ServerHelloDone ServerHelloDone whether the attacker’s forged certificate is issued by a trusted
ClientKeyExchange ClientKeyExchange CA, the attack steps are the same. If one of the client’s trusted
ChangeCipherSpec ChangeCipherSpec CAs went rogue or was otherwise coerced [9] into issuing
Finished Finished a certificate for the attacker, the browser will automatically
ChangeCipherSpec ChangeCipherSpec accept the forged certificate. In fact, professional attackers
Finished Finished have proven capable of compromising CAs themselves in
order to obtain valid certificates, as has occurred during the
Encryptattacker(data) Encryptattacker(data)
security breaches of DigiNotar [5] and Comodo [6]. Moreover,
even if the attacker does not have a trusted certificate of the
victim server and uses a self-signed certificate, researchers
have shown that many users ignore SSL certificate warnings
Fig. 2. An SSL man-in-the-middle attack between the browser and the server,
using a forged SSL certificate to impersonate as the server to the client. presented by the browser [11]. Even worse, studies have
discovered that some non-browser software and native mobile
applications actually contain faulty SSL certificate validation
the server (typically for the purpose of eavesdropping or ma- code, which silently accepts invalid certificates [20], [21], [22].
nipulating private communications). The attacker establishes Lastly, numerous automated tools that can mount SSL man-
two separate SSL connections with the client and the server, in-the-middle attacks are publicly available on the Internet
and relays messages between them, in a way such that both the (e.g. sslsniff [23]), which greatly reduce the level of technical
client and the server are unaware of the middleman. This setup sophistication necessary to mount such attacks.
enables the attacker to record all messages on the wire, and C. Certificate Observatories
even selectively modify the transmitted data. Figure 2 depicts
A number of SSL server surveys [4], [15], [16], [17] have
an SSL man-in-the-middle attack with a forged certificate
analyzed SSL certificates and certificate authorities on the
mounted between a browser and a HTTPS server. We describe
Internet. The EFF SSL Observatory [4] analyzed over 1.3
the basic steps of a generic SSL man-in-the-middle attack as
million unique SSL certificates by scanning the entire IPv4
follows:
space, and indicated that 1,482 trusted certificate signers are
1) The attacker first inserts itself into the transport path being used. Similarly, Durumeric et al. [17] collected over
between the client and the server, for example, by 42 million unique certificates by scanning 109 million hosts,
setting up a malicious WiFi hotspot. Even on otherwise and identified 1,832 trusted certificate signers. Holz et al. [15]
trusted networks, a local network attacker may often analyzed SSL certificates by passively monitoring live SSL
successfully re-route all of the client’s traffic to itself traffic on a research network in addition to actively scanning
using exploits like ARP poisoning, DNS spoofing, BGP popular websites, and found that over 40% certificates ob-
hijacking, etc. The attacker could also possibly configure served were invalid due to expiration, incorrect host names, or
itself as the client’s proxy server by exploiting auto- other reasons. Akhawe et al. [16] analyzed SSL certificates by
configuration protocols (PAC/WPAD) [19]. At this point, monitoring live user traffic at several institutional networks,
the attacker has gained control over the client’s traffic, and provided a categorization of common certificate warn-
and acts as a relay server between the client and the ings, including server mis-configurations and browser design
server. decisions. However, existing studies do not provide insights
2) When the attacker detects an SSL ClientHello message on forged certificates, probably since network attackers are
being sent from the client, the attacker accurately deter- relatively rare on those research institutional networks. In our
mines that the client is initiating an SSL connection. The work, we set out to measure real-world SSL connections from
attacker begins the impersonation of the victim server a large and diverse set of clients, in an attempt to find forged
and establishes an SSL connection with the client. Note SSL certificates.
that the attacker uses a forged SSL certificate during its
SSL handshake with the client. D. Tamper Detection Techniques for WebSites
3) In parallel to the previous step, the attacker creates Several techniques have been proposed to assist websites
a separate SSL connection to the legitimate server, in detecting whether the client’s network connections has
impersonating the client. Once both SSL connections are been tampered with. In this paper, we focus on detection
established, the attacker relays all encrypted messages methods that do not require user interaction, and do not require
the installation of additional software or browser extensions. III. SSL TAMPER D ETECTION M ETHOD
Notably, Web Tripwires [24] uses client-side JavaScript code In Section II-D, we discussed a number of existing tech-
to detect in-flight modifications to a web page. Several other niques for websites to detect network tampering. However,
studies [25], [26], [27], [28] have utilized Java applets to probe none of the current methods (without browser modifications)
the client’s network configurations and detect proxies that are are effective in detecting SSL man-in-the-middle attacks. In
altering the client’s traffic. this section, we present a new method for detecting SSL
man-in-the-middle attacks from the website’s end. First, we
• Web Tripwires. Web Tripwires [24] was a technique describe our threat model. We then detail the design and our
proposed to ensure data integrity of web pages, as an implementation of the detection method on the Facebook web-
alternative to HTTPS. Websites can deploy JavaScript site. Lastly, we present our findings from analyzing millions
to the client’s browser that detects modifications on of real-world SSL connections.
web pages during transmission. In their study of real-
world clients, over 1% of 50, 000 unique IP addresses A. Threat Model
observed altered web pages. Roughly 70% of the page We primarily consider an active network attacker who has
modifications were caused by user-installed software that control over the victim’s network connection. However, the
injected unwanted JavaScript into web pages. They found attacker does not have control over the website (such as
that some ISPs and enterprise firewalls were also injecting accessing internal machines and stealing the server’s private
ads into web pages, or benignly adding compression to key). The goal of the adversary is to read encrypted messages
the traffic. Interestingly, they spotted three instances of between the victim client and the HTTPS website. The attacker
client-side malware that modified their web pages. Web may impersonate the legitimate website with either (1) a
Tripwires was mainly designed to detect modifications to trusted certificate issued by a trusted CA, or (2) an untrusted
unencrypted web traffic. By design, Web Tripwires does certificate (e.g. a self-signed certificate). In the case of an
not detect passive eavesdropping (that does not modify untrusted certificate, we assume that users may still be vulner-
any page content), nor does it detect SSL man-in-the- able, since previous studies [11], [12] have shown that many
middle attacks. In comparison, our goal is to be able to users ignore browser security warnings. Users are assumed to
detect eavesdropping on encrypted SSL connections. use up-to-date browsers (with no SSL implementation bugs).
• Content Security Policy. Content Security Policy In addition, we will discuss separately another type of
(CSP) [29] enables websites to restrict browsers to load local attacker, where the attacker may be a piece of software
page content, like scripts and stylesheets, only from a running on the client with the ability to modify the client’s
server-specified list of trusted sources. In addition, web- trusted CA store, as well as manipulate network connections.
sites can instruct browsers to report CSP violations back Such local attackers are much stronger than active network
to the server with the report-uri directive. Interest- attackers, and are naturally not in scope of the SSL protocol’s
ingly, CSP may detect untrusted scripts that are injected protection.
into the protected page, and report them to websites. Like
Web Tripwires, CSP does not detect eavesdropping on B. Design
SSL connections. There are several obstacles for websites to detect whether
• Browser Plugins. Another technique for websites to any SSL man-in-the-middle attacks are mounted against their
diagnose the client’s network is by using browser plugins, connections. First of all, since SSL client certificates are rarely
such as Java and Flash Player. Browser plugins may sent by normal users, it is not possible to distinguish a legit-
provide more network capabilities than JavaScript, in- imate client from an attacker directly via the SSL handshake
cluding the ability to open raw network sockets and even from the server’s perspective. In order to determine whether
perform DNS requests. For instance, the Illuminati [25] an SSL connection is being intercepted, our fundamental
project used Java applets to identify whether clients were approach is to observe the server’s certificate from the client’s
connecting through proxies or NAT devices. Jackson et perspective. Intuitively, if the client actually received a server
al. conducted studies using both Java and Flash Player certificate that does not exactly match the website’s legitimate
on real-world clients to find web proxy vulnerabilities, certificate, we would have direct evidence that the client’s
including multi-pin DNS rebinding [26] and cache poi- connection must have been tampered with.
soning [27]. The ICSI Netalyzer [28] used a signed Java Although one could easily develop a binary executable file
applet to perform extensive tests on the client’s network or a custom browser extension that probes SSL certificates as
connectivity, such as detecting DNS manipulations. an SSL client, it would not be scalable to distribute additional
software to a large number of normal users, especially for
In our work, we focused on detecting SSL man-in-the- non-tech-savvy users. Ideally, we would like to develop a
middle attacks in real-world, from a website’s perspective, JavaScript code snippet to observe SSL certificates, which
without modifications to current browsers. Other proposals to runs in existing browsers and can reach a large population of
prevent or mitigate SSL interception will be later discussed in clients. However, there are currently no existing browser APIs
Section V. that allows web applications to directly check the observed
 Browser HTTPS server order for a SWF applet from example.com to open a socket
connection to a HTTPS server example.com on port 443, a
valid socket policy file must be served at example.com on
port 843, which permits socket access from example.com
Request HTML applications to port 443, as follows (in XML format):
<?xml version="1.0"?>
<html>… <object src="applet.swf"></object> … <!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
Request applet.swf <cross-domain-policy>
<allow-access-from domain="example.com" to-ports="443" />
</cross-domain-policy>
applet.swf
Note that the socket policy file should not be confused with
Flash Player
the crossdomain.xml file served by web servers, which
restricts access to HTTP, HTTPS, and FTP access, but not
socket access. If the Flash Player cannot successfully retrieve
Port 843 a valid socket policy (e.g. blocked by a firewall), the socket
<policy-file-request />
connection will be aborted and an exception will be thrown.
<cross-domain-policy>...</cross-domain-policy>
Once the socket connection is permitted, our applet will
Port 443 initiate an SSL handshake by sending a ClientHello message
ClientHello
over the socket, and wait for the server to respond with
ServerHello, Certificateattacker… the ServerHello and Certificate messages, which will be
recorded. To support clients behind explicit HTTP proxies,
Log Certificateattacker the applet may send a CONNECT request over the socket to
create an SSL tunnel prior to sending the ClientHello message,
as follows:
Fig. 3. The website loads a client-side applet, that performs the SSL CONNECT example.com:443 HTTP/1.1
handshake over a Flash-based socket connection to observe SSL certificates.
Our SSL handshake implementation was based on the SSL
3.0 protocol version. Since our goal to observe the server’s
server certificate or validation status of their SSL connections. certificate chain, our applet closes the socket connection
To workaround this, we utilized browser plugins to implement after successfully receiving the certificate chain. Lastly, our
a client-side applet that is capable of imitating the browser’s applet converts the raw bytes of the recorded SSL handshake
SSL handshake, accompanied with the ability to report the responses into an encoded string, and sends it back to our log
observed certificate chain. The applet can open a socket con- server with a POST request.
nection to the HTTPS server (skipping the browser’s network We note that the Flash Player plugin is currently supported
stack), perform an SSL handshake over the socket, record on 95% of web browsers [31], therefore, our applet should
the SSL handshake, and report the certificate chain back to be able to run on most clients. In fact, one of the major
our logging servers, shown in Figure 3. We describe our browsers, Google Chrome, has the Flash Player plugin built
implementation details below. in by default. Also, SWF applets are usually allowed to
1) Client-Side Applet: Our approach is to use a client- execute without any additional user confirmation, and do not
side applet that observes the server’s SSL certificate from trigger any visual indicators (e.g. system tray icons) while
the client’s perspective, directly during the SSL handshake. running, thus, deploying this method should not affect the
Since native browser networking APIs like XMLHttpRequest visual appearance of the original web page.
and WebSockets do not provide web applications access to Alternatively, the client-side applet may be implemented
raw bytes of socket connections, we must utilize browser using other browser plugins, for example, the Java plugin.
plugins. We implemented a Shockwave Flash (SWF) applet Java applets are allowed to create socket connections from
that can open a raw socket connection to its own HTTPS server the client to any port on the same host that the applet was
(typically on port 443), and perform an SSL handshake over served from. As an example, an applet served from port
the connection in the Flash Player. 80 on example.com can open a raw socket to port 443
By default, the Flash Player plugin does not allow any on example.com without requesting any additional access.
applets to access socket connections, unless the remote host However, due to security concerns, the Java plugin is currently
runs a Flash socket policy server [30]. The Flash socket policy blocked by default on several client platforms, and may require
server, normally running on port 843, serves a socket policy additional user interaction to activate the Java plugin. Such
file that declares whether SWF applications may open socket user interaction would be too obtrusive for our experiment
connections to the server. Note that even if a SWF file is and client diversity suffers greatly once all potential interactive
requesting a socket connection to the same host it was served platforms are removed from the experiment. Another side
from, a socket policy server is still required. As a result, in effect of running a Java applet on some platforms is that a
  EURZVHUKWPO

visible icon would be displayed in the system tray, which 

&KURPH
might annoy or confuse some of the website’s users.
)LUHIR[
2) Lenient Certificate Extraction: Since we implemented 
,QWHUQHW([SORUHU
the SSL handshake process on our own, we must extract 
6DIDUL
the SSL certificates from a raw byte dump of the SSL 2SHUD
handshake observed on the client, by parsing the Server-  2WKHU
Hello and ServerCertificate messages. Surprisingly, in our
initial attempts, we found that this seemingly straightforward
extraction process failed occasionally. By manual inspection, Fig. 4. Browser usage share of sampled clients. Note that given our sampling
we noticed that some of the recorded SSL messages were parameters, this is not directly representative of the entire population of
Facebook’s website.
slightly different from the SSL/TLS standards. As a result,
we intentionally parsed the SSL handshake in as lenient a TABLE I
manner as possible in order to extract certificates even if the N UMBER OF CLIENTS THAT COMPLETED EACH STEP OF THE DETECTION
PROCEDURE
SSL message format did not conform exactly to the standards.
We did not discard these malformed handshakes as we theorize
that they are caused by either transmission errors or software Procedure Count
errors in the intercepting proxy. 1. Inserted HTML object tag into web page 9, 179, 453
Websites may choose to perform certificate extraction on- 2. Downloaded SWF file from server 6, 908, 675
the-fly in the client-side applet, or simply send the handshake 3. Sent report to logging server 5, 415, 689
raw bytes to their log servers for post-processing. We took
the latter approach, since it enabled us to preserve the SSL
handshake bytes for further investigation, even if early versions
SSL certificates were processed and read using the OpenSSL
of our extraction code failed (or even crashed unexpectedly)
library. In addition, we built an internal web interface for
while parsing certificates.
querying the log reports.
C. Implementation
D. Experimentation
We have implemented our client-side applets for both the
Using the Flash-based detection method, we conducted the
Flash Player and Java plugins. With similar functionality,
first large-scale experiment in an attempt to catch forged SSL
the SWF file (2.1 KB) was slightly smaller than the Java
certificates in the wild. We served our client-side applet to
applet (2.5 KB). Since Flash Player was supported on a larger ILOHORFDOKRVW8VHUVOLQVKXQJKXDQJ'URSER[/D7H;IEBPLWPEURZVHUKWPO 
a set of randomly sampled clients on Facebook’s website.
client population and is considered less obtrusive to users, we
We collected and analyzed data from November 20, 2012 to
deployed the SWF file for our experiments.
March 31, 2013.2 Our dataset consists of reports from a variety
To observe SSL connections on a large set of real-world
of browsers, shown in Figure 4. The most popular browser
clients, we deployed our client-side applet on Facebook’s
versions in our dataset were (in descending order) Chrome
servers to run our experiments. We sampled a small portion
23, Chrome 24, Internet Explorer 9, Chrome 25, and Firefox
(much less than 1%) of the total connections on Facebook’s
18.
desktop website, particularly on the www.facebook.com
First of all, we noticed that only a portion of the sampled
domain. To avoid affecting the loading time of the website’s
clients actually completed our detection procedure, explained
original web pages, our applets are programmed to load several
below. As shown in Table I, a total of 9, 179, 453 page
seconds after the original page has completed loading. This is
views on Facebook’s desktop website had our HTML object
done by using a JavaScript snippet that dynamically inserts a
tag dynamically inserted. Our web servers logged 6, 908, 675
HTML object tag that loads the SWF file into the web page
actual downloads for the SWF file. The download count for
visited by the user. Basically, the script is triggered only after
the SWF file was noticeably lower than the number of object
the original page finishes loading, and further waits a few
tags inserted. We reason that this is possibly due to: (1) the
seconds, before actually inserting the applet. Additionally, we
Flash Player plugin was not enabled on the client, (2) a few
built server-side mechanisms to allow granular control over
legacy browsers did not support our SWF object embedding
the sampling rates in specific countries or networks. This
method, or (3) the user navigated away from the web page
granularity enables us to increase the sampling rate for certain
before the object tag was loaded. Our log servers received
populations in response to the detection of a specific attack.
a total of 5, 415, 689 reports from applets upon successful
To support Flash-based socket connections used by our SWF
execution. Again, the number of received reports is lower than
files, we have set up Flash socket policy servers that listens on
the number of SWF file downloads. This is likely due to the
port 843 of the website, which are configured with a socket
web page being closed or navigated away by the user, before
policy file that allows only its own applets to open socket
the applet was able to finish execution.
connections to port 443. We also setup a logging endpoint
on the HTTPS servers, in PHP, that parses the reports, and 2 Personally identifiable information (IP addresses and HTTP cookies) were
aggregates data into our back-end databases. The extracted removed from our database after a 90-day retention period.
 TABLE II
C ATEGORIZATION OF REPORTS however we have no evidence that these false POST requests
were intentional.
Finally, we successfully extracted 3, 447, 719 (64%) well-
Type Count
formed certificates from the logged reports. We used custom
Well-formed certificates 3, 447, 719 (64%) scripts (mentioned in Section III-B2) to parse the recorded
Flash socket errors 1, 965, 186 (36%) SSL handshake bytes. A total of 3, 440, 874 (99.8%) out of
Empty reports 2, 398 (0%) 3, 447, 719 observed certificates were confirmed to be the
Bogus reports 290 (0%) website’s legitimate SSL certificates, by checking the RSA
HTTP responses 96 (0%) public keys (or more strictly, by comparing the observed
certificate bit-by-bit with its legitimate certificates). We note
that there were multiple SSL certificates (thus, multiple RSA
public keys) legitimately used by Facebook’s SSL servers
Next, we noticed that only 64% out of the 5, 415, 689 re- during the period of our study, issued by publicly-trusted
ceived reports contained complete and well-formed certificate commercial CAs including VeriSign, DigiCert, and Equifax.
records, as shown in Table II. We observed that 1, 965, 186 Most interestingly, we discovered that 6, 845 (0.2%) of the
(36%) of the reported data indicated that the client caught observed certificates were not legitimate, nor were they in
SecurityErrorEvent or IOErrorEvent exceptions in the Flash any way approved by Facebook. We further examine these
Player and failed to open a raw socket. We believe that most captured forged certificates in Section IV.
of these errors were caused by firewalls blocking the socket
policy request (for example, whitelisting TCP ports 80 and 443 E. Limitations
to only allow web traffic), thus not allowing the Flash Player to Before we move on, we offer insights on the limitations
retrieve a valid socket policy file from our socket policy servers of our detection method. It is important to point out that the
(over port 843). For clients behind these firewalls, we were not goal of our implementation was not to evade the SSL man-in-
able to open socket connections using Flash Player, although the-middle attacks with our detection mechanism. Admittedly,
using Java might have worked in some legacy client platforms. it would be difficult to prevent professional attackers that are
We discuss in Section III-E that similar measurements can be fully aware of our detection method. We list below some ways
conducted on native mobile platforms to avoid the drawbacks that an attacker might adaptively evade our detection:
of Flash sockets. • Attackers may corrupt all SWF files in transmission, to
In addition to the Flash socket errors, we also observed a prevent our client-side applet from loading. However, this
few other types of erroneous reports. There were 2, 398 reports approach would cause many legitimate applications using
that were empty, indicating that the SWF file failed to receive SWF files to break. Of course, the attacker could narrow
any certificates during the SSL handshake. This might have the scope of SWF blacklisting to include only the specific
been caused by firewalls that blocked SSL traffic (port 443). SWF files used in this detection. In response, websites
There were 96 reports that received HTTP responses during may consider randomizing the locations of their SWF
the SSL handshake, mostly consisting of error pages (HTTP files.
400 code) or redirection pages (HTTP 302 code). These • Attackers may restrict Flash-based sockets by blocking
responses suggest that some intercepting proxies contained Flash socket policy traffic on port 843. To counter this,
logic that were modifying the client’s web traffic to block websites could possibly serve socket policy files over
access to certain websites (or force redirection to certain web firewall-friendly ports (80 or 443), by multiplexing web
pages, known as captive portals). We found that some clients traffic and socket policy requests on their servers. In
received a HTML page in plaintext over port 443, for instance, addition, websites could try falling back to Java applets
linking to the payment center of Smart Bro, a Philippine on supporting clients if Flash-based sockets are blocked.
wireless service provider. These type of proxies do not appear • Attackers may try to avoid intercepting SSL connections
to eavesdrop SSL traffic, but they inject unencrypted HTTP made by the Flash Player. However, the website may
responses into the client’s web traffic. tailor its client-side applet to act similarly to a standard
In addition, there were 290 reports that contained garbled browser.
bytes that could not be correctly parsed by our scripts. Al- • In theory, attackers could possibly tamper the reports
though we could not successfully parse these reports, manual (assuming that the measured client was under an SSL
inspection determined that 16 of the reports contained seem- man-in-the-middle attack, and probably clicked through
ingly legitimate VeriSign certificates that had been truncated in SSL warnings, if any), and trick our log servers to believe
transit, presumably due to lost network connectivity. Another that the website’s legitimate certificate was observed.
37 of these reports appear to be issued by Kurupira.NET, a Under this scenario, the website may need additional
web filter, which closed our SSL connections prematurely. mechanisms to verify the integrity of their reports.
We also found that 17 of the unrecognized POST requests At the time of this study, there is no reason to think that
on our log servers were sent from a Chrome extension called any attacker is tampering our reports, or even aware of our
Tapatalk Notifier (determined by the HTTP origin header), detection method. We do not consider attackers that have
 TABLE III TABLE IV
F ORGED CERTIFICATE CHAIN SIZES F ORGED CERTIFICATE CHAIN DEPTHS

Size (bytes) Count Depth Count

0 - 1000 6,154 (90%) 1 6,173 (90%)

1000 - 2000 508 (7%) 2 617 (9%)
2000 - 3000 140 (2%) 3 19 (0%)
3000 - 4000 29 (0%) 4 34 (0%)
4000 - 5000 2 (0%) 5 2 (0%)
5000 - 6000 23 (0%)
6000 - 7000 13 (0%) TABLE V
P UBLIC KEY SIZES OF FORGED SERVER CERTIFICATES

Public Key Size (bits) Count

obtained access to Facebook’s internal servers. As shown
512 119 (2%)
in Section III-D, our current methodology has successfully
1024 3,447 (50%)
captured direct evidences of unauthorized SSL interceptions in
2048 3,279 (48%)
the wild. However, if more websites become more aggressive
about this sort of monitoring, we might get into an arms race,
unfortunately.
Fortunately, many popular websites nowadays have the op- that did not include any intermediate CA certificates (thus
tion to leverage their native mobile applications for detecting the smaller chain size). A small number of certificate
attacks. While our initial implementation targeted desktop chains were larger than 5 KB in size, where the size
browsers, we suggest that similar mechanisms can be im- overhead might have a negative impact on page load time
plemented, more robustly, on mobile platforms such as iOS for victim users.
and Android.3 Native mobile applications have the advantage • Certificate chain depths. Table IV shows the distribution
of opening socket connections without Flash-based socket of certificate chain length. Here, we refer to the certificate
policy checks, and are more difficult for network attackers chain depth as the number of certificates (including any
to bypass (since the Flash applet is no longer necessary, and intermediate CA certificates) actually transmitted during
native applications can be programmed to act exactly like the SSL handshake. We note that on most websites, the
a standard browser). Furthermore, mobile clients can also certificate chains normally do not include the issuing root
implement additional defenses (e.g. certificate pinning [22]) CA certificate (since trusted CA certificates are presumed
to harden itself against SSL man-in-the-middle attacks (e.g. to be installed on the client, thus omitted in transmission).
preventing the tampering of reports), while performing similar The majority of the forged certificate chains have a
measurement experiments. depth of one, which only contained the server’s end
entity certificate without any intermediate certificates.
IV. A NALYSIS OF F ORGED SSL C ERTIFICATES Since most commercial CAs nowadays issue certificates
From the experiments in Section III-D, we collected 6, 845 using intermediate keys (rather than their root keys), one
forged certificates from real-world clients connecting to Face- should probably raise some suspicion when encountering
book’s SSL servers. In this section, we analyze the root cause certificate chains with a depth of one. There were 55 of
of these injected forged SSL certificates. First, we survey the the forged certificates that had a depth of 3 or larger,
characteristics of the forged certificate chains, including the which is actually longer than the website’s legitimate
certificate chain sizes, certificate chain depths, and public key certificate chain. For these certificate chains, additional
sizes. Subsequently, we examine the subject names and the cryptographic computations or even online revocation
issuer names of the forged certificates. checks on the client might be required, since the client
needs to verify signatures for all of the intermediate
A. Size Characteristics certificates when establishing an SSL connection. On
We first examine the size characteristics of the forged SSL slower devices, the additional verification time might be
certificates, as follows: noticeable by the victim user.
• Public key sizes. Table V shows the RSA public key sizes
• Certificate chain sizes. Table III summarizes the total
in bits carried in the forged certificates. Most of the forged
sizes in bytes of the forged certificate chains. Notably,
certificates had either 1024-bit or 2048-bit public keys,
most of the forged certificate chains were actually very
which are not characteristically different from legitimate
small (less than a kilobyte). By manual inspection, these
SSL certificates (although websites should transition to
small certificates were generally self-signed certificates
2048-bit or stronger RSA keys by 2014 according to the
3 After our initial study, Facebook has implemented our methodology across CA/Browser forum’s recommendations). We noticed that
their native mobile applications. a few certificates actually contained relatively weak 512-
 TABLE VI
S UBJECT ORGANIZATIONS OF FORGED CERTIFICATES that a number of forged certificates used a subject name that
starts with two characters FG concatenated with a long numeric
string (e.g. FG600B3909600500). These certificates were
Subject Organization Count
issued by Fortinet Ltd., a company that manufactures SSL
Facebook, Inc. 6,552 proxy devices which offer man-in-the-middle SSL inspection.
Empty 131 Similarly, we found 8 certificates that had a subject common
Fortinet Ltd. / Fortinet 93 name “labris.security.gateway SSL Filtering Proxy,” which is
Lousville Free Public Library 10 also an SSL proxy device. There were a few other common
Other 59 names observed that were likely amateur attempts of SSL
interception, such as localhost.localdomain, which
TABLE VII is the default common name when generating a self-signed
S UBJECT COMMON NAMES OF FORGED CERTIFICATES
certificate using the OpenSSL library.
For the forged SSL certificates that did not use a subject
Subject Common Name Count common name with facebook.com as suffix, we also
*.facebook.com 6,491 checked if any subject alternative names were present in the
www.facebook.com 117 certificate. Subject alternative names are treated as additional
pixel.facebook.com 1 subject names, and allow certificates to be shared across
m.facebook.com 1 multiple distinct hostnames. This may allow attackers to gen-
facebook.com 1 erate a single forged certificate for attacking multiple different
* 1 websites. For the 233 forged certificates that did not provide a
IP addresses 118 matching common name, none of them provided a matching
FG... / Fortinet / FortiClient 93 subject alternative name. Even though these 233 (3.4%) forged
Other 22 certificates would definitely trigger name mismatch errors,
there is still a significant possibility that users may ignore
the browser’s security warnings anyway.
bit public keys. These users may have become further C. Certificate Issuers
vulnerable to a second attacker given the considerably
In this section, we examine the issuer organizations and is-
weakened public key.
suer common names of each forged SSL certificate. Table VIII
B. Certificate Subjects lists the top issuer organizations of the forged certificates.
First, Table VI shows the subject organizations of forged At first glance, we noticed several forged certificates that
certificates. As expected, the majority of them spoofed the fraudulently specified legitimate organizations as the issuer,
organization as Facebook. There were over a hundred forged including 5 using Facebook, 4 using Thawte, and one using
certificates that excluded the organization attribute entirely. VeriSign. These invalid certificates were not actually issued
Again, we confirmed 93 certificates that were attributed to by the legitimate companies or CAs, and were clearly mali-
Fortinet Ltd. cious attempts of SSL interception. Since 166 of the forged
Next, we inspect the observed subject common names of the certificates did not specify its issuer organization (or empty),
forged SSL certificates, summarized in Table VII. Normally, we also checked the issuer common names, listed in Table IX.
the subject common name of the SSL certificate should match We manually categorized the certificate issuers of forged
the hostname of the website to avoid triggering SSL certificate certificates into antivirus, firewalls, parental control software,
warnings in the browser. While most of the forged certificates adware, and malware. Notably, we observed an intriguing
used the legitimate website’s domains as the subject common issuer named IopFailZeroAccessCreate that turned out to
name, there were a few certificates that used unrelated domains be produced by malware, which we discuss in detail below.
as well. • Antivirus. By far the top occurring issuer was Bitde-
Unsurprisingly, most of the forged SSL certificates used the fender with 2, 682 certificates, an antivirus software prod-
wildcard domain *.facebook.com as the subject common uct which featured a “Scan SSL” option for decrypting
name in order to avoid certificate name validation errors. SSL traffic. According to their product description, Bit-
This suggests that most of the attacking entities were either defender scans SSL traffic for the presence of malware,
specifically targeting Facebook’s website by pre-generating phishing, and spam. The second most common issuer was
certificates that match the website’s name, or using automated ESET with 1, 722 certificates, another antivirus software
tools to generate the certificates on-the-fly. None of the forged product that provides SSL decryption capabilities for
certificates were straight clones of Facebook’s legitimate cer- similar purposes. Several other top issuers were also ven-
tificates (that replicated all the X.509 extension fields and dors of antivirus software, such as BullGuard, Kaspersky
values). There were some certificates that used IP addresses as Lab, Nordnet, DefenderPro, etc. These software could
common name, for example, 69.171.255.255 (which ap- possibly avoid triggering the browser’s security errors by
pears to be one of Facebook’s server IP addresses). We noticed installing their self-signed root certificates into the client’s
 TABLE VIII TABLE IX
I SSUER ORGANIZATIONS OF FORGED CERTIFICATES I SSUER COMMON NAMES OF FORGED CERTIFICATES

Issuer Organization Count Issuer Common Name Count

Bitdefender 2,682 Bitdefender Personal CA.Net-Defender 2,670
ESET, spol. s r. o. 1,722 ESET SSL Filter CA 1,715
BullGuard Ltd. 819 BullGuard SSL Proxy CA 819
Kaspersky Lab ZAO / Kaspersky Lab 415 Kaspersky Anti-Virus Personal Root Certificate 392
Sendori, Inc 330 Sendori, Inc 330
Empty 166 IopFailZeroAccessCreate 112
Fortinet Ltd. / Fortinet 98 ...
EasyTech 78 * .facebook.com 6
NetSpark 55 VeriSign Class 4 Public Primary CA 5
Elitecore 50 Production Security Services 3
ContentWatch, Inc 48 Facebook 1
Kurupira.NET 36 thawte Extended Validation SSL CA 1
Netbox Blue / Netbox Blue Pty Ltd 25 Other (252) 794
Qustodio 21
Nordnet 20
Target Corporation 18 devices for web content filtering with support for HTTPS
DefenderPro 16 deep inspection. NetSpark was another web content fil-
ParentsOnPatrol 14 tering device manufacturer offering similar capabilities.
Central Montcalm Public Schools 13 According to their product description, the user’s content
TVA 11 is unencrypted for inspection on NetSpark’s servers, and
Louisville Free Public Library 10 then re-encrypted under NetSpark’s SSL certificate for
Facebook, Inc. 5 the end user. We observed a number of device vendors
thawte, Inc. 4 that provided similar devices, such as EliteCore, Con-
Oneida Nation / Oneida Tribe of WI 2 tentWatch, and Netbox Blue. There were also software
VeriSign Trust Network 1 solutions that provided selective website blocking, such
Other (104) 186 as Kurupira.NET. Some appliance vendors aggressively
marketed SSL content inspection as a feature which can-
not be bypassed by users. For example, ContentWatch’s
system. Note that the observed antivirus-related certificate website provided the following product description for
counts are not representative of the general antivirus their firewall devices:4
usage share of the website’s users, since SSL interception “This technology also ensures the users cannot by-
is often an optional feature in these products. However, pass the filtering using encrypted web traffic, remote
if any antivirus software enabled SSL interception by proxy servers or many of the other common methods
default, we would expect a higher number of their forged used circumvent content filters.”
certificates observed.
Interestingly, EliteCore’s Cyberoam appliances have pre-
Supposing that these users intentionally installed the an- viously been discovered [32] to be using the same CA
tivirus software on their hosts, and deliberately turned on private key across all Cyberoam devices. This is partic-
SSL scanning, then these antivirus-generated certificates ularly dangerous, since the universal CA private key can
would be less alarming. However, one should be wary of be extracted from any single device by an attacker. This
professional attackers that might be capable of stealing vulnerabilitiy allows an attacker to seamlessly perform
the private key of the signing certificate from antivirus SSL man-in-the-middle attacks against users of benign
vendors, which may essentially allow them to spy on the Cyberoam devices, because the attacker can issue forged
antivirus’ users (since the antivirus’ root certificate would server certificates that will be accepted by other clients
be trusted by the client). Hypothetically, governments that have installed Cyberoam’s CA certificate. Reportedly,
could also compel antivirus vendors to hand over their Cyberoam issued an over-the-air patch to generate unique
signing keys. CA certificates on each device. Nevertheless, we should
• Firewalls. The second most popular category of forged be aware that other device manufacturers are likely to
certificates belongs to commercial network security appli- introduce similar security vulnerabilities.
ances that perform web content filtering or virus scanning • Adware. We observed 330 instances of forged certificates
on SSL traffic. As observed in the certificate subject
fields, Fortinet was one of the issuers that manufactures 4 http://www.contentwatch.com/solutions/industry/government
 issued by a company named Sendori. This company of-
fers a browser add-on that claims to automatically correct
misspelled web pages. However, using Google Search to
query the string “Sendori” revealed alarming discussions
about the add-on actually hijacking DNS entries for
the purposes of inserting advertisements into unrelated
websites.5 This form of adware actively injects content
into webpages, and could possibly be detected using Web
Tripwires or CSP (as described in Section II-D).
• Malware. As previously mentioned, we noticed that
an unknown issuer named IopFailZeroAccessCreate
appeared relatively frequently in our dataset. We man-
ually searched the name on the Internet and noticed
that multiple users were seeing SSL certificate errors
of the same issuer, and some were suggesting that the  
user could be under SSL man-in-the-middle attacks by
Fig. 5. Geographic distribution of forged SSL certificates generated by the
malware.6 Upon deeper investigation, we discovered 5 malicious issuer IopFailZeroAccessCreate
forged certificates that shared the same subject public
key as IopFailZeroAccessCreate, yet were generated
with their issuer attribute set as “VeriSign Class 4 Public In addition, there were 4 other suspicious certificates
Primary CA.” We confirmed with Symantec/VeriSign that issued under the organization name of thawte, Inc with
these suspicious certificates were not issued through their three of them using “Production Security Services” as
signing keys. This was obviously a malicious attempt the issuer common name, and one using “thawte Ex-
to create a certificate with an issuer name of a trusted tended Validation SSL CA.” These instances could be
CA. These variants provide clear evidence that attackers the same malware attack previously spotted by some
in the wild are generating certificates with forged issuer Opera users [33], in which forged certificates pretending
attributes, and even increased their sophistication during to be issued by Thwate were observed. These 4 forged
the time frame of our study. certificates were observed in Italy, Spain, and the United
States.
In Figure 5, we illustrate the geographic distribution
of the certificates issued by IopFailZeroAccessCreate We note that a sophisticated attacker utilizing malware
(and the forged “VeriSign Class 4 Public Primary CA”) could install their self-signed CA certificates on clients
on a world map. As shown, the infected clients were in order to suppress browser security errors. Such an
widespread across 45 different countries. The countries attacker is likely capable of stealing confidential infor-
with the highest number of occurrences were Mexico, mation, by reading from protected storage or logging
Argentina and the United States, with 18, 12, and 11 the user’s keystrokes. Nevertheless, mounting an SSL
occurrences, respectively. This shows that the particular man-in-the-middle attack further enables a general way
SSL man-in-the-middle attack is occurring globally in the of capturing and recording the victim’s web browsing
wild. While it is possible that all of these attacks were am- activities in real-time.
ateur attackers individually mounting attacks (e.g. at their • Parental Control Software. Some forged SSL certifi-
local coffee shop), it is certainly odd that they happened cates were issued by parental control software, including
to use forged certificates with the same subject public key. 21 from Qustodio and 14 from ParentsOnPatrol. These
However, this is not so unreasonable if these attacks were type of software are designed to enable parents to monitor
mounted by malware. Malware researchers at Facebook, and filter the online activities of their children. Whether
in collaboration with the Microsoft Security Essentials such level of control is appropriate is beyond the scope
team, were able to confirm these suspicions and identify of our work.
the specific malware family responsible for this attack. While the remaining 104 other distinct issuer organizations
Since our experiments only tested SSL connections to in Table VIII and 252 other distinct common names in
Facebook’s servers (only for the www.facebook.com Table IX do not appear to be widespread malicious attempts
domain), we cannot confirm whether this attack also (based on manual inspection), the possibility remains that
targeted other websites. In response to our discovery, the some may still be actual attacks.
website notified the infected users, and provided them For example, we found two unexpected instances of forged
with malware scan and repair instructions. certificates issued by the Oneida Nation of Wisconsin, an
Indian tribe. We have little clue of why encrypted traffic would
5 http://helpdesk.nwciowa.edu/index.php?/News/NewsItem/View/10 be eavesdropped by such entities. It is possible that this is
6 http://superuser.com/q/421224 another case of corporate surveillance. We also found that
some schools and libraries were using forged certificates for TACK pins a signing key that chosen by the server, separate
SSL interception, such as “Central Montcalm Public Schools” from the private key corresponding to the server’s certificate,
and “Louisville Free Public Library.” and can be short-lived. TACK allows websites with multiple
For some certificates, the certificate attributes alone provide SSL servers and multiple public keys to pin the same signing
insufficient clues to determine their origin. For example, an key. Once the browser receives a TACK extension from an SSL
issuer named EasyTech could either implicate the PC repair site, it will require future connections to the same site to be
service at Staples EasyTech, or the EasyTech digital education signed with the same TACK signing key, or otherwise, reject
system on learning.com. In either case, we were unclear the connection. Another proposal called DVCert [41] delivers
why SSL connections were being intercepted for those partic- a list of certificate pins over a modified PAKE protocol in
ular targets. an attempt to detect SSL man-in-the-middle attacks, but also
requires modifications to existing clients and servers.
V. S URVEY OF M ITIGATIONS The concept of public key pinning (or certificate pinning)
We provided direct evidences of a variety of forged SSL has previously been implemented as a pure client-side defense
certificates from real-world connections in Section IV. In as well. Firefox add-ons such as Certificate Patrol [42] and
this section, we list some possible defenses that websites or Certlock [9] were designed to alarm users when a previously
browser vendors may consider to help mitigate these attacks. visited website starts using a different certificate. However,
without explicit signals from the server, it may be difficult to
A. Strict Transport Security accurately distinguish real attacks from legitimate certificate
HTTP Strict Transport Security (HSTS) [34], the successor changes, or alternative certificates.
of ForceHTTPS [35], is a HTTP response header that allows
websites to instruct browsers to make SSL connections manda- C. Origin-Bound Certificates
tory on their site. By setting the HSTS header, websites may The TLS Origin-Bound Certificates (TLS-OBC) [43] pro-
prevent network attackers from performing SSL stripping [36]. posal revisits TLS client authentication, by enabling browsers
A less obvious security benefit of HSTS is that browsers sim- to generate self-signed client certificates on demand without
ply hard-fail when seeing invalid certificates, and do not give requiring any user configurations. TLS-OBC may block most
users the option to ignore SSL errors. This feature prevents of the existing man-in-the-middle attack toolkits, since attack-
users from accepting untrusted certificates when under man-in- ers cannot impersonate the client (without stealing the self-
the-middle attacks by amateur script kiddies. However, HSTS signed private key from the legitimate browser). However, it
is not designed to protect against malware or professional does not prevent an impersonated server from supplying a
attackers that use forged certificates that would be accepted cacheable malicious JavaScript file to the client, which later
by the browser. executes in the context of the victim website, and potentially
exfiltrates data by reconnecting to the legitimate server. Fur-
B. Public Key Pinning ther, TLS-OBC requires code changes to the network stack on
The Public Key Pinning Extension for HTTP (HPKP) [37] servers (while HSTS and HPKP do not), and induces extra
proposal allows websites to specify their own public keys with computational costs for client certificate generation. Websites
a HTTP header, and instruct browsers to reject any certifi- should assess whether this is an acceptable trade-off.
cates with unknown public keys. HPKP provides protection
against SSL man-in-the-middle attacks that use unauthorized, D. Certificate Validation with Notaries
but possibly trusted, certificates. HPKP automatically rejects Perspectives [44] is a Firefox add-on that compares server
fraudulent certificates even if they would be otherwise trusted certificates against multiple notaries (with different network
by the client. Both HSTS and HPKP defenses require that vantage points) to reveal inconsistencies. Since public no-
clients must first visit the legitimate website securely before taries observe certificates from diverse network perspectives,
connecting from untrusted networks. This requirement is lifted a local impersonation attack could be easily detected. Conver-
if public key pins are pre-loaded in the browser, such as in gence [45] extends Perspectives by anonymizing the certificate
Google Chrome [38] and Internet Explorer (with EMET) [39], queries for improved privacy, while allowing users to configure
although this approach may not scale for the entire web. alternative verification methods (such as DNSSEC). The De-
Notably, Chrome’s pre-loaded public key pinning mechanism tecTor [46] project (which extends Doublecheck [47]) makes
has successfully revealed several high-profile CA incidents, use of the distributed Tor network to serve as external notaries.
in which mis-issued certificates were used to attack Google’s Crossbear [48] further attempts to localize the attacker’s posi-
domains in the wild. However, in current implementations, tion in the network using notaries. However, notary approaches
Chrome’s public key pinning does not reject certificates that might produce false positives when servers switch between
are issued by a locally trusted signer, such as antivirus, alternative certificates, and clients may experience slower SSL
corporate surveillance, and malware. connection times due to querying multiple notaries during
A related proposal, Trust Assertions for Certificate Keys certificate validation. Further, these pure client-side defenses
(TACK) [40], allows SSL servers to pin a server-chosen have not been adopted by mainstream browsers, thus cannot
signing key with a TLS extension. In contrast with HPKP, protect the majority of (less tech-savvy) users.
E. Certificate Audit Logs in Section V-B. Other defenses including audit logs and
Several proposals have suggested the idea of maintaining notary-based approaches can detect these attacks.
cryptographically irreversible records of all the legitimately- 3) Professional attacker. Next, we consider the profes-
issued certificates, such that mis-issued certificates can be sional attackers, which we define as an entity that has
easily discovered, while off-the-record certificates are sim- managed to obtained a forged certificate from a trusted
ply rejected. Sovereign Keys [49] requires clients to query CA. This classification may include a state-sponsored
public timeline servers to validate certificates. Certificate attacker who may compel trusted CAs to issue forged
Transparency (CT) [50] removes the certificate queries from certificates, or a sophisticated hacker who has success-
clients by bundling each certificate with an audit proof of its fully compromised a trusted CA directly. Server-side
existence in the public log. Accountable Key Infrastructure defenses including CT, AKI, SK, TACK, and HPKP are
(AKI) [51] further supports revocation of server and CA designed to block this type of mis-issued certificates,
keys. These defenses are designed to protect against network although at varying deployment costs (e.g. HPKP is
attackers (not including malware). However, browsers need the most lightweight in terms of server modifications).
to be modified to support the mechanism, and changes (or Notary-based defenses may spot local inconsistencies if
cooperation) are needed on the CAs or servers to deliver the the attacker mounted the attacks discriminately.
audit proof. Encouragingly, Google has announced their plan 4) Malware. As discussed in Section IV-C, malware nowa-
to use Certificate Transparency for all EV certificates in the days may also perform SSL interception. None of the
Chrome browser [52]. possible defenses are designed to prevent malware at-
tackers, which may have access to the victim client’s
F. DNS-based Authentication machine, and simply tamper with the client’s root CA
DNS-based Authentication of Named Entities (DANE) [53] store.
allows the domain operator to sign SSL certificates for web- In all, websites may consider reaping the security benefits
sites on its domain. Similar to public key pinning defenses, of deploying HSTS and HPKP defenses in conjunction, since
DANE could allow websites to instruct browsers to only accept they are most readily supported in at least one of the major
specific certificates. This approach prevents any CAs (gone browsers today. Unfortunately, these two defenses do not
rogue) from issuing trusted certificates for any domain on the prevent all types of attacks such as corporate-level surveil-
Internet. Another related proposal, the Certification Authority lance, as discussed. Several defense proposals (and prototypes)
Authorization (CAA) [54] DNS records, can specify that a are more robust against most attacks (with the exception of
website’s certificates must be issued under a specific CA. malware, which is out-of-scope), but are not yet available for
However, these approaches fundamentally rely on DNSSEC websites to use. Websites may want to stay agile and deploy
to prevent forgery and modification of the DNS records. Until multiple approaches for defense in depth. In the meantime, we
DNSSEC is more widely deployed on the Internet, websites recommend that websites or mobile applications can adopt our
must consider alternative defenses. detection method (as publicized in this paper), and possibly
collaborate to detect SSL interceptions in the wild.
G. Discussion
In this last section, we analyze the robustness of the possible VI. C ONCLUSION
defenses with regards to four common types of SSL man-in- In this paper, we introduced a new method for detecting
the-middle attackers: SSL man-in-the-middle attacks against a website’s users. We
1) Script kiddie. A script kiddie is a relatively unskilled demonstrated the feasibility of detecting man-in-the-middle
individual who simply downloads attack toolkits that attacks by implementing this mechanism on millions of SSL
have been created by others. These attackers generally connections at a top global website, Facebook. We presented
only attempt to perform attacks with less sophisticated the first analysis of forged SSL certificates in the wild. We
methods (with self-signed forged certificates) and on a revealed direct evidences that 0.2% of real-world connections
smaller scale, such as a local public WiFi hotspot. All of were substituted with unauthorized forged certificates. While
the defenses are immune to script kiddies. Even HSTS most of the SSL interceptions were due to antivirus software
can block these attacks, because any invalid certificates and corporate surveillance devices, we also observed a few
will hard-fail in supporting browsers. amateur attack attempts, and even traces of pervasive malware
2) Corporate-level surveillance. Most SSL man-in-the- in the wild that intercepted SSL connections. Our data suggest
middle attacks are attributed to corporate-level surveil- that browsers could possibly detect many of the forged certifi-
lance. In such scenarios, the corporate IT technicians cates based on size characteristics, such as checking whether
may access the client’s machine to establish trust with the certificate chain depth is larger than one. We strongly
their self-signed root certificates. SSL interception is encourage popular websites, as well as mobile applications, to
typically done without any authorization from the le- deploy similar mechanisms to start detecting SSL interception.
gitimate websites. HSTS, by design, does not reject Lastly, we assessed possible mitigations for SSL man-in-the-
browser-accepted certificates. HPKP also does not reject middle attacks, and recommend websites to deploy multiple
certificates signed by locally trusted CAs, as mentioned available defenses, in conjunction, for better protection.
 ACKNOWLEDGMENT [22] S. Fahl, M. Harbach, H. Perl, M. Koetter, and M. Smith, “Rethinking
SSL development in an appified world,” in Proceedings of the ACM
This work was done during Huang’s internship at Facebook. Conference on Computer and Communications Security, 2013.
We thank Adam Langley, Scott Renfro, Zack Weinberg, and [23] M. Marlinspike, “sslsniff,” http://www.thoughtcrime.org/software/
the anonymous reviewers for providing feedback on drafts sslsniff.
[24] C. Reis, S. D. Gribble, T. Kohno, and N. C. Weaver, “Detecting in-flight
of the paper. Special thanks to Mark Hammell and Joren page changes with web tripwires,” in Proceedings of the 5th USENIX
McReynolds for their code reviews. Symposium on Networked Systems Design and Implementation, 2008.
[25] M. Casado and M. J. Freedman, “Peering through the shroud: the
R EFERENCES effect of edge opacity on IP-based client identification,” in Proceedings
[1] A. O. Freier, P. Karlton, and P. C. Kocher, “The Secure Sockets Layer of the 4th USENIX Symposium on Networked Systems Design and
(SSL) Protocol Version 3.0,” RFC 6101 (Historic), Internet Engineering Implementation, 2007.
Task Force, Aug. 2011. [26] C. Jackson, A. Barth, A. Bortz, W. Shao, and D. Boneh, “Protecting
[2] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol browsers from DNS rebinding attacks,” in Proceedings of the ACM
Version 1.2,” RFC 5246 (Proposed Standard), Internet Engineering Task Conference on Computer and Communications Security, 2007.
Force, Aug. 2008. [27] L.-S. Huang, E. Y. Chen, A. Barth, E. Rescorla, and C. Jackson, “Talking
[3] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, to yourself for fun and profit,” in Proceedings of the Web 2.0 Security
“Internet X.509 Public Key Infrastructure Certificate and Certificate and Privacy, 2011.
Revocation List (CRL) Profile,” RFC 5280 (Proposed Standard), Internet [28] C. Kreibich, N. Weaver, B. Nechaev, and V. Paxson, “Netalyzr: Illu-
Engineering Task Force, May 2008. minating the edge network,” in Proceedings of the ACM SIGCOMM
[4] Electronic Frontier Foundation, “The EFF SSL Observatory,” https:// Conference on Internet Measurement, 2010.
www.eff.org/observatory. [29] S. Stamm, B. Sterne, and G. Markham, “Reining in the web with content
[5] VASCO, “DigiNotar reports security incident,” http://www.vasco.com/ security policy,” in Proceedings of the 19th International Conference on
company/about vasco/press room/news archive/2011/news diginotar World Wide Web, 2010.
reports security incident.aspx, Aug. 2011. [30] P. Uhley, “Setting up a socket policy file server,” http://www.adobe.com/
[6] Comodo, “Comodo Report of Incident - Comodo detected and thwarted devnet/flashplayer/articles/socket policy files.html, Apr. 2008.
an intrusion on 26-MAR-2011,” http://www.comodo.com/Comodo- [31] StatOwl.com, “Flash player version market share and usage statistics,”
Fraud-Incident-2011-03-23.html, Mar. 2011. http://www.statowl.com/flash.php.
[7] TURKTRUST, “Public announcements,” http://turktrust.com.tr/en/ [32] R. A. Sandvik, “Security vulnerability found in Cyberoam DPI
kamuoyu-aciklamasi-en.html, Jan. 2013. devices (CVE-2012-3372),” https://blog.torproject.org/blog/security-
[8] H. Adkins, “An update on attempted man-in-the-middle attacks,” vulnerability-found-cyberoam-dpi-devices-cve-2012-3372, Jul. 2012.
http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted- [33] Y. N. Pettersen, “Suspected malware performs man-in-the-middle
man-in-middle.html. attack on secure connections,” http://my.opera.com/securitygroup/blog/
[9] C. Soghoian and S. Stamm, “Certified lies: detecting and defeating 2012/05/16/suspected-malware-performs-man-in-the-middle-attack-on-
government interception attacks against SSL,” in Proceedings of the 15th secure-connections, May 2012.
International Conference on Financial Cryptography and Data Security, [34] J. Hodges, C. Jackson, and A. Barth, “HTTP Strict Transport Security
2011. (HSTS),” RFC 6797 (Proposed Standard), Internet Engineering Task
[10] S. E. Schechter, R. Dhamija, A. Ozment, and I. Fischer, “The emperor’s Force, Nov. 2012.
new security indicators,” in Proceedings of the IEEE Symposium on [35] C. Jackson and A. Barth, “ForceHTTPS: protecting high-security web
Security and Privacy, 2007. sites from network attacks,” in Proceedings of the 17th International
[11] J. Sunshine, S. Egelman, H. Almuhimedi, N. Atri, and L. F. Cranor, Conference on World Wide Web, 2008.
“Crying wolf: an empirical study of SSL warning effectiveness,” in [36] M. Marlinspike, “New techniques for defeating SSL/TLS,” in Black Hat
Proceedings of the 18th USENIX Security Symposium, 2009. DC, 2009.
[12] D. Akhawe and A. P. Felt, “Alice in warningland: A large-scale field [37] C. Evans and C. Palmer, “Public Key Pinning Extension for HTTP,”
study of browser security warning effectiveness,” in Proceedings of the IETF, Internet-Draft draft-ietf-websec-key-pinning-03, Oct. 2012.
22nd USENIX Security Symposium, 2013.
[38] A. Langley, “Public key pinning,” http://www.imperialviolet.org/2011/
[13] A. P. Felt, H. Almuhimedi, S. Consolvo, and R. W. Reeder, “Experi-
05/04/pinning.html.
menting at scale with Google Chrome’s SSL warning,” in Proceedings
[39] C. Paya, “Certificate pinning in Internet Explorer with EMET,”
of the ACM Conference on Human Factors in Computing Systems, 2014.
http://randomoracle.wordpress.com/2013/04/25/certificate-pinning-in-
[14] P. Eckersley, “A Syrian man-in-the-middle attack against Facebook,”
internet-explorer-with-emet/.
https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-
facebook, May 2011. [40] M. Marlinspike and E. T. Perrin, “Trust Assertions for Certificate Keys,”
[15] R. Holz, L. Braun, N. Kammenhuber, and G. Carle, “The SSL land- IETF, Internet-Draft draft-perrin-tls-tack-02, Jan. 2013.
scape: a thorough analysis of the x.509 PKI using active and passive [41] I. Dacosta, M. Ahamad, and P. Traynor, “Trust no one else: Detecting
measurements,” in Proceedings of the ACM SIGCOMM Conference on MITM attacks against SSL/TLS without third-parties,” in Proceedings
Internet Measurement, 2011. of the European Symposium on Research in Computer Security, 2012.
[16] D. Akhawe, B. Amann, M. Vallentin, and R. Sommer, “Here’s my [42] “Certificate Patrol - a psyced Firefox/Mozilla add-on,” http://patrol.
cert, so trust me, maybe? Understanding TLS errors on the web,” in psyced.org.
Proceedings of the International Conference on World Wide Web, 2013. [43] M. Dietz, A. Czeskis, D. Balfanz, and D. Wallach, “Origin-bound
[17] Z. Durumeric, J. Kasten, M. Bailey, and J. A. Halderman, “Analysis certificates: A fresh approach to strong client authentication for the web,”
of the HTTPS certificate ecosystem,” in Proceedings of the 13th ACM in Proceedings of the 21st USENIX Security Symposium, 2012.
SIGCOMM Conference on Internet Measurement, 2013. [44] D. Wendlandt, D. Andersen, and A. Perrig, “Perspectives: Improving
[18] E. Butler, “Firesheep,” http://codebutler.com/firesheep. SSH-style host authentication with multi-path probing,” in Proceedings
[19] S. Chen, Z. Mao, Y.-M. Wang, and M. Zhang, “Pretty-Bad-Proxy: An of the USENIX Annual Technical Conference, 2008.
overlooked adversary in browsers’ HTTPS deployments,” in Proceedings [45] M. Marlinspike, “SSL and the future of authenticity,” in Black Hat USA,
of the IEEE Symposium on Security and Privacy, 2009. 2011.
[20] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and [46] K. Engert, “DetecTor,” http://detector.io/DetecTor.html.
V. Shmatikov, “The most dangerous code in the world: validating [47] M. Alicherry and A. D. Keromytis, “Doublecheck: Multi-path ver-
SSL certificates in non-browser software,” in Proceedings of the ACM ification against man-in-the-middle attacks,” in IEEE Symposium on
Conference on Computer and Communications Security, 2012. Computers and Communications, 2009.
[21] S. Fahl, M. Harbach, T. Muders, L. Baumgärtner, B. Freisleben, and [48] R. Holz, T. Riedmaier, N. Kammenhuber, and G. Carle, “X. 509
M. Smith, “Why eve and mallory love Android: an analysis of Android forensics: Detecting and localising the SSL/TLS men-in-the-middle,”
SSL (in)security,” in Proceedings of the ACM Conference on Computer in Proceedings of the European Symposium on Research in Computer
and Communications Security, 2012. Security, 2012.
[49] P. Eckersley, “Sovereign key cryptography for internet domains,” [52] R. Sleevi, “[cabfpub] Upcoming changes to Google Chrome’s certifi-
https://git.eff.org/?p=sovereign-keys.git;a=blob;f=sovereign-key- cate handling,” https://cabforum.org/pipermail/public/2013-September/
design.txt;hb=master. 002233.html, 2013.
[50] B. Laurie, A. Langley, and E. Kasper, “Certificate Transparency,” IETF, [53] P. Hoffman and J. Schlyter, “The DNS-Based Authentication of Named
Internet-Draft draft-laurie-pki-sunlight-02, Oct. 2012. Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA,” RFC
[51] T. H.-J. Kim, L.-S. Huang, A. Perrig, C. Jackson, and V. Gligor, 6698 (Proposed Standard), Internet Engineering Task Force, Aug. 2012.
“Accountable Key Infrastructure (AKI): A proposal for a public-key [54] P. Hallam-Baker and R. Stradling, “DNS Certification Authority Au-
validation infrastructure,” in Proceedings of the International Conference thorization (CAA) Resource Record,” RFC 6844 (Proposed Standard),
on World Wide Web, 2013. Internet Engineering Task Force, Jan. 2013.