To Pin or Not to Pin—Helping App Developers
Bullet Proof Their TLS Connections
Marten Oltrogge and Yasemin Acar, Leibniz Universität Hannover; Sergej Dechand andMatthew Smith, Universität Bonn; Sascha Fahl, Fraunhofer FKIE
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/oltrogge

This paper is included in the Proceedings of the24th USENIX Security Symposium
August 12–14, 2015 • Washington, D.C.
ISBN 978-1-931971-232

Open access to the Proceedings ofthe 24th USENIX Security Symposiumis sponsored by USENIXTo Pin or Not to Pin
Helping App Developers Bullet Proof Their TLS Connections
Marten Oltrogge, Yasemin Acar
DCSEC, Leibniz University Hannover
oltrogge,acar@dcsec.uni-hannover.de

Sergej Dechand, Matthew SmithUSECAP, University Bonndechand, smith@cs.uni-bonn.de

Sascha Fahl
FKIE, Fraunhofer
fahl@fkie.fraunhofer.de
Abstract
For increased security during TLS certiﬁcate validation, a common recommendation is to use a variation of pinning. Especially non-browser softwaredevelopers are encouraged to limit the number oftrusted certiﬁcates to a minimum, since the default
CA-based approach is known to be vulnerable to serious security threats.
The decision for or against pinning is always a tradeoﬀ between increasing security and keeping maintenance eﬀorts at an acceptable level. In this paper,
we present an extensive study on the applicabilityof pinning for non-browser software by analyzing
639,283 Android apps. Conservatively, we propose
pinning as an appropriate strategy for 11,547 (1.8%)
apps or for 45,247 TLS connections (4.25%) in our
sample set. With a more optimistic classiﬁcation ofborderline cases, we propose pinning for consideration for 58,817 (9.1%) apps or for 140,020 (3.8%1 )TLS connections. This weakens the assumption thatpinning is a widely usable strategy for TLS security
in non-browser software. However, in a nominalactual comparison, we ﬁnd that only 45 apps actually implement pinning. We collected developer
feedback from 45 respondents and learned that only
a quarter of them grasp the concept of pinning, but
still ﬁnd pinning too complex to use. Based on their
feedback, we built an easy-to-use web-applicationthat supports developers in the decision process andguides them through the correct deployment of apinning-protected TLS implementation.

1

Introduction

Android is the major platform for mobile users andmobile app developers. Many apps handle sensitive
1 This smaller percentage in the optimistic case is caused

by a diﬀerent prevalence of third party library use.

USENIX Association

information and deploy the transport layer security
protocol (TLS) to protect data in transit. Previous
research uncovered security issues with TLS in mobile apps [7, 8, 9, 2, 22] that highlight that developers
have problems with implementing correct certiﬁcate
validation while users are challenged by TLS interstitials. Furthermore, the default TLS implementation
on Android receives criticism [24, 18]: Adopted fromweb-browsers, default TLS certiﬁcate validation relies on a huge number of root CAs pre-installed on
all Android devices [24]. Hence, all Android apps
suﬀer from the same issues as web-browsers: A single
malicious CA is able to conduct Man-In-The-Middle
attacks (MITMAs) against all apps trusting the respective certiﬁcate. To make things even worse, Fahl
et al. [8] uncovered that in 97% of all cases wheredevelopers implemented their own certiﬁcate validation strategy, they turned oﬀ validation entirely andleft their apps vulnerable to MITMAs with arbitrarycertiﬁcates, i.e. every active network attacker wasable to attack successfully.
Pinning is often recommended as a general countermeasure to tackle the weakest link in the CAbased infrastructure [1, 14, 17, 8]. We use the term
pinning in this paper to include both pinning thecomplete X.509 certiﬁcate or only the certiﬁcate’s
public key. Instead of trusting a large set of root
CAs that come pre-installed with the operating system, software limits the set of certiﬁcates it trusts
to pins, which can be single leaf certiﬁcates, single
root CA certiﬁcates or a set of certiﬁcates. Pinning is a straightforward mechanism and its deployment does not require changes to the current
CA infrastructure. However, pinning has not foundwidespread adoption yet. While limiting the numberof trusted certiﬁcates drastically increases security,
pinning doesn’t come for free: Embedding trusted
certiﬁcates into an app requires app updates whenever the pins change. Hence, the decision whether

24th USENIX Security Symposium 239

Take-aways We formulate lessons learned during
our evaluation to share them with the research community.

pinning is applicable for a TLS connection is always
a trade-oﬀ between increased security and maintenance eﬀort that is not entirely under the control
of an app developer: Whenever users do not update
their app although the pins have changed, the app
stops working and users might uninstall the broken
app. Therefore, to pin or not to pin is a critical decision for app developers, which requires in-depth understanding of the mechanisms behind pinning and
its implications on their apps. This is where ourwork comes in: To the best of our knowledge, weare the ﬁrst to explore the applicability of pinning
as an appropriate alternative certiﬁcate validation
strategy for non-browser software. In this paper, we
make the following contributions:

2

Background and Motivation

To establish secure TLS connections, certiﬁcate validation is important in order for communication
partners to authenticate remote endpoints. Therefore, Android and most other non-browser software
adopted the in-browser certiﬁcate validation strategy, i.e. applications trust a predeﬁned set of root
certiﬁcate authorities (root CAs). When attempting
to establish a secure connection, the server provides
the client with a certiﬁcate chain.

Status Quo We evaluate the status quo and analyze 639,283 Android apps to ﬁnd that only 45 apps
implement pinning.

2.1

Formalization Instead of intuitively recommending pinning, we formalize criteria that must be considered when the decision is made whether to pin or
not to pin.

Default Certiﬁcate Validation

Certiﬁcate chain validation works as follows:
Chain of Trust Based on the certiﬁcate chain
sent by the server, the client tries to build the chainof trust beginning at the server’s leaf certiﬁcate up
to one of the root CA certiﬁcates. Every certiﬁcatein the chain is checked for validity – i.e. it is not
expired and it is signed by its immediate successor
in the chain. The second last certiﬁcate in the chain
must be signed by one of the root CAs installed on
the user’s device [3]; the last certiﬁcate in the chain
belongs to the signing root CA.

Implementation We apply static code analysis
and program slicing to automatically assess thosecriteria and obtain an overview of the situation for
single apps.
Evaluation We evaluate our criteria against a setof 639,283 Android apps for an overview of the applicability of pinning in the Android universe. We
ﬁnd that 223,655 apps establish TLS-secured connections to remote origins; 11,481 (5.13%) of these
223,655 apps are eligible candidates to implement
pinning for one or more of their TLS connections.

Hostname Veriﬁcation A certiﬁcate is bound toa certain identity – in this case a particular hostname
or a set of hostnames. During hostname veriﬁcation,a client veriﬁes this identity by checking whether
the hostname can be matched to one of the identities (i.e. CommonName, SubjectAltName [20]) for
which the certiﬁcate was issued.

App Updates Since new certiﬁcate pins need to
be updated on the users’ devices, the update speed
is crucial. Therefore, we instrument telemetry datafrom a popular anti-virus software provider. We
evaluate the update behaviour of 871,911 uniqueusers from January 2014 to December 2014 and ﬁndthat only 50% of the users update to a new app
version within the ﬁrst week after release.

Further checks Complete certiﬁcate validation
may include further checks, e. g. certiﬁcates haveto be checked for revocation which is done via a certiﬁcate revocation list (CRL)[3] or Online Certiﬁcate
Status Protocol (OCSP)[21].

Developer View Although pinning is only applicable in relatively few cases, the nominal-actual
comparison leaves room for improvement. We therefore collected feedback from 45 developers of apps
for which we would recommend pinning. We identiﬁed the developers’ major issues with pinning andused their feedback as the foundation to build aneasy-to-use web application that assists developers
with securing their apps’ TLS connections. We oﬀer
help on the decision whether to pin or not to pin andsupport the implementation of pinning with concretesuggestions and code examples.

2.2

MITM Attack

In a Man-In-The-Middle attack (MITMA), the attacker is in a position to intercept network communication. A passive MITMA can only eavesdrop on thecommunication, while an active MITMA can also
tamper with the communication. Correctly conﬁgured TLS together with proper certiﬁcate validation
is fundamentally capable of preventing both passive
and active attackers from executing their attacks.
2

240 24th USENIX Security Symposium

USENIX Association

2.3

Alternative Validation Strategies• Application developers might want to use a selfsigned certiﬁcate either for testing, eﬀort- or
economical reasons;Over the years, alternative certiﬁcate validation
strategies have come up [12, 26, 16, 15, 10, 17].
While they all provide approaches to check a certiﬁcate chain’s validity, our paper focuses on pinning [17] as one of the most recommended alternative strategies for non-browser software.
2.3.1• When a root CA is not in the system-wide listof trusted root CAs, a company might have aninternal CA that issues certiﬁcates for use in
intranet applications;• Security can be enhanced by restricting relianceon the PKI to mitigate the exposure to weaknesses in the PKI

Pinning

Pinning is a notion of certiﬁcate validation that uses
existing knowledge about the network origin or thecertiﬁcation data presented to protect the TLS connection [17]. Required parameters to be pinned need
to be available in an application before the TLS
handshake happens. Pinning can be achieved basedon diﬀerent parameters (e.g. public key, whole certiﬁcate).
Pinning can also be applied to diﬀerent subjects:
Leaf Pinning Leaf pinning includes pinning a single leaf certiﬁcate or its public key or a set of leaf
certiﬁcates or their public keys and is the most rigorous way of pinning.
CA Pinning Certiﬁcate authority pinning eﬀectively limits the number of trusted certiﬁcate authorities and allows for more ﬂexible reconﬁgurationof deployed TLS certiﬁcates. This includes both intermediate and root CAs.
2.3.2

• and custom implementations are required to implement leaf or CA pinning.

2.5

Recently, TLS has been subject to urgent ﬂaws.
Studies by Fahl et al. [7] and Georgiev et al. [9]uncovered a disastrous state of TLS-Code. Georgiev
et al. [9] show numerous ﬂaws in non-browser TLSCode. Fahl et al. [7] identify numerous applications
featuring erroneous custom TLS-code that potentially renders applications vulnerable to MITMAs.
This is caused by incorrect implementations of custom certiﬁcate handling. Investigations on the reasons illustrate that especially developers without asecurity focus are unaware of the correct use of
the APIs that Android provides: They carelessly
incorporate code snippets from platforms such as
stackoverflow.com [8]. In particular, self-signed
certiﬁcates used during development lead to erroneous code that makes applications vulnerable bydeactivating certiﬁcate validation completely.
Both of the above investigations [7, 9] focusedon the diﬃculties experienced by developers with
the implementation of correct certiﬁcate validation. However, they discuss possible countermeasures rather sketchily and do not evaluate the applicability of pinning for non-browser software.
To improve the state of erroneous certiﬁcate handling and to mitigate the threats, Fahl et al. [8] suggest to completely disallow custom code. Instead,they propose a framework that allows to realize common use-cases (e.g. self-signed certiﬁcates for testing, pinning, default warning messages, etc.) by conﬁguration without the developer writing any TLSrelated code. Tendulkar and Enck [23] suggest a similar approach. However, although both approaches
try to improve the usability of certiﬁcate handlingfor software developers, they do not support developers in the decision process of whether pinning is arecommendable certiﬁcate validation strategy.

Trust on First Use (TOFU)

Another notion of pinning is trust on ﬁrst use(TOFU). Instead of knowing the information to bepinned in advance, the ﬁrst certiﬁcate (leaf or CA)
seen for a TLS connection is stored locally on theclient side and used to validate certiﬁcates for further connections. Hence, TOFU can be seen as a mixof conventional pinning (cf. Section 2.3.1) and thedefault validation strategy. TOFU is used to secure
SSH connections and is an opt-in feature for HTTPS
webservers for which it is called HTTP Public Key
Pinning (HPKP [5]). As of today, HPKP has notfound widespread adoption on the web [11].

2.4

Related Work

Flaws in client implementations

The Android platform provides built-in functionalities for handling TLS and certiﬁcate validation
based on the PKI without further conﬁguration. It
comes pre-loaded with an extensive truststore featuring 140+ root CAs [18]. Additionally, the Android framework enables developers to provide custom implementations for handling certiﬁcate validation. There are several reasons for developers to use
custom implementations:
3
USENIX Association

24th USENIX Security Symposium 241

3

An Exit Strategy

tom certiﬁcate veriﬁcation strategies for 639,283 Android apps. Therefore we used MalloDroid [7] andextended the classiﬁcation feature of custom veriﬁcation implementations. We focused on both customized implementations of the TrustManager interface and the usage of a custom KeyStore for TLS
certiﬁcates.
Whenever we found that a KeyStore object was
created, we conducted a reachability analysis [13] forthis object. For objects that were reachable from anapp’s entry point, we assume that this app uses pinning. Next, we extracted the keystore ﬁle that wasloaded to check whether leaf or CA certiﬁcates were
pinned. We found 21 apps that implement pinning
using the keystore method. 13 of these apps pin aleaf certiﬁcate, while 8 of them pin a custom root
CA certiﬁcate.
Whenever we found a TrustManager implementation, we checked whether the chain parameter of thecheckServerTrusted method was accessed by the
implementation. Implementations that do not use
this parameter do not verify the remote origin’s certiﬁcate chain and hence were removed from further
analyses. In a second step we conducted a reachability analysis for implemented TrustManager objects and removed all implementations that were notreachable from an app’s entry point. We found custom TrustManager implementations in 42,902 apps
and could remove 42,042 apps from the list since
they either implemented bypassing TrustManagers
or were not reachable. The remaining 858 apps implemented 189 diﬀerent TrustManagers. We compared these implementations with the list provided
by Fahl et al. [8] and could ﬁlter out 124 implementations that basically add logging for certiﬁcate validation. We manually reviewed the remaining 65 implementations and found that 13 implemented pinning. Overall, these implementations were used by
24 apps.
Altogether, of the 639,283 apps in our data-set, 45
implement pinning. These numbers conﬁrm ﬁndings
already reported by Fahl et al. [8].

Previous work shows that TLS is complex and errorprone. Studies imply that the implementation ofclient code for correct certiﬁcate validation is hardfor software developers. The general trust model
received a lot of criticism over the last years and alternative solutions have not found widespread adoption.
As a general solution for both problems, pinning
is often advocated as a secure and reliable alternative to the default trust model for non-browser
software [17, 14, 1, 8]. Pinning can serve two purposes. First, it can mitigate the risk of MITMAs
as it strengthens the validation process. Secondly,
pinning allows to overcome limitations of the current CA infrastructure, e.g. by allowing self-signed
certiﬁcates.
We challenge the recommendation to use pinningfor non-browser software and conduct a deep analysis on the root causes that hinder its widespread
adoption in non-browser software.

3.1

Pinning in Android Apps

Before evaluating the status quo, we give a brief
overview of how TLS pinning can be implemented
in Android apps. In general, Android apps can establish low-level TLS connections via an SSLSocket
or an HTTPSUrlConnection object. Using pinningin these cases requires the developer to implement acustom version of Android’s TrustManager interface
with an appropriate checkServerTrusted method.
This method has to check whether the certiﬁcate
sent by the remote server matches one of the given
pins. Another option is to use a custom KeyStorein which developers can store their own certiﬁcates.
Many Android applications do not make use ofsuch lower level APIs but use a WebView to display
HTML directly. Sadly Android does not provide
an API to implement pinning for WebViews2 . As aworkaround, developers can download all HTML/JavaScript via the low-level HTTPSUrlConnection,
store it locally and only use the WebView for rendering. However, this is a clear shortcoming of Android’s API and makes the implementation of pinning unnecessarily hard.

3.2

4Classiﬁcation Strategy

The decision whether or not a TLS connection
should be secured by pinning depends on multiple
factors and is not trivial in many cases.
Furthermore, whenever we cannot reliably identify
the origin string for a TLS connection endpoint, wecannot assess whether pinning would be a reasonablevalidation strategy. Therefore, we report our results
for two diﬀerent scenarios:

Status Quo

For a better understanding of the current adoptionof TLS pinning in Android apps, we evaluated cus2 https://code.google.com/p/android/issues/detail?

id=765014
242 24th USENIX Security Symposium

USENIX Association

Conservative We report numbers for a conservative scenario. Whenever we cannot identify the origin string for a TLS connection endpoint, we assume
that pinning is unfeasible. This covers most of ourresults.

developers update their libraries, while app developers can hardly inﬂuence whether library developers
keep their certiﬁcate pins up to date.
For both the conservative and the optimistic scenario pinning is not recommended in case API ownership is not given.

Optimistic For some of the cases where we could
not successfully identify origin strings, pinning could
be applied under certain circumstances. These cases
are treated diﬀerently for the optimistic scenario as
detailed in Section 6.
For our classiﬁcation, we consider the following
properties as high level indicators:

TLS Certiﬁcate Conﬁguration Responsibility
Being responsible for the TLS certiﬁcate conﬁguration as well as being the owner of relevant API calls
eases the coordinated deployment of pinning in apps.
In case developers or their companies have control
over the TLS certiﬁcate conﬁguration of origins used
in apps, both the certiﬁcate pins in apps and thecorresponding server conﬁgurations can be coordinated. In these cases, pinning is feasible. Whenever apps communicate with public origins, such as
public API interfaces or websites, pinning cannot berecommended. Certiﬁcate conﬁgurations can change
frequently and the responsible administrators only
rarely announce them in advance. Unplanned certiﬁcate changes can lead to failing TLS handshakes
and are therefore unacceptable.
For both the conservative and the optimistic scenario pinning is not recommended in case the developer is not responsible for TLS certiﬁcate conﬁguration.

Prior Knowledge of the Target Origin Priorknowledge about the target origin is vital: Pinningis only feasible if the developer of an app is able
to hard-code target origins into their app. This
includes adding target origins at compile time aswell as via conﬁguration ﬁles before or at run-time.
Whenever target origins depend on user- or external
app input – e.g. via an Intent – at run-time, we
consider pinning as not feasible, since web-browsers
do not automatically pin certiﬁcates for websites forthe same reasons.3 . Automatically pinning previously unknown origins would increase the danger offailed TLS handshakes due to substituted certiﬁcatesand would decrease acceptance of pinning for bothdevelopers and app users.
In the conservative scenario, we recommend thedefault validation strategy for all connections where
the origin depends on external input. However, someof these connections can be pinned in the optimistic
scenario (cf. Section 6).

4.1

Possible Recommendations

The above criteria build the foundation for the decision whether pinning is applicable for a TLS connection in a given app. The classiﬁcation algorithm
recommends one of the following strategies:

Ownership of Relevant API Calls App development consists of writing one’s own code andembedding external libraries. All source code thatwas written by the developer or the developer’s company is considered owned by the developer. API
calls required for certiﬁcate validation during theestablishment of TLS-secured network connections
are relevant for this. Relevant API calls might bea HTTPSUrlConnection or an SSLSocket. Whenever ownership of relevant API calls is given, pinning might be feasible. Library developers do not
own their code when it is included in other apps.
Therefore, we do not recommend pinning for librarycode. Library developers cannot control when app

Leaf Pinning Leaf pinning limits the numberof trusted certiﬁcates to the server’s leaf certiﬁcate/public key (cf. Section 2.3.1).
CA Pinning CA pinning eﬀectively limits thenumber of trusted CAs (cf. Section 2.3.1). We treat
conventional pinning (cf. Section 2.3.1) and TOFU
(cf. Section 2.3.2) equally, since both provide a similar level of security (cf. Section 2.3.1) and require
the same maintenance overhead from an app developer’s point of view.
Default Whenever none of the above criteria applies, pinning is not a recommended strategy andshould not be implemented. This also accounts forcases where external input – e.g. user input in an
address bar or Intent input – inﬂuences a TLS connection.

3 Administrators can conﬁgure HTTP Public Key Pinning(HPKP) to pin TLS certiﬁcates in modern web-browsers.
However, this involves heavy manual conﬁguration work on
the server side and does not happen automatically (cf. Section 2).

5
USENIX Association

24th USENIX Security Symposium 243

4.2

Classiﬁcation Details

Package nameorg.apache.http.client.methods.*org.apache.http.HttpHost
android.webkit.WebView.loadUrl
android.webkit.WebView.loadDataWithBaseURL
android.webkit.WebView.loadData
android.webkit.WebView.postUrl
android.net.http.AndroidHttpClient
java.net.Url

Algorithm 1 illustrates the classiﬁcation process weapply to decide whether pinning is an advisable veriﬁcation strategy. In the initial state, the default
strategy is assumed to be the right choice for a
TLS connection, since we do not know yet if pinning is recommendable. First, we check whether the
TLS connection is established within a third party
library. In this case classiﬁcation ends with the recommendation to use the default strategy, since ownership of the relevant API is not guaranteed.
Second, we check whether the remote origin depends on user input, other external sources such as
Intents, or may be conﬁgured via a conﬁgurationﬁle. In these cases we recommend the default strategy, since control over the remote origin is not guaranteed.
Third, we check whether the TLS connection’s remote endpoint is a popular origin; in this case, classiﬁcation ends with recommending the default strategy, since the TLS conﬁguration of the remote origin is probably not under the developer’s control. If
we assume that a remote origin is probably undercontrol of the developer, as no other app accesses
it, the classiﬁcation continues: We check whether
the origin’s certiﬁcate was issued by a valid CA oris self-signed. For self-signed certiﬁcates and certiﬁcates that were issued by a valid CA, we recommend
leaf certiﬁcate pinning. For certiﬁcates issued by an
untrusted CA, we recommend CA pinning, since thecustom CA is probably under control of the developer.

4.3

Table 1: Relevant API Calls.
4.3.2

As described above, knowing remote origins in advance is crucial for pinning. At this point, we focus
on extracting whether a remote origin is embedded
in an app or depends on user input or is injected
via an external interface such as an Intent. This
information is supplied via parameters to relevant
API calls. Although these mainly refer to Stringvalues, the object-oriented and Java-based nature of
the Android platform introduces complexity:• Strings may not be constant values but can becomposed of numerous substrings. We identify
concatenation of Strings, formatting of Stringsand platform-speciﬁc APIs for building URIs
as relevant. Therefore, we statically backtrackthese and reproduce String values.
• Values can stem from variables or may be return
values of method calls. Therefore, we accountfor intra-application method calls as well.
• Values that stem from Resources, Properties
or Preferences hint at conﬁguration parameters.

Challenges

For our strategy classiﬁcation, we apply static codeanalysis on a large set of Android apps. To work
as eﬃciently as possible, we identiﬁed multiple challenges:
4.3.1

Embedded Static TLS Origins• Origins can be input parameters for application entrypoints. Entrypoints are parts of an
application that allow either other app components, external apps or users to interact with
an app. Android application entrypoints are
Activities, Services, Receivers, Intents
and Bundles. UI-Components in Activities
hint at user input.

Relevant API Calls

First, we identify relevant API calls, which means
taking remote origins as parameters and establishing a TLS-secured connection between the app andthe origin. The oﬃcial Android API documentation identiﬁes relevant API calls in the packages presented in Table 1.
These API calls are the most low-level calls in the
API and they implicitly include higher level APIs
such as the HTTPSUrlConnection.

4.3.3

API Call Ownership

API call ownership is a requirement for pinning. To
identify whether an app developer holds ownershipof relevant API calls, we must distinguish relevant
API calls that are accessed by third party libraries
and relevant API calls accessed by code that was6

244 24th USENIX Security Symposium

USENIX Association

Algorithm 1: The Classiﬁcation Process.
for r ∈ results dodependencies ← dependencies(r);set strategy as default;
if dependencies = 0/ thenif ∃d ∈ dependencies|d ∈ {exposed intent,UI −Component} thencontinue;else if ∃d ∈ dependencies|d ∈ {unexposed intent, variable, con f iguration} thencontinue;
if not callInLibrary(r) and not isPublicHost(r) thenhost ← host(r);schema ← schema(r);cert ← cert(r);dependencies ← dependencies(r);if isUnderControl(host) thenif signedByUntrustedCA(cert) thenmark for CA pinning;else if validCertChain(cert) or isSel f Signed(cert) thenmark for leaf pinning;

written by the app developer (we call this customcode). Whenever we ﬁnd relevant API calls in codethat is shared between multiple apps by diﬀerent authors, we assume a library that is not under control
of an app’s developer.
4.3.4

2. Identify relevant API calls – i.e. API calls that
implement TLS connections in apps (cf. Sections 5.2 and 4.3.1).
3. Extract information for remote origins applying
program slicing (cf. Sections 5.3 and 5.3.1).
4. Determine whether API and/or origin ownership for relevant API calls is given and decide
which certiﬁcate validation strategy suits best(cf. Sections 4.2 and 5.4).

Origin Exclusivity

Whenever the TLS conﬁguration of a remote origin
is not in the range of inﬂuence of the developer, pinning is not advisable. We classify origins that areshared between multiple apps’ authors and connections that access public origins as not under controlof the developer.

5

5.1

Disassembly

In Step 1, we use androguard [4] to disassemble apps
and construct call graphs for further processing.

5.2

Implementation Details

Relevant API Calls

In Step 2, the call graphs were used to identify appsthat make use of API calls in which origin information for establishing TLS-enabled connections is
speciﬁed (cf. Section 4.3).
We consider API calls as relevant if they are usedduring the process of TLS connection establishment(cf. Table 1).

To decide whether pinning for a TLS connection isadvisable and to address the above challenges (cf.
Section 4.3), we implement our classiﬁcation strategy in a multi-step process. We extend4 the MalloDroid tool [7] and execute the following steps:
1. Disassemble a given Android application to gain
access to the application’s code and call graph(cf. Section 5.1).

5.3

Program Slicing

In Step 3, we apply backwards program slicing [25]to collect method parameters which we subsequently
call slicing criteria. We focus on slicing criteria that

4 Our

MalloDroid extension is available at https://github.com/sfahl/mallodroid.

7
USENIX Association

24th USENIX Security Symposium 245

represent remote origins which are used as input for
relevant API calls, i. e. we are backtracking parameters that are URLs or hostnames for TLS connections.
Our approach is similar to the one applied by Poeplau et al. [19], who apply a backward slicing algorithm to identify security issues with dynamic codeloading in Android apps.
In contrast to backwards slicing single and ﬁxed
method parameters, our targets are network origins.
A network origin String can be a composition ofmultiple substrings. We take this fact into accountby applying backwards slicing for multiple parameters. After backtracking, we join these (multiple)
substrings to one origin string whenever possible. To
break cycles, we stop the slicer after 80 iterations,which guarantees that the algorithm terminates andalso makes sure we do not lose data.
5.3.1

Algorithm 2: StringBuilder Analysis
Data: stringBuilderObjects sbos
Result: new originSubstring O
begin
for sb ∈ sbos domethodInvocations ←methodsOnInstance(sb);originSubstrings ← 0;/
origin ← null;for mi in methodInvocations do
if isAppend(mi) thenoriginSubstring ←backtrack(mi.regs[1]);if originSubstring = null thenadd(originSubstrings,
originSubstring);
else if isToString(mi) thenbreak;
join(O, originSubstrings);

Extracting Origin Strings

Origin strings can be compositions of multiple substrings (e.g. https:// and www.example.com and:443). Thus, reconstructing an origin string might
require combining multiple sliced substrings. Therefore, after program slicing, we apply a combinationof backward and forward analysis. Backwards analysis is used for backtracking constant register values
while forward analysis determines calls of a String
instance. Both, back- and forward analyses are applied multiple times successively as long as we ﬁnd
new substrings that are part of a ﬁnal origin string.
Algorithm 2 outlines pseudocode for handling
StringBuilder objects. The algorithm makes useof the following functions:

new-instance instruction referring to theStringBuilder constructor) and store them insbos.
2. Find all method invocations
StringBuilder object sb;

for

each

3. For calls of the constructor or the append()
method, backtrack the register value for theString parameter originSubstring and add
it to all originSubstrings.
4. Stop on calls of the toString method andjoin all collected originSubstrings to a new
originSubstring.

methodsOnInstance returns a list of all method
invocations on an instance (e.g.
calls totoString, append or the constructor for
StringBuilder objects).

Similarly, we support String concatenation, formatting Strings, UriBuilder instances, Android
UI-Components, Intents, Bundles, Properties,
Preferences and Resources. For Intents andBundles we identify the source in order to determine whether the corresponding component is exposed externally, e.g. via a Service.

backtrack applies the actual backtracking techniques to gather all substrings for the origin
string composition.
add adds one originSubstring to the array oforiginSubstrings that make the origin string
we are looking for.

5.4

join merges all originSubstrings to get the ﬁnal
origin string that is represented by the given
StringBuilder object.

Decide on Validation Strategy

In the ﬁnal Step 4, we assess whether API and/or
origin ownership is given (cf. Section 4). For pinningcandidates, X.509 certiﬁcate information is collected
and a decision for or against pinning is made (cf.
Section 4.2).

1. Identify instructions indicating the instantiation of a StringBuilder object (i.e.
a8
246 24th USENIX Security Symposium

USENIX Association

5.5

Limitations

Overall
Hard-coded HTTPS Origin
Hard-coded HTTP Origin
Non-hard-coded Origin

The described approach is limited in multiple ways.
We decided to reverse engineer a large sample of free
Android apps and analyze the resulting code. This
limits the analysis compared to the analysis of original source code, e.g. we lose variable names andcannot preclude obfuscation. This is however thestate of the art for large scale app analyses, sincereaching out to developers and asking for source code
does not scale well. We apply static code analysis
and program slicing to determine the best certiﬁcate
validation strategy to secure a TLS connection. Our
approach does not consider native code in Android
apps. We cannot track potential TLS connections incode that was dynamically loaded or when obfuscation was applied.
Since we apply static code analysis techniques, wemight report some false positives: Some of the TLS
connections we found and identiﬁed as being reachable code might not be used during real application usage. However, this is not a speciﬁc limitationof our work, but a general limitation of static codeanalysis.
We might also report some false negatives: Due tothe strategy to classify origins to which apps developed by diﬀerent developers connect as “not undercontrol of the developer”, we might miss the scenario that one company has several distinct developers write apps for them that all access the same
domain. However, there exist no criteria to distinguish these cases from the common scenario thatmultiple apps by diﬀerent developers accessing thesame domain means that the domain is not undercontrol of the developers. Therefore, these cases areincluded in the group of public origins for which we
do not recommend pinning.

6

Third Party Libraries
Hard-coded HTTPS Origin
Hard-coded HTTP Origin
Non-hard-coded Origin

Custom CodeHard-coded HTTPS Origin
Hard-coded HTTP Origin
Non-hard-coded Origin

Con.

Apps

1,062,810
2,420,104
16,537,621

229,317414,194553,399

20,020,535

573,258

Con.

Apps

917,567
1,659,933
14,564,581

203,159
310,331512,055

17,142,081

517,790

Con.

Apps

145,243
760,171
1,973,040

48,755
184,184
246,636

2,878,454

299,863

Table 2: Distribution of Network API Calls.
tify 1,062,810 calls as TLS connections due to thefact that the corresponding origin string’s scheme
was HTTPS. 2,420,104 connections were identiﬁed
as plain HTTP, while 16,537,621 connections did nothave a hard-coded origin string in the app’s code.
Hence, for 81% of all connections, it was not directly possible to determine whether TLS was used.
However, a deeper analysis based on our classiﬁcation criteria (cf. Section 4.2) gives detailed insights
into the applicability of pinning. Table 2 gives an
overview of the results.

6.1

Evaluation

Library CodeThe majority of network connections we identiﬁed
were made in third party library code, i. e. users
include third party libraries to make use of external functionality. Such connections can include bothplain and TLS-protected connections. As describedin Section 4.2, we recommend not to use pinningfor those TLS connections, as API ownership is not
given. Of the 20,021,137 TLS connections we could
identify, we found that 17,142,081 (85.6%) connections are embedded in third party libraries.
Table 3 gives an overview of the top 10 third party
libraries we found in our data-set.
Most of the identiﬁed libraries belong toad networks (e.g.
com.google.ads.*), crash
reporting tools or app building kits (e.g.
org.apache.cordova.*) that establish network

We applied the classiﬁcation algorithm (cf. Section4) to a set of 639,283 Android applications we downloaded from Google Play in October 2014. Our data
extraction showed that of these apps, 573,258 implemented network connections.
In the following, we report details of our automated large-scale analysis. We report our results on
a per-connection base (see Figure 2) as well as on a
per-app base (see Figure 1), where an app is counted
as eligible for pinning if at least one of its connections
can be pinned. We distinguish between a conservative and an optimistic strategy rating (cf. Section
4). Altogether we found 20,020,535 calls to network
related API calls (cf. Table 1). For these calls wetried to identify the origin strings. We could iden9
USENIX Association

24th USENIX Security Symposium 247

Shared Origin
Unique Origin(d.a.b.c)Internal Intent
Public Intent
ParcelUI Component
Resource(Shared) Preference
Variable
JSON

connections without any interaction with an app’s
custom code.
We found the AndroidPinning library5 to be theonly library that supports pinning as a security feature out of the box. However, in our data-set wefound only 14 apps that made use of this library (cf.
Section 3.2).

99,99645,247

40,691
11,547145,243

45,549

-

-





Con.

Apps

294,846
14,5995,729
31,266124,356
87,051
432,985
96,43881,0408,268
2,883
18,76632,113
31,975
119,406
32,200-

1,973,040

326,651

-






(b) Dynamic Origins in Custom Code.

Custom Code

Table 4: Origins in Custom Code – Connections
marked with  can be pinned.

Next, we identiﬁed network connections that were
established in code that was actually written byapps’ developers, i.e. network-related API objects
were not instantiated within third party libraries.
We found 2,878,454 connections in custom codeof which we identiﬁed 145,243 as TLS connections.
48,755 apps implemented hard-coded TLS origins as
parts of their custom code. Based on the type of the
deployed certiﬁcate and depending on whether theorigin is shared, we evaluated which of these TLS
connections are candidates for pinning.
For 1,973,040 of the connections that were implemented as part of apps’ custom code, we could not
identify hard-coded origins in apps. Those connections could be either HTTP or HTTPS and depend
on further input available only at run-time, e.g. user
input or Intents. For these connections, we consider a conservative as well as an optimistic scenario.
Based on diﬀerent assumptions, these scenarios allow us to estimate the applicability of pinning in
Android apps.
6.2.1

Apps

(a) HTTPS Origins in Custom Code.

Table 3: Top 10 Third Party Libraries.

6.2

Con.

Optimistic

2,535,020
1,145,108
977,298
730,408551,373
488,143
352,855
340,929
276,988234,130

O

com.google.ads.
*org.apache.cordova.
**
com.qbiki.
com.millennialmedia.
**
com.facebook.
*com.Tobit.
*
com.inmobi.
*
com.ﬂurry.
*com.startapp.
*com.adsdk.

Conservative

Connections

C

Library

connections that connect to the same origin and theorigin’s X.509 certiﬁcate whenever possible.
The 145,243 TLS connections we found included
connections to 11,203 diﬀerent TLS-enabled remoteorigins.
To investigate whether pinning is the recommendable validation strategy, it is important to know if
an origin is shared between multiple apps authoredby multiple developers or used by apps of a single
developer only (cf. Section 4).
Shared Origins 1,301 of the extracted 11,203
hosts were present in multiple apps that were authored by multiple developers. We assume thesehosts not to be under the control of an app’s developer and hence recommend the default certiﬁcate
validation strategy, since host-ownership is not given(cf. Section 4). This aﬀects 99,996 of the TLS connections we identiﬁed in our data-set (cf. Table 4a).
Table 5 lists the top 10 shared origins in custom
code we found in our data-set.

Hard-coded Origins

Overall, we found 145,243 hard-coded HTTPS connections and 760,171 hard-coded HTTP connections
in our data-set. For the HTTPS connections, wecollected further information such as the number of

Unique Origins 6,012 origins were unique to one
single app while 3,890 origins were included in no
more than ﬁve apps owned by a single developer.
Hence, we assume 9,902 origins to be under the con-

5 https://github.com/moxie0/AndroidPinning10
248 24th USENIX Security Symposium

USENIX Association

Appsgraph.facebook.com
m.facebook.com
www.googleapis.com
bugsense.appspot.com
www.starbucks.com
www.facebook.com
docs.google.com
mobileclient.paypal.com
api.twitter.com
svcs.paypal.com

Con.

Hostname

220,697
110,903
30,101
18,402
32,06339,96929,24039,21434,641
38,175111,559
104,745
20,12018,28516,02913,923
11,872
10,963
10,551
9,999

Type

Con.

Apps

40,433
1,966
269
1,709
870

10,176
486
81
546
258

45,247

11,54744,978269

11,24781

Table 7: Pinning Statistics (Conservative).
6.2.2 Dynamic Origins
While the unique origins in custom code are goodcandidates for pinning, the majority of origins forconnections in custom code were not hard-coded into
the apps at compile time (cf. Table 4). These connections’ origins can depend on diﬀerent external
factors such as Intents, UI components etc.
For these connections, we distinguish two scenarios:

trol of a single developer each. We recommend pinning for these apps and their connections, since bothhost- and code-ownership are given (cf. Section 4).
This aﬀects 45,247 TLS connections in our data-set(cf. Table 4a).
To determine whether leaf pinning or CA pinningis the right choice, we analyzed the deployed certiﬁcates for the respective origins. Overall, we gathered
7,941 unique certiﬁcate chains. We used Androids
pre-installed root CA certiﬁcates and Androids certiﬁcate validation strategy to verify the validity ofthe origins’ certiﬁcates and found that 7,177 of all
chains could be veriﬁed successfully, while veriﬁcation failed for 764 chains. Of these non-validating
certiﬁcate chains, 182 certiﬁcates were self-signed;
170 certiﬁcates were issued by an unknown CA; 335
certiﬁcates were already expired and for 160 certiﬁcates hostname veriﬁcation failed. Table 6 gives an
overview of the chains and the aﬀected connections
and apps in our data-set.

Chain Ok
Self-Signed
Custom CA
ExpiredHostname Mismatch

Apps

Leaf Pinning
CA Pinning

Table 5: Top 10 Remote Origins.

Veriﬁcation Result

Connections

Conservative In the conservative scenario, we assume that connections that use dynamic origins cannot be pinned. This assumption prevents us fromover-reporting the applicability of pinning, but probably underestimates its applicability as well. Assuming this scenario, 45,247 of the 1,062,810 TLS
connections we found in our data-set would be good
pinning candidates, which makes up 4.25%.
Optimistic In this scenario, we assume some of
the 1,973,040 dynamic origins connections eligible
for pinning. We still assume that connections that
get their input from Public Intents, Parcels and UIComponents are no good pinning candidates, since
the app developer probably does not have control
over the actual origin strings values. That leaves
some of the remaining 1,921,446 connections that
depend on dynamic origin strings eligible for pinning. We assume that – as for the custom codewith hard-coded origins – 16% of all connections are
HTTPS connections (cf. Table 4), which leaves us
with 307,431 HTTPS connections. If we again assume that, like for the hard-coded custom code origins, 31.1% of the HTTPS connections can be pinned(cf. Table 4), we can recommend 95,611 connections
for pinning. In combination with the 45,247 connections from the conservative scenario, we recommend
to pin 140,858 connections in the optimistic scenario.
However, while only 86.33% of all known HTTPS
connections are implemented in third party librarycode, but 88.07% of our assumed HTTPS connections happen via third library code, the connections
we optimistically recommend for pinning make up
only 3.8% of all (assumed and deﬁnite) HTTPS connections (as opposed to 4.25% for deﬁnite HTTPS
connections). We can optimistically pin 140,858 con-Table 6: X.509 Certiﬁcates Statistics.
We recommend pinning for all of these connections(cf. Section 4). We recommend leaf pinning for theconnections that use a self-signed certiﬁcate and CA
pinning for all other connections (cf. Table 7).
11
USENIX Association

24th USENIX Security Symposium 249

nections as opposed to only 45,247 connections in theconservative case. Naturally, we are unable to specify which pinning strategy we would suggest, but
extrapolating from the conservative scenario i.e. applying the percentages of which pinning strategy isapplicable in the small conservative data-set to thelarger data-set, 140,020 cases would be eligible forleaf pinning, while we would recommend CA pinning for 838 connections.

6.3

Update Frequencies

Figure 1: Statistics and Classiﬁcation Results forApps; Network Access includes apps with customcoded, library- and dynamic HTTPS and HTTP
connections.

Pseudonym We assigned a 256-bit random
pseudonym to each device to protect the users’
privacy. The pseudonym did not reveal any
private information.
DeviceInfo We collected manufacturer- and device
model information as well as the installed Android version.
DeviceFlags We gathered three diﬀerent ﬂags forevery device: (1) Whether developer options
were enabled, (2) whether app installs from untrusted sources were allowed and (3) whether
USB debugging was enabled.
PackageInfo For every (pre-)installed app we
gathered the package name and version code.
PackageHashes For every (pre-)installed app we
gathered SHA256 checksums of the packages
and their corresponding signing keys.
Timestamps We gathered timestamps for when wesaw an app version installed on a device.

In addition to the strategy classiﬁcation, a crucial
requirement for pinning to work properly is the possibility to deploy quick updates for apps to distributenew pins. The applicability of pinning for Android
apps in general depends on how quickly developers
can push new certiﬁcate pins to their users’ devices.
Hence, we were interested in assessing the frequency
for app updates.
Although newer Android versions have an auto
update feature for apps, this feature is opt-in. Furthermore, the default is that app updates are only
downloaded in case a device is connected to a WiFi.
Hence, even auto-updates are not guaranteed to happen instantly.
Information about update frequencies is not easily accessible via Google Play. To gain insights into
users’ update behaviour, we cooperated with a popular anti-virus software vendor for Android with an
install base of 5 million devices. Our cooperation
partner runs a telemetry program and gathers user
data for all users that participate in that program.
From January 2014 to December 2014, we collected
data for 784,721 unique apps and 871,911 uniqueusers. The 871,911 users that participated in thetelemetry program and gave their consent to anonymously analyze the data for our research yield thefollowing meta information:

Our interest focused on third party apps suchas facebook or games, as these apps get updates
pushed via Android’s default update mechanism.
We excluded Google apps and device vendor speciﬁc
apps from our analysis, since these can be updated

Figure 2: Statistics and Classiﬁcation Results forConnections.
12
250 24th USENIX Security Symposium

USENIX Association

through special update channels provided by Googleor the device vendor. We identiﬁed Google apps anddevice vendor apps based on the keys they have beensigned with [6].
For third party apps, we found that on average
40% of all users update to a new version on the release day. Around half of all app users update within
the ﬁrst week after release and 70% update within 30
days after release. However, to update all devices,on average 200 days elapse. Figure 3 illustrates theaverage apps update periods.

via conﬁguration ﬁles that can easily be updated via
a secure remote connection. Such an update mechanism could be enforced immediately and developers
would not depend on the (lazy) update behaviourof their users. An alternative pinning deployment
strategy would be to use multiple origins for a TLS
connection, e. g. having pin1.example.com for one
pin version and pin2.example.com for a second version. Both mechanisms allow for out-of-band pin
updates but come with some extra eﬀort on the developers’ side.

7

After conducting a large scale analysis for real world
Android apps and the applicability of pinning, wewere also interested in the developers’ point of viewas the actors who actually implement pinning. First,
we collected informative feedback from developers
to learn more about their view on pinning. Second,
based on their valuable and constructive feedback,
we built a tool that supports developers in the process of deciding whether to implement pinning andeases the implementation.

Figure 3: Average days between the release of a new
app version and its installation.

7.1

These numbers illustrate that app updates are
unsuitable for security-critical app components. In
case of pinning, half of all users of an app would beunable to use the app during the ﬁrst week after the
update is released, since the pinning-secured TLS
handshakes would fail 6 .

6.4

Developer Support

Feedback

We analyzed all apps in our sample set and extracted possible candidates for pinning 7 . For those,
we extracted the email addresses of the developersfrom Google Play, taking care not to create multiple emails for the same recipient, which left us withroughly 3,200 addresses. We emailed a random sample of 500 developers with an introductory email andthe plea to provide us feedback on their experience
with pinning, or, if they were not the developer, toplease forward the email to their app’s developer.
Our outreach to developers was intended for a qualitative analysis of their feedback and comments to
be used as the foundation to build our tool. A quantitative analysis was not our primary focus. We wereable to gather 498 responses, of which we manually
removed 4 who had answered in a nonsensical way
or who clearly did not understand English. After
we analyzed the 45 responses, we had gained insight
into the major problem areas, a saturation of new input was reached and more responses would probably
not have provided more valuable insights.

Discussion

Our results have multiple major implications: Themajority of TLS connections happen in third party
libraries (86.33%) and another 68.85% of connections are established with shared hosts. However, although only 4.25% of all TLS connections seem to begood candidates for pinning, the current situation of
only 45 apps that actually implement pinning leaves
much room for improvement. An additional hurdle
for deploying pinning are the lazy update frequencies of many users; losing half of the users for a totalof one week after a certiﬁcate (pin) update is unacceptable for both app developers and their users. To
facilitate the use of pinning for eligible developers,
we cannot recommend to hard-code certiﬁcate pins
into app binaries. Instead, pins should be included

7 Here we made conservative choices to prevent unnecessarily bothering developers.
8 Given the lack of a platform comparable to Amazon Mechanical Turk for software developer studies, which also meansthat they donate their time to our research for free, a response
rate of 10% seems quite reasonable.

6 We assume that apps use TLS-secured connections forcritical components and do not work properly without Internet access.

13
USENIX Association

24th USENIX Security Symposium 251

Desired Change: Provide concrete sample codefor the speciﬁc use case or app.

To build our tool with the best possible feature
set and usability in mind, we were mainly interested
in the following aspects:

Wishlist We received wishes for “good tutorials
and programming examples”, “example code”, “libraries across platforms”, a “native Android API”,
a “test period and simple implementations” and thepossibility to “do the same for the web front-end”.

Knowledge About Pinning 15 (a third) of ourparticipants stated they knew what pinning was.
We asked them to explain this knowledge, and theirreplies varied from correct mentions of “custom, selfsigned certiﬁcates”, “reduction of the reliance on intermediate/root certiﬁcates, if a intermediate/root
gets compromised you don’t.” and “mobile apps thattalk to the same well known server all the time”
over “securing the communication between the app
and the server without needing to pay to issuers out
there” to “i don’t know” and confused and/or wrong
answers like “when you change the servers and/or
certiﬁcates more often”. We rated 80% of the answers as sensible.

Key Result: Developers want better tool supportand support in the decision process.
Desired Change: Easy-to-use tool support.

7.2

Tool Support

The developer feedback conﬁrmed that more tool
support is required and requested. When oﬀering
security solutions, we have to keep in mind that developers usually do not have a strong security focus and are not TLS experts, therefore, choosing
and implementing secure solutions must be made aseasy as possible. To this end, we built a tool that
supports developers with implementing secure certiﬁcate validation in general; it additionally helps
to decide whether pinning is the appropriate strategy. We made a web application publicly accessible
at https://pinning.android-ssl.org/, which webase on our classiﬁcation framework, the evaluation
results and the developer study’s results. We choseto implement our tool as a web application, since
it is easily accessible and allows to keep the data
backend up-to-date.
Developers and app users can upload APK ﬁlesand have results presented to them in a clear web
interface. First of all, the developers need to upload their app’s APK ﬁle, whereupon the web application conducts all required information extraction steps (cf. Section 4) and presents the developer
with an overview of relevant API calls and the corresponding remote origins that could be extracted.
To increase accuracy, in the next step the developers
are asked (1) whether they hold ownership for the
relevant API calls and (2) whether they control the
TLS conﬁguration for the extracted remote origins(to keep the workﬂow as simple as possible and notovercharge the developer with unnecessary information, we ﬁlter out well known libraries and popularorigins). Involving developers into the decision process is especially important in cases where automaticclassiﬁcation might not reveal accurate results, suchas for conﬁgured origins (cf. Section 4).
Finally, the strategy classiﬁcation is conducted
and we present the developer with our recommendation for making their connections as secure as pos-

Key Result: Only a quarter of the developers who
gave us feedback have a basic understanding of
pinning.
Desired Change: More detailed and critical explanation of what pinning is and how it works
as part of the oﬃcial Android documentation.
Obstacles Six participants had considered implementing pinning and decided against it. The reasonsranged from “laziness” over confusion to complaints
about the complexity and the lack of an “out-ofthe-box solution”. To the two thirds of our participants who didn’t know what pinning was, we
showed a short explanatory text 9 and asked them torate what they imagined could hypothetically keepthem from using pinning or convince them to staywith the standard solution. We showed the same
set of possible reasons to the developers who were
informed about pinning and asked how much thesereasons contributed to their not implementing pinning. They ranked “fear of losing users with old
app versions / due to hard TLS fails” the highest, followed by ”updates required when a certiﬁcate changes” and “complexity of the implementation”. They said the standard solution was preferable, because “it is easier”, they “trust in the existingCA-ecosystem” and “already own CA-signed certiﬁcates”, but rather not because of “employing several
diﬀerent certiﬁcates”.
Key Result: Of those who had heard of pinning,
40% had considered implementing it, but discounted it for being unusable or hard to implement.
9 taken and adapted from www.owasp.org

14
252 24th USENIX Security Symposium

USENIX Association

sible. In case the default strategy was selected, we
do not recommend the developer to take further action. In case leaf or CA pinning is recommended, thedevelopers are encouraged to increase their app’s security by implementing pinning. However, we also
inform the developers about the downsides of pinning in terms of updatability of certiﬁcate pins (cf.
Section 6.3). In a last step, the developer is oﬀered
support for implementing pinning.
For any given relevant API call and the corresponding remote origin, concrete example code forpinning is generated over the following steps:

future, it would be reasonable to include the classiﬁcation and recommendation process into the publication process in Google Play: An uploaded APK
ﬁle could be run through the tool and unpinned but
pinnable connections could be pointed out to therespective developer or pinned automatically via alibrary.

9

We conducted an extensive analysis on the applicability of pinning as an alternative and more secure
certiﬁcate validation mechanism for non-browser
software. Therefore, we analyzed 639,283 Android
apps of which 229,317 (35.9%) use TLS to secure
network connections and conservatively recommend
pinning for 11,547 (1.8%) of all apps, or 5.0% of theapps that use TLS. This corresponds to 20,020,535
connections, of which 1,062,810 (5.3%) use TLS,
of which 45,247 (4.25%) are conservatively recommendable for pinning. Optimistically, including estimates for unclassiﬁed connections as well as connections depending on dynamic code loading, we areable to suggest 140,858 connections or 58,817 (9.1%)
apps to take pinning into consideration.
This contradicts the common assumption thatpinning is a widely applicable solution for making
TLS certiﬁcate validation in non-browser software
more secure. Of the 229,317 apps we analyzed thatmake use of TLS to secure (some of) their network
connections, 203,159 (88.6%) establish TLS connections via third-party libraries.
While we ﬁnd that pinning is applicable only for
relatively few apps and their TLS connections, anominal-actual comparison illustrates that there isroom for improving the current situation, as only
45 of the 11,481 apps that could beneﬁt from pinning actually implement it. To help us understandaﬀected developers and design a solution, we conducted a qualitative study with 45 developers, where
we learned that pinning is relatively unknown andoften neglected due to usability problems. These
results incentivized us to build an easy-to-use webapplication to support developers in the decision
making process and guide them through the implementation of pinning for appropriate connections.
Our work concludes with the following take-aways:

1. The remote origin’s certiﬁcate is fetched and thecorresponding pin is computed.
2. A PinningTrustManager that uses the pin forcertiﬁcate validation is generated.
3. Surrounding
code
that
includesthe
PinningTrustManager
intothe
relevant API calls is generated, e.g.
for anHTTPSUrlConnection, an SSLContext is
generated that is initialized with the given
PinningTrustManager.
The developer can then simply include this scaﬀold
into the app and proﬁt from a higher level of security.
We asked the interested developers who left theircontact information in our developer study to test
our web application; 7 participated and gave positive
feedback on its usability.

8

Conclusions

Limitations

In addition to the limitations described in Section
5.5, our work has three more limiations.
First, the update behaviour analysis we conducted
for the users that participated in the AV’s telemetry
program might not necessarily represent the global
update behaviour. However, we think that security
aﬃne users who install anti-virus software on theirdevices have a tendency to update their software
more quickly than average users. Therefore, update
frequencies for the global Android user population
might be even worse.
Second, the feedback we got from app developers
was based on self-reporting and might be inﬂuenced
by a self-selection bias. Since we emailed developers
who our classiﬁcation framework had identiﬁed as
good candidates for pinning, but oﬀered them no
incentive for taking part in our survey, we could only
work with the developers who responded, leaving uswith an opt-in bias. However, this is best practicefor getting feedback from developers.
Third, our tool is currently implemented as a web
service and a standalone command line tool. In the

Poor Support for Pinning The Android API
lacks suﬃcient support for pinning: For low-level
APIs, developers have to implement their own certiﬁcate validation and need detailed knowledge regarding pinning. For higher level APIs, support for
pinning is missing entirely.
15

USENIX Association

24th USENIX Security Symposium 253

Limited Applicability The application of pinning in non-browser software such as apps is very
limited: We recommend pinning for only 5.0% of the229,317 TLS-enabled Android apps we analyzed.
Developer
Education Developer
feedback
showed that only a third of the developers who
could have implemented pinning had heard of it
before. Pinning seems to be confusing and developers misinformed. In the future, better developer
education is required as well as better developer
support.
Security Updates Our analysis of update periods for Android apps suggests that Android requires
mechanisms to quickly deploy security updates in
the future (cf. Section 6.3).
Pinning Implementation The current Android
documentation recommends to include pinning information at compile time, i. e. the recommendation is to add pins to the source code of an app.
However, our analysis of the update behaviour ofAndroid users suggests that developers should not
implement certiﬁcate pins into an app’s binary. Instead, we recommend to set pins via conﬁgurationﬁles that are only accessible by the respective app.

[10] Hoffman, P., and Schlyter, J. The DNS-Based Authentication of Named Entities (DANE) Transport Layer
Security (TLS) Protocol: TLSA. RFC 6698 (proposed
standard), IETF, 2012. http://tools.ietf.org/html/
rfc6698.

References[19] Poeplau, S., Fratantonio, Y., Bianchi, A., Kruegel,C., and Vigna, G. Execute This! Analyzing Unsafe andMalicious Dynamic Code.

[11] Kranch, M., and Bonneau, J. Upgrading HTTPS in
Mid-Air: An Empirical Study of Strict Transport Security and Key Pinning.
[12] Laurie, B., Langley, A., and Kasper, E. RFC
6962 Certiﬁcate Transparency. http://tools.ietf.org/
html/rfc6962, June 2013.
[13] Lu, L., Li, Z., Wu, Z., Lee, W., and Jiang, G. Chex:
Statically vetting android apps for component hijacking
vulnerabilities. CCS ’12, ACM, pp. 229–240.
[14] Marlinspike, M. Android Pinning. https://github.
com/moxie0/AndroidPinning.
[15] Marlinspike, M. TACK: Trust Assertions for Certiﬁcate Keys. http://tack.io/draft.html.
[16] Marlinspike, M. SSL And The Future Of Authenticity.
In BlackHat USA, 2011.
[17] OWASP.
OWASP Certiﬁcate Pinning Guide.
https://www.owasp.org/index.php/Certificate_
and_Public_Key_Pinning.
[18] Perl, H., Fahl, S., and Smith, M. You Won’t Be Needing These Any More: On Removing Unused Certiﬁcates
From Trust Stores. In Financial Cryptography and Data
Security 2014 (2014).

[1] API, A. Android TLS API. https://developer.
android.com/training/articles/security-ssl.html.

[20] Rescorla, E. RFC 2818 HTTP Over TLS. http://
tools.ietf.org/html/rfc2818, May 2000.

[2] Bates, A., Pletcher, J., Nichols, T., Hollembaek,
B., Tian, D., Butler, K. R., and Alkhelaifi, A. Securing ssl certiﬁcate veriﬁcation through dynamic linking. CCS ’14, ACM, pp. 394–405.

[21] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and Adams, C. RFC 6960 X.509 Internet
Public Key Infrastructure Online Certiﬁcate Status Protocol - OCSP. https://tools.ietf.org/html/rfc6960,
June 2013.

[3] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and Polk, W. RFC 5280 Internet X.509
Public Key Infrastructure Certiﬁcate and Certiﬁcate Revocation List (CRL) Proﬁle. https://datatracker.
ietf.org/doc/rfc5280/?include_text=1, May 2008.

[22] Sounthiraraj, D., Sahs, J., Greenwood, G., Lin, Z.,
and Khan, L. SMV-Hunter: Large Scale, AutomatedDetection of SSL/TLS Man-in-the-Middle Vulnerabilities in Android Apps.

[4] Desnos, A. Androguard. http://code.google.com/p/
androguard/.

[23] Tendulkar, V., and Enck, W. An Application Package Conﬁguration Approach to Mitigating Android SSL
Vulnerabilities.

[5] Evans, C., Palmer, C., and Sleevi, R. Public Key
Pinning Extension for HTTP. http://tools.ietf.org/
html/draft-ietf-websec-key-pinning-21, Oct 2014.
Internet-Draft.

[24] Vallina-Rodriguez, N., Amann, J., Kreibich, C.,
Weaver, N., and Paxson, V. A tangled mass: The
android root certiﬁcate stores. CoNEXT ’14, ACM,
pp. 141–148.

[6] Fahl, S., Dechand, S., Perl, H., Fischer, F., Smrcek,
J., and Smith, M. Hey, nsa: Stay away from my market!
future prooﬁng app markets against powerful attackers.
CCS ’14, ACM, pp. 1143–1155.

[25] Weiser, M. Program Slicing. IEEE TRANSACTIONSON SOFTWARE ENGINEERING VOL. SE-10, NO. 4(1984), 352–357.

[7] Fahl, S., Harbach, M., Muders, T., Baumgärtner,
L., Freisleben, B., and Smith, M. Why Eve and Mallory Love Android: An Analysis of Android SSL (in)Security. CCS ’12, ACM, pp. 50–61.

[26] Wendlandt, D., Andersen, D. G., and Perrig, A.
Perspectives: Improving ssh-style host authentication
with multi-path probing. ATC’08, USENIX Association,
pp. 321–334.

[8] Fahl, S., Harbach, M., Perl, H., Koetter, M., andSmith, M. Rethinking SSL Development in an Appiﬁed
World. CCS ’13, ACM, pp. 49–60.
[9] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R.,
Boneh, D., and Shmatikov, V. The Most Dangerous
Code in the World: Validating SSL Certiﬁcates in Nonbrowser Software. CCS ’12, ACM, pp. 38–49.

16
254 24th USENIX Security Symposium

USENIX Association