CertShim: Securing SSL Certificate Verification through Dynamic

Linking

Tyler Nichols, Adam Bates, Joe Pletcher, Braden Hollembaek,Dave Tian, Abdulrahman Alkhelaifi, and Kevin R.B. Butler

Department of Computer and Information ScienceUniversity of Oregon, Eugene, OR

University of Oregon Technical Report TR-201405-01

Abstract

Recent discoveries of widespread vulnerabilities inthe SSL/TLS protocol stack, particular with regardto the verification of server certificates, has left thesecurity of the Internet’s communications in doubt.Newly proposed SSL trust enhancements addressmany of these vulnerabilities, but are slow to be de-ployed and do not solve the problem of securing ex-isting software. In this work, we provide new mech-anisms that offer immediate solutions to addressingvulnerabilities in legacy code. We introduce Cert-Shim, a lightweight retrofit to SSL implementationsthat protects against SSL vulnerabilities, includingthose surveyed by Georgiev et. al. [19], in a mannerthat is transparent to the application. We demon-strate CertShim’s extensibility by adapting it towork with Convergence, DANE, and Client-BasedKey Pinning. CertShim imposes just 20 ms over-head for an SSL verification call, and hooks the SSLdependencies of 94% of Ubuntu’s most popular pack-ages with no changes necessary to existing applica-tions. This work significantly increases system-widesecurity of SSL communications in non-browser soft-ware, while simultaneously reducing the barriers toevaluating and adopting the myriad alternative pro-posals to the certificate authority system.

1 Introduction

Internet applications have relied for years on the SS-L/TLS libraries for secure end-to-end channels, but agrowing body of literature points to systemic lapsesin security procedure that renders our communica-tions insecure. The heart of these problems lies withthe inability for clients to accurately authenticate theserver when presented with its public-key certificate.Certificate validation has been shown to be incor-rect at all layers of the SSL stack, from impropercertificate handling in libraries [7, 29], to confusionand abuse of SSL APIs [19, 43], to applications thatare broken by design so that they are easier to use[17]. Moreover, high profile compromises of promi-nent Certificate Authorities (CAs) have eroded thevery foundations of the SSL trust model [32, 18, 12].Any one of these lapses gives rise to the threat ofa Man-in-the-Middle (MitM) attack, in which an at-tacker is able to intercept and read supposedly-secureSSL traffic in transit to or from a target website.

While a variety of forward-thinking solutions havebeen proposed in the literature [10], less attention hasbeen paid to immediate countermeasures, and waysin which we can fix the vast amount of legacy soft-ware that is vulnerable and inexorably linked to theCA model. Detecting and reporting these vulnera-bilities is an inadequate solution; studies of AndroidSSL usage have found that up to 76% of vulnerabili-ties persist for over a year [43], even once the devel-opers have been notified of confirmed vulnerabilities

1

[17]. In the presence of aloof and unavailable devel-opers, we must pursue alternate means of securingour Internet communications.

In this paper, we consider a system-wide approachto securing negligent SSL code in non-browser soft-ware that simultaneously facilitates the immediateuse of CA alternatives and other SSL trust enhance-ments. We present CertShim, a lightweight retrofitto existing popular SSL implementations (OpenSSL,GnuTLS, and partial support for JSSE) that actsas a shim1 into the validation procedure in dynami-cally linked applications. CertShim provides appli-cation and domain specific handlers thatforce correctcertificate validation on previously insecure applica-tions. We demonstrate its practicality by incorporat-ing a variety of verification techniques including tra-ditional CA validation, Convergence [30], DANE [23],and client-side key pinning [14, 31, 37, 42], some ofwhich were previously only available as experimentalbrowser plug-ins, CertShim reduces the barrier toadopting alternative certificate validation systems bymaking them immediate candidates for system-widedeployment.

While recent studies have made recommendationsfor the general improvement of the SSL ecosystem,few have introduced system-wide defenses to SSL vul-nerabilities in legacy software. Fahl et al. modify theAndroid API to restrict SSL misuse [17], while Contiet al. introduce MYTHIS, a benign MitM proxy forAndroid that is able to defend against rogue accesspoint attacks [11]. In contrast to these works, ourplatform-wide defense does not require a manufac-turer update, or even administrator privileges, to beput to use. We also deliver on the promise of plug-gable certificate verification that is left to future workby Fahl et al., and go a step further by showingthat additional security assurances can be attainedby layering multiple verification modules. CertShimworks in desktop and server environments, which areconsiderably more complex than Android, as vari-ous SSL implementations need be considered. Fur-thermore, the solutions for Android experience com-patibility issues with some programs; in contrast, we

1A shim is a library that transparently intercepts an APIand changes its parameters or operations.

present a policy engine that provides application- anddomain-specific certificate handling.

We make the following contributions:

• Enforce Safe Defaults on SSL: CertShimhooks calls to SSL APIs in order to enforce host-name validation and certificate validation. Asthis behavior would otherwise break applicationsthat pin certificates or connect to domains thatuse self-signed certificates, we present a policyengine that enforces safe defaults but providesunique handlers based on the application anddestination domain.

• Enable CA Alternatives: Existing opensource initiatives may be slow to adopt alterna-tive SSL trust models, may intentionally chooseto stay with the status quo of certificate author-ities, or may simply have gone defunct. Cert-Shim provides modular retrofits that allow exist-ing applications to use modern CA alternatives.CertShim provides a means of taking the con-sensus of multiple forms of certificate validation,which to our knowledge is the first of its kind inthe literature, allowing even stronger guaranteesthrough ensemble validation.

• Performance Analysis of CertShim: Wesurvey Ubuntu’s 10,000 most popular packagesand find that CertShim supports 94% of the 390packages that were found to contain SSL usage.Our benchmarks show that the use of CertShimadds as little as 20 ms to an SSL lookup under re-alistic conditions. We also perform manual test-ing to determine that CertShim transparentlysecures all of the major SSL library misconfig-urations and 8 of the 9 data-transport libraryvulnerabilities identified by Georgiev et al.[19].

The remainder of this work is organized as follows:Section 2 provides background on SSL, CAs, and theproblems associated with certificate validation. InSection 3 we present the design and implementationof CertShim, analyze its features in Section 4, andevaluate its performance as well as coverage of realworld SSL usage in Section 5. Limitations of ourapproach and future work are discussed in Section

2

6, and related work is summarized in Section 7. InSection 8 we conclude.

2 Background

The SSL/TLS protocol families are largely responsi-ble for securing the Internet’s web traffic. The orig-inal SSL (Secure Socket Layers) protocols were in-troduced by Netscape in 1995 to provide confiden-tiality, integrity, and identity to network communica-tions [22]. While the foundations of SSL’s solutionsto confidentiality and integrity have withstood thetest of time, reliably establishing destination identityin SSL connections has proven to be a surprisinglydifficult problem. Without identity assurances, usersare vulnerable to the threat of impersonation or Man-in-the-Middle (MitM) attacks, in which an attackeris able to intercept and read supposedly-secure SSLtraffic bound to or from a target website. We stillrely on Netscape’s original solution, the CertificateAuthority (CA) public key infrastructure, which re-quires that domains register with one or more CAs inexchange for a signed X.509 certificate. A client canthen authenticate the server validating its certificateby using the issuing CA’s public key; obtaining thispublic key is a transparent process to the client, as itis likely pre-installed into their operating system orweb browser.

Development Vulnerabilities. Good SSL code,particularly with regards to certificate verification,is very difficult to correctly implement. NumerousMitM vulnerabilities have been discovered in certifi-cate chain validation routines, such as null prefix at-tacks on Pascal strings [29, 28]. Georgiev et al’s sur-vey of SSL connection authentication exposed per-vasive misunderstanding of certificate verification inSSL API’s in non-browser software, and also drew at-tention to many popular SSL libraries that are brokenby design [19]. Fahl et al. interviewed developers tofind that apps were often intentionally broken so asto allow for easier development, or to support self-signed certificates [17]. Even worse, the tomes of vul-nerable SSL code that exist today that are unlikelyto ever be patched. Studies of SSL vulnerabilities inAndroid apps have found that up to 76% of vulner-

abilities persist for over a year [43], even once thedevelopers have been notified of confirmed vulnera-bilities [17]. Even more surprisingly, Brubaker et al.perform automated testing to uncover dramatic in-consistencies in the validation routines of the majorSSL libraries, some of which gave rise to exploitablevulnerabilities [7]. Given that not even SSL librarydevelopment teams can agree on best practices forcertificate handling, the situation today is certainlygrim.

Trust Vulnerabilities. Orthogonal to these im-plementation issues are a number of fundamental andsystemic limitations in the CA trust model. CAs areunder no obligation to perform due diligence beforeissuing a certificate, and in fact this lack of verifi-cation is pervasive in the certificate ecosystem [45].This, combined with the myriad recent serious, high-profile compromises and blunders (e.g., Comodo[32],Diginotar[18], TURKTRUST[12]), makes it fair toask whether CAs are sufficiently incentivized to pre-serve the security of themselves or their customers.These lapses are at times met without any seriousrepercussions [9, 30], and there is even evidence thatCAs work directly against customer security by offer-ing wiretap services [21, 39, 41, 42]. These problemsare serious enough, but they are exacerbated by a lackof scoping; any CA can verify any certificate, meaningthat conscientious businesses that certify with rep-utable CAs are just as at risk, and software vendorsoften include potentially untrustworthy CAs in orderto ensure compatibility with Internet services [15].

2.1 CA Alternatives

Proposed CA enhancements and alternatives weresurveyed by Clark and van Oorschot [10], who iden-tify families of proposals based on their underlyingfundamental principles of operation. These alterna-tives vary widely in terms of both their advantagesand limitations, reflecting differences of opinion onthe fundamental problems with the CA trust model.This work makes use of an important subset of thesesecurity enhancements that require no server sidechanges in order to be adopted; primitives such asmultipath probing [3, 30, 47], client-based key pin-ning [37, 14, 31, 42], and certificate revocation lists

3

[33, 38, 13, 26] are eligible for immediate deploy-ment by individual users, providing tangible securityenhancements to today’s Internet threats. Due toits relative popularity, we also consider the DANEDNS-based key pinning system, a trust enhancementthat embeds X.509 certificates in DNSSEC records[23, 27]. However, none of these trust enhancementshas enjoyed widespread deployment, in part due tothe vast amount of non-browser software that wouldneed to be modified in order to enable their system-wide use.

Key pinning, Convergence, and DANE are exem-plar trust enhancements that we make use of in thiswork. However, each suffers from inherent design ortrust limitations that impact their applicability incertain scenarios. For example, client-based key pin-ning cannot determine whether a change in a server’scertificate is malicious or benign. Recent work byAmann et al. [2, 4] shows that routine changes to SSLtrust relationships are often indistinguishable fromattacks, making this a noteworthy limitation. In con-trast, Convergence can offer insight into the cause ofthe unexpected certificate by detecting whether thecertificate has changed globally, or just locally. How-ever, if the new certificate is the result of a MitMattack near the server, the Convergence notaries willconclude that the change is benign, resulting in a dan-gerous false negative. DANE, by checking the targetdomain’s TLSA record, could offer a definitive an-swer to whether the change was benign, but DANEis being incrementally deployed and further bloatsthe traditional CA trust model to include the DNSarchitecture. In this work, we show that by queryingmultiple certificate validation systems it is possibleto retain the benefits of each while mitigating eachsystem’s limitations.

3 Design

3.1 Threat Model & Assumptions

Our system is designed with consideration for an ad-versary in the network that attempts to launch aMitM attack against SSL communications; this at-tack could be launched from a rogue wireless access

point from which the client is connecting, or fromelsewhere on the Internet, such as somewhere on thenetwork paths between the client and server. Cert-Shim works under multiple trust models, and wetherefore consider adversaries of varying strengths.A weak attacker might only possess an untrustedCA certificate, but a stronger attacker might pos-sess a valid certificate from a trusted CA, or evencontrol parts of the Internet architecture (e.g., net-work paths, trusted CAs, DNS resolvers). We discussthe security of various verification modules againstthese adversaries in Section 3.4. When client-basedkey pinning is considered, we assume that the Clienthas had one opportunity to correctly authenticate theserver in the past, which is necessary for use in Truston First Use (TOFU) authentication [5].

We seek to secure client-side non-browser applica-tions that are benign but potentially defective in theiruse of SSL. In particularly, we wish to protect againstinsecure use of SSL libraries. Except where otherwisenoted, we do not consider incorrectness within theunderlying libraries themselves [7, 20], assuming in-stead that they are correctly implemented. This workis motivated by the fact that developers often fail tofix vulnerable code, so we assume that the applica-tions will not take active countermeasures to bypassour mechanism. CertShim interposes on popularknown SSL libraries; we do not consider applicationsthat use their own SSL implementations. Doing sowould increase the cost and complexity of softwaredevelopment, and in evaluation we found no evidencethat this was a widespread practice. However, we doanticipate that applications can use many layers ofabstraction/misdirection in calling an SSL API, suchas a cURL wrapper for a scripting language.

3.2 System Goals

We set out to design a mechanism that provided thefollowing system-wide properties:

Override Insecure SSL Usage. Force safe de-faults for certificate handling (i.e., validation of host-names and certificate chains) on all SSL connections,regardless of whether or not the application makesany attempt to do so. This encompasses applicationsthat misconfigure the SSL API, applications that use

4

python-apt

netcat

curl

mailutils

libssl1.0.0

gnutls26

CertShim

Convergence

DANE

Preloaded Shared Object SSL ApplicationsSSL Libraries

. . .. . . . . .

Key Pinning

Policy Engine

Figure 1: CertShim interoperates with various SSLlibraries, replacing their certificate verification func-tions with those from proposed CA alternatives.

insecure SSL wrappers, and applications that are bro-ken by design.

Enable SSL Trust Enhancements. In additionto traditional verification, our system should be con-figurable to enable the use of CA alternatives andenhancements. CA Alternatives are often incapableof correctly authenticating all Internet domains dueto design limitations or incremental deployment, sowe also wish to provide a means of querying multipleverification methods and reconciling their results.

Maximize Compatibility. Due to the great di-versity of SSL usage, existing software will use SSLAPIs in ways that we cannot anticipate, some ofwhich may be perfectly valid and secure. These con-straints could be application-specific, such as using apinned certificate, or trusting a corporate CA. Oth-ers could be domain-specific, such as a server on anunreachable private network, or a server that has notpublished a TLSA record [23]. Our mechanism mustbe able to coexist with these applications withoutbreaking them.

Maximize Coverage. As applications could con-ceivably re-implement SSL from the RFCs, it is im-possible to enumerate all of the possible SSL libraries.However, we wish to maximize the coverage of our de-fensive layer by supporting the libraries that are mostcommonly used by SSL applications in practice.

3.3 CertShim

Our system, CertShim, is a dynamically linkedshared object that performs binary instrumentation

Function Location Purposeconnect libssl1.0.0 Initial SSL handshakedo handshake libssl1.0.0 Renegotiate handshakeget verify result libssl1.0.0 Check verification resulthandshake libgnutls26 SSL handshakecertificate verify peers2 libgnutls26 Verify certificate (deprec.)certificate verify peers3 libgnutls26 Verify certificateCheckIdentity JDK6 Verify hostnameCheckIdentity JDK7 Verify hostnameSetEndpointIdentifAlg JDK7 Verify hostnameconnect System call Track hostname, portgethostbyname System call Track hostname, portgetaddrinfo System call Track hostname, port

Table 1: Functions that CertShim overrides/hooks.Multiple hooks are required because libraries havemultiple entry points that trigger certificate verifica-tion.

in order to layer additional security onto the pop-ular SSL implementations, OpenSSL and GnuTLS,and includes an additional mechanism that instru-ments JSSE’s SSLSocketFactory. Shown in Figure1, CertShim works primarily through use of theLinux dynamic linker’s LD PRELOAD environment vari-able. Under normal circumstances, a function such asssl connect() would resolve to code in libssl.so.However, when CertShim is enabled, the linker firstlooks at our shared object before moving to the stan-dard include paths, allowing us to redefine the be-havior of the library’s verification function withoutmodifying specific executables, as shown in Figure3. CertShim performs additional certificate checksand also calls the original functions such that the se-curity semantics of the original library workflow ispreserved. The specific form of verification is modu-lar, and is discussed at greater length in Section 3.3.2.

3.3.1 Function Hooks

CertShim targets both verification functions andhandshake functions in SSL libraries as well as systemcalls that allow for the recovery of important networkcontext. A list of the CertShim’s function hooks isincluded in Table 1.

Verification Functions. To manipulate certificatehandling procedures, the most obvious place to startwas with SSL library verification functions. Weinstrumented OpenSSL’s ssl get verify result()

5

1 int SSL_get_verify_result(SSL *ctx)

2 // Determine SSL initialization type

3 type = resolve_ctx_type(ctx)

45 // Obtain the domain and port

6 name = lookup_name(ctx)

7 port = lookup_port(ctx)

89 // Grab the certificate fingerprint

10 sha = extract_ctx_fingerprint(ctx)

1112 // Call a validation Function

13 status = 0

14 if (CONFIG_CERT_PINNING)

15 status += keypin_verify(name ,port ,sha)

16 if (CONFIG_CERT_AUTHORITY)

17 status += ca_verify(name ,port ,sha)

18 if (CONFIG_CONVERGENCE)

19 status +=

convergence_verify(name ,port ,sha)

20 if (CONFIG_DANE)

21 status += dane_verify(name ,port ,sha)

2223 // Check the results

24 if (resolve(status) == OK)

25 return X509_V_OK

26 else

27 return X509_ERR_INVALID_CA

shim.c

Figure 2: Pseudocode for CertShim’s dynamicallyloaded SSL get verify result function.

and GnuTLS’ gnutls certificate verify peer()

to support modular certificate verification. The re-turn values of these functions are consistent with theAPI of their respective libraries, and reflect the re-sult of the module’s decision. Pseudocode for Cert-Shim’s version of SSL get verify result() can befound in Figure 2. In lines 2-7, the canonical nameand port of the certificate are recovered. In lines9-10, the certificate fingerprint (SHA1 hash) is ex-tracted from the SSL context. Certificate validationfunctions are called in lines 12-19. Lines 21-25 returnthe standard X509 accept or reject values based onwhether or not the certificate was approved.

Handshake Functions. While the verification func-tion hooks allow us to make use of CA alterna-tives, they are insufficient to force proper verifica-

Client Application: SSL_connect()

CertShim: Disable SSL struct callbacks

CertShim: Call libssl SSL_connect()

CertShim: Call Verification Module

Terminate connection and return error

Fatal connection

error

Client Application: Executed

ELF preloads CertShim

CertShim: Init,Load policies, hooks

CertShim: Check verification result

against policy

Return OK on success or connection error on failure

Figure 3: Interaction between a client application us-ing the SSL connect() function and CertShim.

tion in vulnerable applications due to the fact thatthey often go unused by developers [19]. Therefore,CertShim also targets the main connection func-tions of SSL libraries, which represent a choke pointat which we can force certificate verification. Weinstrument OpenSSL’s ssl connect() and ssl do -

handshake() functions and GnuTLS’s gnutls do -

handshake() function. CertShim first calls the orig-inal functions from each respective library, return-ing its error code if the connection failed on its own(e.g., due to network connectivity failure). If thecall is successful, however, CertShim calls the ver-ification module as described above. If verificationfails, CertShim generates an error that emulatesa connection failure, essentially short-circuiting theSSL connection and forcing the application to recover(shown in Figure 3). This system behavior is likely

6

to cause unexpected behavior in some applications;however, as we show in Section 3.4 the behavior ofthe verification module can be configured to preventapplication breakage.

CertShim’s inclusion of both handshake and ver-ification functions is to ensure that vulnerable SSLcode is hooked. This is necessary because numerousstudies have shown that negligent developers oftenfail to consult SSL verification functions [19, 17]. Asa consequence, however, CertShim will redundantlyverify certificates in well-formed SSL code. The ver-ification function hooks are superseded by the hand-shake hooks in normal usage, but we felt it impor-tant to hook the verification functions so that the li-braries’ certificate handling was consistent across dif-ferent parts of the API. We show in Section 5 thatthe performance costs of using CertShim are mini-mal, and that this redundancy is a small price to payfor the added coverage assurances.

Network Context. Some alternate certificate ver-ification methods, such as network probing, requirea canonical hostname and port in order to validatean X509 certificate. However, the structures passedinto OpenSSL and GnuTLS functions do not reliablycontain this information. This is due to the greatvariety of ways in which these routines are invoked;in some cases, certificates are verified without beingaware of the endpoint with which the SSL session isbeing established. To recover this information, weinstrument the getaddrinfo(), gethostbyname(),and connect() system calls. By recording the pa-rameters passed and returned from the original func-tions, we were able to perform reverse lookups thattranslated socket file descriptors to hostnames, whichwere then stored in a sqlite3 database that waskeyed from the process id of the calling function.Keying off the pid was important to allowing thedatabase to be shared between processes, preventingfile descriptor collisions.

3.3.2 Verification Modules

Currently, CertShim supports 4 certificate verifica-tion methods:

• Traditional CA Verification: Module invokesthe underlying native SSL API calls.

• Convergence[30]: Module communicates withConvergence Notaries via a REST API. Conver-gences local cache is implemented as a sqlite3

database, and the list of trusted notaries and averification threshold is set via a configurationfile.

• DANE [23]: Module is a thin wrapper aroundLexis’ SWEDE library for TLSA record verifica-tion [35]. This servers to demonstrate that exist-ing prototypes for SSL trust enhancements canbe easily adapted for use with CertShim. Withminor modifications, this module could be usedto deploy Liang et. al.’s DANE extension for se-curing CDN connections in non-browser software[27].

• Client-Based Key Pinning: Implementa-tions currently exist as Firefox Plug-Ins [37, 42].Rather than adapting these utilities, we de-veloped our own trust-on-first-use key pinningmodule that stores certificate fingerprints in ansqlite3 database.

Not only does CertShim facilitate the use of anyone of these modules, it also offers support for cer-tificate validation through ensemble voting strate-gies. For example, all 4 of the modules can be en-abled simultaneously, with a majority vote deter-mining whether or not the certificate is approved.Because CertShim uses a single verification mod-ule across many implementations of SSL, prototyp-ing clients for new CA alternatives becomes a one-time cost and interoperability with a variety of SSLlibraries is assured.

3.4 Policy Engine

CertShim includes a policy engine that allows usersto easily express complex certificate verification rou-tines that can be enforced system-wide or tailored toa specific application or domain. Policies are definedby the user as an Apache-like configuration file that

7

1 global_policy: {

2 cert_pinning = false;

3 cert_authority = true;

4 convergence = false;

5 dane = false;

6 vote = 1.00;

7 };

89 command_policies: ({

10 cmd = "/usr/bin/git";

11 vote = 1.00;

12 methods: {

13 cert_authority = false;

14 convergence = true;

15 };

16 }, {

17 cmd = "/usr/bin/lynx";

18 vote = 0.50;

19 methods: {

20 cert_pinning = true;

21 convergence = true;

22 dane = true;

23 };

24 });

2526 host_policies: ({

27 host = "www.torproject.org";

28 vote = 1.00;

29 methods: {

30 cert_authority = false;

31 dane = true;

32 };

33 });

config.cfg

Figure 4: A sample CertShim policy configurationfile

is dynamically loaded every time an application is in-voked, allowing for the user to alter the SSL behaviorof all applications on the system at any time withouthaving to recompile. Figure 4 is an example of sucha policy definition file. The configuration subsystemof CertShim uses libconfig [1] for parsing the con-figuration file and extracting data.

The structure of the policy file is easy to under-stand and use. A global policy entry defines thesystem-wide behavior of CertShim except for caseswhere a more specific policy is present. The enginefinds relevant policy entries by pattern matching over

the cmd and host keys, with priority being given tohost entries. The methods key in each entry allowsfor the enabling and disabling of specific verificationmodules. The vote key represents the percent ofmodules that must return true before CertShim ap-proves the certificate. When a key is not set in a spe-cific entry, it inherits the value of the global policy.The ordering of the policies within the configurationfile is irrelevant.

Figure 4 shows an example configuration file thatillustrates the granularity and flexibility of the Cert-Shim policy configuration engine. The global pol-icy is set to force traditional CA verification on allSSL connections. However, this user connects to aGitLab versioning server that makes use of a self-signed certificate, so they created a command pol-icy entry for git that uses the Convergence module.The user also wants stronger assurances than tradi-tional CAs can provide when browsing with Lynx,so they create an additional command entry thatqueries all 4 modules and requires that at least 2 re-turn true. This entry inherits its cert authority

value from the global policy. Finally, when connect-ing to domains that are known to offer DANE sup-port such as torproject.org, the user adds a hostpolicy entry that requires DANE validation. Policiesthat tolerate failure in this fashion are useful whenusing CertShim as a platform for testing CA alter-natives that may not be entirely stable. In the eventthat a verification method fails but overall verifica-tion passes, CertShim prints a notification of thefailure to syslog.

3.5 Java Instrumentation

In the Java architecture, we cannot interpose on SSLlibraries such as JSSE and BouncyCastle throughLinux’s dynamic linking. Instead, we make use of thejava.lang.instrumentation interface to achievesimilar functionality inside of the JVM. We success-fully used this method to provide CertShim-likefunctionality by hooking the checkIdentity() func-tion in JDK 6’s JSSE, and the checkIdentity() andsetEndpointIdentificationAlgorihtm function ofJDK 7. Georgiev et al. point to misuse of the lowlevel JSSE SSLSocketFactory API, which does not

8

perform hostname verification, as one of the biggestSSL vulnerabilities in Java [19]. While in controlof these functions, CertShim overrides the applica-tions’ configuration in order to force hostname ver-ification. Like our C-based mechanism, our instru-mentation object can be injected into all Java callsby setting an environment variable. Java is not yetfully supported in CertShim, as we have not re-implemented our policy engine and verification mod-ules. However, this mechanism demonstrates how ourapproach can be generalized to work with Java.

4 Analysis

We now consider the extent to which CertShimmeets our 3 primary system goals: override insecureSSL usage, enable SSL trust enhancements, and max-imize compatibility. We consider the extent to whichwe achieve maximal coverage in Section 5.

4.1 Override Insecure SSL Usage

Recent work has uncovered strong evidence that inse-cure certificate handling practices are often a result ofdeveloper confusion and apathy [16, 17, 19]. Ratherthan wait on developers, CertShim automaticallyfixes these vulnerabilities without requiring developerintervention. Enforcing safe defaults for SSL doesnot even require policy configuration, as CertShiminstalls with a global default policy that enforces CAverification. We also include fail safe protections tothe policy engine, such as the vote key defaulting to1.00 if left accidentally unspecified by the user.CertShim supports all applications that dynami-

cally link to OpenSSL and GnuTLS, two of the mostpopular open source SSL libraries. In Section 5, weshow that this provides support for 94% of SSL usagein the most popular Ubuntu packages. Most excit-ingly, CertShim fixes certificate verification in data-transport libraries that are broken by design, includ-ing urllib/urllib2, httplib, python’s ssl module,and perl’s fsockopen call. This aspect of CertShimproves critical, as the survey in Section 5 finds thatsuch libraries represent up to 33% of SSL usage inUbuntu packages.

4.2 Enable SSL Trust Enhancements

In this work, we implement verification modules for3 exemplar CA alternatives, making them immediatecandidates for system-wide deployment. Switchingfrom CA verification to an alternative such as Con-vergence requires a change of just 2 lines in the Cert-Shim configuration file. Due to incremental deploy-ment or design limitations, some CA alternatives arenot universally applicable to the entire SSL ecosys-tem. For example, not all HTTPS domains havepublished TLSA certificates for DANE, and other do-mains will be inside closed networks that cannot beverified with Convergence’s multi-path probing. Wehave further contributed to the adoptability of CAalternatives by introducing a policy engine that al-lows for application and domain specific certificatehandling. With CertShim, it is possible to forceDANE verification only on domains that are knownto be supported. CertShim even helps to supporttraditional CA verification by providing a multi-pathprobe module that can be enabled specifically for ap-plications and domains that make use of self-signedcertificates.

4.2.1 Consensus Verification

CertShim further improves SSL security by provid-ing the first practical means of reconciling the re-sults of multiple certificate verification handlers. Inso doing, it is possible to overcome practical prob-lems or trust concerns that are limitations of differentarchitectures. To demonstrate the power of this ap-proach, we present sample policy entries that repre-sent unique trust and usage models for SSL. For a de-tailed explanation of the security properties of thesesystems, please refer to the original works. We believethat the combining of different verification primitivesthrough consensus voting represents a promising newdirection for securing SSL.

Distrust the CAs. Convergence was motivated bythe goal of completely removing certificate authori-ties from the SSL trust model. CAs are replaced withnotaries, trusted third parties that are incentivized tobe trustworthy agents due to trust agility, the abilityof the user to change who their trusted notaries at

9

any time. However, multi-path probing cannot vali-date all domains. One option would be to combineConvergence with client-based key pinning:

cert_pinning = true;

convergence = true;

vote = 0.50;

This configuration allows for a CA-free trustmodel. When Convergence is unable to validate adomain, CertShim would default to a trust-on-first-use model [5]. In the event that a certificate is up-dated, in most cases Convergence would be able tore-validate the domain, making up for key pinning’sinability to offer context in the event of a benignanomaly. In the event of a discrepancy between acached certificate and the certificate presented by thehost, the key pinning module would fail to verifythe certificate, requiring the user to manually decidewhether or not to trust the presented certificate.Server-side MitM Defense. Convergence relieson network path diversity in order to validate certifi-cates. While this is adequate for detecting local MitMattacks at rogue access points, if a powerful adversarysuch as a nation state can control all paths betweenthe server and the notaries, Convergence could yielda false negative during an attack. To account for thispossibility, CertShim could tether its trust to theDNS architecture:

convergence = true;

dane = true;

vote = 1.00;

This policy increases attack complexity by requir-ing the attacker to control the DNSSEC resolvers anda valid certificate from a trusted CA in addition toall network paths to the server. We note that thispolicy only works for domains that offer DANE sup-port. In environments where DNSSEC is actively be-ing used, the use of Convergence provides a hedgeagainst DNSSEC server compromises.

4.3 Maximize Compatibility

As the invasiveness of our function hooks increased,so too did the likelihood that CertShim would

Program Success Confirmed Withlibcurl Yes C programgnutls26 Yes C programlibssl1.0.0 Yes C programSSLSocketFactory Yes java programperl socket::ssl Yes perl scriptphp curl No php scriptfsockopen Yes php scripthttplib Yes python scriptpycurl Yes python scriptpyOpenSSL Yes python scriptpython ssl Yes python scripturllib, urllib2 Yes python scriptgnutls-cli Yes CLI execution

Table 2: Libraries and wrappers that were manuallyconfirmed to be supported by CertShim.

break applications. Developers could not have antic-ipated our layering of additional certificate verifica-tion methods on top of their code. Applications maydisable certificate verification in order to support self-signed certificates [17], contact domains that are notcompatible with certain forms of verification, or evenhave implemented their own security features such askey pinning. As a result, CertShim’s actions couldtrigger unexpected behavior.

These realities motivated the creation of our policyengine, which offers the ability to completely elimi-nate compatibility issues by performing applicationand domain specific certificate handling. When a cer-tificate is rejected, CertShim logs both a record ofthe event and a template policy entry for the user toedit. This log can optionally be redirected to stdout.

Regardless of the policy in effect for a given con-nection, the CertShim hook return values strictlyadhere to the OpenSSL and GnuTLS APIs. This im-plies that existing applications are unable to detectthe presence of CertShim while allowing CertShimto remain entirely method-agnostic. That is, Cert-Shim does not interfere with the logic built into ex-isting applications since return values remain true tothe OpenSSL and GnuTLS APIs and CertShim it-self holds no opinion on which verification methodsit should or should not use; CertShim can even beconfigured to take no action for a given applicationor domain. Furthermore, the success or failure of al-

10

Program Test Cmd Successcurl curl https://google.com Yessslscan sslscan google.com:443 Yeslynx lynx -dump https://google.com Yesncat ncat –ssl-verify google.com 443 Yesfdm Checked gmail.com over SSL Yesfetchmail Checked gmail.com over SSL Yesfirefox Visited gmail.com (w/o plugin) Nompop Checked gmail.com over SSL Yesperl Perl’s IO::Socket::SSL Yespycurl cUrl established SSL session YespyOpenSSL Socket established SSL session Yesurllib urllib made HTTPS request Yesw3m w3m https://google.com -dump Yeswget wget https://google.com Yesgnutls-cli Performed handshake procedure Yes

Table 3: Programs and libraries that were manuallytested to confirm CertShim support

ternate verification methods is translated into returncodes consistent with OpenSSL and GnuTLS.

5 Evaluation

In this section, we evaluate CertShim for both itsability to support real world SSL usage and the per-formance costs it imposes on SSL connections.

5.1 Coverage

Our investigation of CertShim coverage is comprisedof two parts. We first perform a small-scale surveyin which we manually test applications and librariesto confirm support, followed by a large-scale surveyin which we conduct semi-automated source code in-spection to estimate CertShim coverage for a fullerdistribution of software.

5.1.1 Manual Testing

Our evaluation of CertShim coverage began withmanual testing of popular SSL applications and mid-dleware. Presently, CertShim is confirmed to sup-port 12 different SSL implementations or wrappers,shown in Table 2. Although it was apparent thatthe listed SSL scripting wrappers all used OpenSS-L/GnuTLS backends, it was necessary to manually

(a) Total Packages Supported (b) Packages supported by SSLlibrary/wrapper

Figure 5: Estimated CertShim support of SSL usagefound in Ubuntu Popularity Contest.

confirm compatibility because the wrappers occasion-ally made use of the SSL API in unexpected ways.For example, we discovered that CertShim does notsupport php curl due to the fact that this librarystatically links libcurl. Continuing with manualtesting, we selected a handful of common SSL appli-cations to confirm CertShim support, shown in Ta-ble 3. Of these, CertShim successfuly hooked eachapplication except for Firefox, which is due to thefact that Mozilla uses LibNSS rather than OpenSSLor GnuTLS. We discuss the broader implications ofthese coverage gaps in Section 6.

5.1.2 Less Dangerous Code?

We next consider CertShim’s safe default features,and how they protect against the SSL vulnerabilitiespresented by Georgiev et al. [19]. Through manualtesting, we confirmed that CertShim would securethe SSL communications in 100% of the SSL libraries,89% of the data-transport libraries, and 71% appli-cations mentioned in this work:

• SSL Libraries. Error-prone aspects of theSSL API are identified in OpenSSL, GnuTLS,and JSSE. CertShim enforces proper certificatehandling for OpenSSL and GnuTLS, even whenthe application fails to call the verification func-tion. We provide partial support to JSSE, whichwe instrumented to ensure that hostname veri-fication is always performed, regardless of howthe API is invoked.

11

• Data-transport Libraries. Georgiev et al.discuss 9 data-transport frameworks that wrapthe major SSL libraries. We provide full supportto cURL, php’s fsockopen, urllib, urllib2,httplib, python ssl, and partial support tothe Java libraries Apache HttpClient and We-berknect. The only library that CertShim doesnot support is php curl due to static linking.

• SSL Applications. We obtained the vulner-able versions of several of the applications ex-plored, including Lynx, Apache HttpClient, andApache Axis. Based on review of these applica-tions combined with our manual tests, we con-clude that CertShim secures the SSL commu-nications of 12 of the 17 applications mentionedthat could be run on Linux systems. All 5 of theunsupported applications were payment servicesthat had a vulnerable php curl dependency.

These findings demonstrate the power of the Cert-Shim methodology. It also serves to show that, solong as the API remains the same, CertShim canprotect against presently undiscovered vulnerabilitiesand misconfigurations in SSL APIs and wrapper li-braries.

5.1.3 Large-Scale Coverage Survey

On a general computing platform such as Linux, au-tomated dynamic analysis of SSL proved difficult dueto the great variety of SSL implementations, lan-guages, and usage scenarios. During manual testing,we found that a thorough knowledge of an applica-tion’s purpose and behaviors was required in orderto trigger SSL connections. As a result, we were un-able to perform large-scale dynamic analysis of Cert-Shim. Fortunately, based on the supported librariesshown in Table 2, we were able to use a mix of staticanalysis and manual inspection in order to arrive ata CertShim coverage estimate for a large corpus ofapplications.

As a source for real world SSL usage, we se-lected the Ubuntu Popularity Contest [34], a servicethat tracks the most commonly installed packages onUbuntu. Starting with the top 10,000 packages, we

Dependency Support? Pkg. Counturllib/httplib Yes 123OpenSSL Yes 92GnuTLS Yes 51cURL/libcurl Yes 48Misc SSL Wrappers Yes 56Total Supported 370Total Unsupported 26

Table 4: Details of estimated CertShim support andSSL usage in the Ubuntu Popularity Contest.

ran apt-rdepends, a tool for recursively finding li-brary dependencies for a given package, on each pack-age. Of these packages, we were able to recover li-brary dependency information for 7,789 packages dueto the fact that some packages were not present inthe main apt repositories for Ubuntu 12.04. Fromthis list we discovered 2,949 packages that had de-pendencies to known SSL libraries (i.e., the pack-ages left out could not have been using SSL). Wethen gathered the corresponding source files usingapt-get source. This methodology yielded 1,809codebases, with the reduction in total packages be-ing accounted for by the fact that one codebase canbe responsible for multiple packages. With the avail-able source, we proceeded to check the files againsta list of keywords related to networking, SSL, andHTTPS. After narrowing the field to source packagescontaining keywords, we manually inspected the re-maining packages to confirm that the package madeSSL connections. As CertShim only partially sup-ports Java, these packages that were removed fromthe survey.

Because CertShim cannot support static linking,we also wished to determine if this was a commonpractice. To do so, we installed the 395 packagesthat contained SSL activity, then ran ldd, a toolthat prints shared library dependencies, against eachof the resulting files that were placed in bin or lib

directories. ldd lists packages that are dynamicallylinked, and can also detect static linking. We did notfind widespread use of static linking, of 10,707 fileschecked by ldd, we found only 12 that were staticallylinked.

As illustrated in Figure 5a, we found that Cert-

12

Shim supported 370 of the 395 packages found tobe making SSL connections, for a coverage ratio of94%. Our use of the word “support” can be inter-preted as follows – this application may make anSSL connection in execution, and if it does Cert-Shimwill hook it. A stronger assurance about appli-cation behavior would have required dynamic analy-sis, which was not feasible. A summary of our resultscan be found in Table 4 and Figure 5b. The miscella-neous SSL wrappers included QSSL, Pidgin’s PurpleSSL, URLGrabber, Serf, and Neon; for each, we in-spect the source code to confirm that they wrappedOpenSSL or GnuTLS and used one of CertShim’sfunction hooks. The unsupported packages includedpreviously discovered coverage gaps such as NSS, aswell as other wrappers such as KSSL and QCA, forwhich we were unable to confirm support. We notethat this coverage result is an estimate; without dy-namic analysis, it was impossible to definitively con-firm that these applications attempted to make SSLconnections. However, we did confirm that each ofthe applications had code paths that made web re-quests with SSL-ready libraries.

5.2 Performance

We generated several benchmarks for the baselineperformance of CertShim, performing tests on a DellPC running a Linux 3.5 kernel with 2 GB of RAM anda Pentium 3Ghz dual-core processor. We measuredthe time it took the wget utility to retrieve a small, 9KB file over HTTPS from a nearby web server. Thiscall triggers the SSL get verify result() function,which is supported by CertShim. The throughputof the connection to the server was approximately 80MB per second. The server was using a CA-signedcertificate, which was validated by wget during thecourse of the download. Each of these results wereaveraged over 500 measurements. When CertShimwas not loaded, wget returned in 88 ms. WhenCertShim was loaded without a verification mod-ule, the operation completed in 108 ms, imposingjust 20 ms base overhead on OpenSSL. This over-head is largely due to the CertShim hooks for theconnect() and getaddrinfo() functions, which col-lect contextual data that is required by the hooked

OpenSSL and GnuTLS functions and write it to aSQLite database. The policy engine demonstratedan average run time of just 0.061 ms while parsingthe sample configuration file and initializing the poli-cies. When using an 86 kilobyte configuration fileconsisting of 392 policies, the policy engine requiredan average run time of 3.075 ms. Both of these aver-ages were observed over 1,000 iterations.

We then repeated these trials with the differentverification modules enabled. The results are sum-marized in Table 5. The minimum time required forConvergence verification was 108 ms, correspondingto the case in which the client already possesses alocally cached copy of the certificate fingerprint; Thetime required to use the DANE module was 7 sec-onds. We attribute this exorbitant cost to the factthat our DANE measurements used https://www.

torproject.org instead of a local server. Tor has9 IP addresses associated with this domain, each ofwhich was sequentially verified by the SWEDE li-brary within our module. We benchmarked Key Pin-ning under two use cases: verification took 130 mswhen visiting a domain for the first time, and 119 mswhen checking a previously-visited domain.

Initially, we observed that the base cost of Cert-Shim was 900 ms. Upon further investigation, werealized that this was due to our SQLite configura-tion; each attempt to open a write transaction tothe database cost approximately 100 ms. To improveperformance, we disabled journaling on the database.We note that this also disabled protections againstdatabase corruption due to hardware failures or un-expected interrupts. In a future iteration of Cert-Shim, we intend to restore these protections whileimposing minimal additional performance cost by im-plementing an in-memory database and opportunis-tically flushing to disk during idle periods.

6 Limitations & Future Work

We now discuss several potential gaps in CertShim’scoverage, as well as possible solutions:

Root Processes. For security reasons, LD PRELOAD

is not permitted by default for processes running asroot; however, support for root can be provided by

13

Module Real TimeOpenSSL w/o CertShim 88 ms [ 84, 92]CertShim Baseline 108 ms [107, 109]Convergence Baseline 108 ms [107, 110]DANE 7 secKey Pinning, First Use 130 ms [120, 139]Key Pinning, Revisit 119 ms [118, 119]

Table 5: Benchmarks for CertShim usage. 95% con-fidence intervals are included in brackets.

symbolically linking a root-owned copy of CertShimto the /lib directory.

Alternative Libraries. CertShim supports mod-ern versions of two of the most popular open sourceSSL libraries, libssl1.0.0 and gnutls26. Thereare many other implementations available, such asPolarSSL and NSS; we have inspected these librariesand believe that CertShim can be extended to sup-port them with only modest additional work. Cert-Shim provides a blueprint for interposing on func-tion calls in any C-based SSL library. Our approachcould be deployed on Windows’ SChannel library asan AppInit DLL.

SSL in Java. Linux dynamic linking cannot beused to interpose on Java libraries. However, in Sec-tion 3.5 we demonstrate that our approach is appli-cable in Java through instrumentation objects.

Static Linking. As our methodology is based on dy-namic linking, CertShim cannot interpose on stati-cally linked executables. In our evaluation, we en-countered one instance of static linking in PHP’scURL wrapper. This limitation could be addressedvia static binary instrumentation through use of toolslike PEBIL [25] and DynInst [6, 8].

7 Related Work

A large body of recent work has sought to better un-derstand and ultimately prevent SSL vulnerabilitiesin non-browser software. Georgiev et al. manuallysurvey different layers of the SSL stack, discoveringpervasive misconfigurations of certificate validationroutines, as well as usage of SSL libraries that are bro-ken by design [19]. Brubaker et al. specifically targetSSL libraries, generating 8 million random permuta-

tions of valid X509 certificates to perform differentialtesting and discover hundreds of certificate validationdiscrepancies [7]. Akhawe et al. [2] considered theissues of TLS errors on the web and notices differ-ences with results from OpenSSL. While these stud-ies makes recommendations based on their findings,there is no mechanism for retrofitting changes intoexisting applications, which we make feasible withCertShim.

Large-scale automated dynamic analysis of SSL us-age requires knowledge of application semantics inorder to trigger SSL connections, and is thereforedifficult on general computing platforms due to thegreat diversity of languages, code paths, and SSL im-plementations; however, recent work has made useof the constrained interfaces of mobile platforms toperform large scale analysis. SMV-Hunter leveragesknowledge of the X509TrustManager interface andAndroid WindowManager to perform user interfaceautomation, triggering SSL connections in hundredsof Android apps to detect MitM vulnerabilities [43].MalloDroid performs static analysis to identify de-viant SSL usage in thousands of apps, but manuallyaudited to confirm vulnerabilities [16].

While the above studies offered recommendationsfor the general improvement of the SSL ecosystem,such as improved app market testing [16], clarifyingSSL APIs [19], or communicating vulnerabilities todevelopers [7], they were unable to introduce system-wide defenses to SSL vulnerabilities in legacy soft-ware. An exception to this is Fahl et al’s RethinkingSSL work, in which an Android patch is introducedthat dramatically improves app security through userinterface warnings, device-specific developer options,and forced certificate and hostname validation [17].While we also introduce a platform-wide defense, ourwork does not require a manufacturer update, or evenadministrator privileges, to put to use. Additionally,where pluggable certificate verification is left to fu-ture work by Fahl et al., we introduce four such mod-ules, and the ability to use them in tandem throughpolicy-specified consensus votes. Our tool, Cert-Shim, works in a considerably more complex envi-ronment than the Android platform, where variousSSL implementations need be considered. Both oursystem and Fahl et al’s experience compatibility is-

14

sues with some programs; however, rather than relyon developers to update their applications, we pro-vide a policy engine that allows for application- ordomain-specific certificate handling.

Rather than re-architecting SSL stacks in the OS,other work has invasive strategies to protecting SSLthat actually closely mirror the attack behaviors.MYTHIS uses a local MitM network proxy as an SSLsecurity layer on android [11]; by anchoring its se-curity in a single-path network probe, MYTHIS de-tects rogue access points [40], but not attacks nearthe server or network interior. Huang et al. embedflash scripts in browser code that “phone home” tothe server, allowing websites to detect the presence offorged certificates [24]. CertShim also behaves sim-ilarly to an attack by hijacking dynamic library calls;however, our solution is a more general one that per-mits multiple trust models and detects wider classesof attacks.

Various proposals in the literature adopt a similardeployment strategy to CertShim. Provos et al. [36]implement privilege separation (Privsep), modifyinga small portion of the OpenSSH source code to per-mit different parts of an application run at differ-ent privilege levels. They demonstrate that thisapproach allowed for interoperability and negligibleperformance costs. Watson et al. [46] present Cap-sicum, a capability-based sandboxing mechanism forUNIX, through the introduction of a library that re-places basic UNIX operations such as fork and exec.They present Capsicum-compliant versions of severalpopular utilities (e.g. tcpdump, gzip), and performmicrobenchmarking to demonstrate small overheadson the modified system calls. The DNSSEC-Toolsproject provided Libval, a shim for the DNS librarythat facilitated the rapid adoption of DNSSEC [44].Our work differs from the Libval in that we targetmultiple SSL implementations used by a greater di-versity of programs, override additional functions inthe Linux networking stack to track SSL flow context,and employ a modular design that supports multipleverification methods.

8 Conclusion

This paper has introduced CertShim, a mechanismthat immediately improves the security of Internetcommunications by interposing on SSL APIs, andeven permits the retrofitting of legacy software tosupport SSL trust enhancements such as Convergenceand DANE. Moreover, we have presented a practicalmechanism for polling the results of multiple verifi-cation methods, further promoting the adoptabilityof CA alternatives by overcoming their usage limi-tations. We have also shown that 94% of the SSLusage in Ubuntu’s most commonly installed packagesare supported by CertShim, and that CertShimsecures applications against some of the most infa-mous SSL vulnerabilities explored in the literature.This work significantly increases system-wide secu-rity of SSL communications in non-browser software,while simultaneously reducing the barriers to evalu-ating and adopting the myriad alternative proposalsto the certificate authority system.

Acknowledgments

We would like to thank Jun Li, Paul van Oorschot,and Patrick Traynor for their valuable comments andinsight. This work is supported in part by the US Na-tional Science Foundation under grant numbers CNS-1118046 and CNS-1254198. Braden Hollembaek wasfunded in part through an NSF REU supplement.

Availability

The code, documentation, and example output toCertShim will be released immediately upon pub-lication.

References

[1] libconfig - c/c++ configuration file library. Available:http://www.hyperrealm.com/libconfig/.

[2] Akhawe, D., Amann, B., Vallentin, M., and Sommer,R. Here’s My Cert, So Trust Me, Maybe? UnderstandingTLS Errors on the Web. In Proceedings of the 22nd In-ternational World Wide Web Conference (WWW 2013)(Rio de Janeiro, Brazil, May 2013).

15

[3] Alicherry, M., and Keromytis, A. D. Doublecheck:Multi-path verification against man-in-the-middle at-tacks. In Computers and Communications, 2009. ISCC2009. IEEE Symposium on (2009), IEEE, pp. 557–563.

[4] Amann, B., Sommer, R., Vallentin, M., and Hall, S.No Attack Necessary: The Surprising Dynamics of SSLTrust Relationships. In ACSAC ’13: Proceedings of the29th Annual Computer Security Applications Conference(Dec. 2013).

[5] Arkko, J., and Nikander, P. Weak Authentica-tion: How to Authenticate Unknown Principals withoutTrusted Parties. In Security Protocols, B. Christianson,B. Crispo, J. Malcolm, and M. Roe, Eds., vol. 2845 ofLecture Notes in Computer Science. Springer Berlin Hei-delberg, 2004, pp. 5–19.

[6] Bernat, A. R., and Miller, B. P. Anywhere, Any-timeBinary Instrumentation. In Proceedings of the 10th ACMSIGPLAN-SIGSOFT Workshop on Program Analysis forSoftware Tools (New York, NY, USA, 2011), PASTE ’11,ACM, pp. 9–16.

[7] Brubaker, C., Jana, S., Ray, B., Khurshid, S., andShmatikov, V. Using Frankencerts for Automated Ad-versarial Testing of Certificate Validation in SSL/TLS Im-plementations. In Proceedings of the 2014 IEEE Sympo-sium on Security and Privacy (San Jose, CA, May 2014).

[8] Buck, B., and Hollingsworth, J. K. An api for runtimecode patching. Int. J. High Perform. Comput. Appl. 14,4 (Nov. 2000), 317–329.

[9] Carly, R. Internet Security provider Comodo’s CEONamed “Entrepreneur of the Year” by Info SecurityProducts Guide. Available: http://www.comodo.

com/news/press_releases/2011/02/comodo-CEO-

entrepreneur-of-the-Year-infosecurity-global-

excellence-award.html, February 2011.

[10] Clark, J., and van Oorschot, P. C. SoK: SSL andHTTPS: Revisiting Past Challenges and Evaluating Cer-tificate Trust Model Enhancements. In Proceedings ofthe 2013 IEEE Symposium on Security and Privacy (SanFrancisco, CA, May 2013).

[11] Conti, M., Dragoni, N., and Gottardo, S. MITHYS:Mind The Hand You Shake - Protecting Mobile Devicesfrom SSL Usage Vulnerabilities. In Security and TrustManagement, R. Accorsi and S. Ranise, Eds., vol. 8203of Lecture Notes in Computer Science. Springer BerlinHeidelberg, 2013, pp. 65–81.

[12] Ducklin, P. The TURKTRUST SSL Certificate Fiasco– What Really Happened, and What Happens Next?Available: http://nakedsecurity.sophos.com/2013/

01/08/Available: the-turktrust-ssl-certificate-

fiasco-what-happened-and-what-happens-next/,January 2013.

[13] Eastlake, D., et al. Transport Layer Security (TLS)Extensions: Extension Definitions.

[14] Eckersley, P. Sovereign Key Cryptography for InternetDomains, 2011.

[15] Edge, J. Mozilla and CNNIC. Available: http://lwn.

net/Articles/372386/, February 2010.

[16] Fahl, S., Harbach, M., Muders, T., Baumgartner, L.,Freisleben, B., and Smith, M. Why Eve and MalloryLove Android: An Analysis of Android SSL (in)Security.In Proceedings of the 2012 ACM Conference on Com-puter and Communications Security (New York, NY,USA, 2012), CCS ’12, ACM, pp. 50–61.

[17] Fahl, S., Harbach, M., Perl, H., Koetter, M., andSmith, M. Rethinking SSL Development in an AppifiedWorld. In Proceedings of the 2013 ACM SIGSAC Con-ference on Computer & Communications Security(New York, NY, USA, 2013), CCS ’13, ACM, pp. 49–60.

[18] Fisher, D. Microsoft Revokes Trust in Five Dig-inotar Root Certs. Wired. Available: http:

//threatpost.com/microsoft-revokes-trust-five-

diginotar-root-certs-mozilla-drops-trust-staat-

der-nederland-cert, September 2011.

[19] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R.,Boneh, D., and Shmatikov, V. The most danger-ous code in the world: validating SSL certificates innon-browser software. In Proceedings of the 2012 ACMconference on Computer and communications security(Raleigh, NC, USA, 2012), CCS ’12, ACM, pp. 38–49.

[20] Gibbs, S. Heartbleed bug: what do you actually need todo to stay secure? Available: http://www.theguardian.

com/technology/2014/apr/10/heartbleed-bug-

everything-you-need-to-know-to-stay-secure.

[21] Grigg, I. VeriSign’s Conflict of Interest Creates NewThreat. Financial Cryptography 1 (September 2004).

[22] Hickman, K., and Elgamal, T. The SSL protocol.Netscape Communications Corp 501 (1995).

[23] Hoffman, P., and Schlyter, J. The DNS-Based Au-thentication of Named Entities (DANE) Transport LayerSecurity (TLS) Protocol: TLSA. Tech. rep., RFC 6698,August, 2012.

[24] Huang, L.-S., Rice, A., Ellingsen, E., and Jackson,C. Analyzing Forged SSL Certificates in the Wild.

[25] Laurenzano, M., Tikir, M., Carrington, L., andSnavely, A. PEBIL: Efficient static binary instrumenta-tion for Linux. In Performance Analysis of Systems Soft-ware (ISPASS), 2010 IEEE International Symposium on(March 2010), pp. 175–183.

[26] Laurie, B., Langley, A., and Kasper, E. Certifi-cate Transparency. Available: ietf. org-Certificate Trans-parency (06.01. 2013) (2013).

[27] Liang, J., Jiang, J., Duan, H., Li, K., Wan, T., andWu, J. When HTTPS Meets CDN: A Case of Authenti-cation in Delegated Service.

[28] Marlinspike, M. More tricks for defeating SSL in prac-tice. Black Hat USA (2009).

16

[29] Marlinspike, M. New tricks for defeating SSL in prac-tice. BlackHat DC (Feb. 2009).

[30] Marlinspike, M. SSL and the Future of Authenticity.Black Hat USA (2011).

[31] Marlinspike, M. Trust Assertions for Certificate Keys.

[32] Mills, E. Comodo: Web Attack BroaderThan Initially Thought. CNET. Available:http://news.cnet.com/8301-27080_3-20048831-

245.html?part=rss&tag=feed&subj=InSecurityComplex,March 2011.

[33] Myers, M. Revocatoin: Options and challenges. In Fi-nancial Cryptography (1998), Springer, pp. 165–171.

[34] Pennarun, A., Allombert, B., and Reinholdtsen, P.Ubuntu Popularity Contest. Available: http://popcon.

ubuntu.com/.

[35] Pieter Lexis. SWEDE - A Tool To Create and Ver-ify TLSA (DANE) Records. Available: https://github.

com/pieterlexis/swede.

[36] Provos, N., Friedl, M., and Honeyman, P. PreventingPrivilege Escalation. In Proceedings of the 12th USENIXSecurity Symposium (2003), pp. 231–242.

[37] Psyced.org. Certificate Patrol. Available: http://

patrol.psyced.org/.

[38] Rivest, R. L. Can We Eliminate Certificate Revoca-tion Lists? In Financial Cryptography (1998), Springer,pp. 178–183.

[39] Sandvik, R. Security Vulnerability Found in Cy-beroam DPI Devices (CVE-2012-3372). Available:https://blog.torproject.org/blog/security-

vulnerability-found-cyberoam-dpi-devices-cve-

2012-3372, July 2012.

[40] Shetty, S., Song, M., and Ma, L. Rogue AccessPoint Detection by Analyzing Network Traffic Charac-teristics. In Military Communications Conference, 2007.MILCOM 2007. IEEE (Oct 2007), pp. 1–7.

[41] Singel, R. Law Enforcement Appliance SubvertsSSL. Available: http://www.wired.com/threatlevel/

2010/03/packet-forensics, March 2010.

[42] Soghoian, C., and Stamm, S. Certified Lies: De-tecting and Defeating Government Interception AttacksAgainst SSL. In Financial Cryptography and Data Secu-rity. Springer, 2012, pp. 250–259.

[43] Sounthiraraj, D., Sahs, J., Greenwood, G., Lin, Z.,and Khan, L. SMV-HUNTER: Large Scale, AutomatedDetection of SSL/TLS Man-in-the-Middle Vulnerabilitiesin Android Apps. In Proceedings of the 19th Network andDistributed System Security Symposium. (2014).

[44] SPARTA, Inc. DNSSECTools: DNSSEC Software Li-braries and Tools. Available: http://www.dnssec-tools.org/.

[45] Vratonjic, N., Freudiger, J., Bindschaedler, V.,and Hubaux, J.-P. The Inconvenient Truth About WebCertificates. In Economics of Information Security andPrivacy III, B. Schneier, Ed. Springer New York, 2013,pp. 79–117.

[46] Watson, R., Anderson, J., Laurie, B., and Kennaway,K. Capsicum: practical capabilities for UNIX. In Proceed-ings of the 19th USENIX Security Symposium (2010).

[47] Wendlandt, D., Andersen, D. G., and Perrig, A. Per-spectives: Improving SSH-style Host Authentication withMulti-Path Probing. In USENIX 2008 Annual TechnicalConference (Boston, MA, 2008), ATC’08, pp. 321–334.

17