On Reliability of JA3 Hashes

for Fingerprinting Mobile Applications

Petr Matouˇsek1(B

), Ivana Burgetov´a1, Ondˇrej Ryˇsav´y1, and Malombe Victor2

1Brno University of Technology, Brno, Czech Republic

{matousp,burgetova,rysavy}@fit.vutbr.cz

2Strathmore University, Nairobi, Kenya

vmalombe@strathmore.edu

Abstract. In recent years, mobile communication has become more

secure due to TLS encapsulation. TLS enhances user security by encrypt-

ing transmitted data, on the other hand it limits network monitoring and

data capturing which is important for digital forensics. When observ-

ing mobile traﬃc today most transmissions are encapsulated by TLS.

Encrypted packets causes traditional methods to be obsolete for device

ﬁngerprinting that require visibility of protocol headers of HTTP, IMAP,

SMTP, IM, etc. As a reaction to data encryption, new methods like TLS

ﬁngerprinting have been researched. These methods observe TLS param-

eters which are exchanged in an open form before the establishment of

a secure channel. TLS parameters can be used for identiﬁcation of a

sending application. Nevertheless, with the constant evolution of TLS

protocol suites, it is not easy to create a unique and stable TLS ﬁnger-

print for forensic purposes. This paper presents experiments with JA3

hashes on mobile apps. We focus especially on the stability, reliability

and uniqueness of JA3 ﬁngerprints for digital forensics.

Keywords: Mobile application ·TLS ﬁngerprinting ·Network

forensics ·JA3 hash ·Encrypted communication

1 Introduction

With the disclosure of millions of private documents on Wikileaks in 2015, users

and companies massively started to improve the security of transmitted data,

especially against the interception. A high demand for security of transmitted

data led to the adoption of encrypted techniques by many network protocols.

Today, the majority of network applications and services support only encrypted

communication encapsulated by Transport Layer Security (TLS) [10,26].

Encryption was also adopted by many mobile app vendors. Table 1shows the

structure of network protocols involved in mobile communication. Datasets 1 to

4 created by the authors of this study in 2018 show that the ratio of encrypted

communication to unencrypted varies from 51,7 to 91,7%. You may notice a

ICST Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2021

S. Goel et al. (Eds.): ICDF2C 2020, LNICST 351, pp. 1–22, 2021.

https://doi.org/10.1007/978-3-030-68734-2_1

2 P. Matouˇsek et al.

Table 1. Encrypted and unencrypted mobile communication in 2018 and 2019

presence of non-encrypted HTTP traﬃc. Especially HTTP headers, e.g., User-

Agent,Accept-Language,Accept-Charset, have been largely used as an important

data source for various ﬁngerprinting techniques [11,17].

A year after our ﬁrst experiments, we noticed that the ratio of encrypted

communication increased to 99% which prevented the further use of traditional

ﬁngerprinting methods. As seen in Fig. 1, besides the encrypted TLS traﬃc

transmitted over port 443, only Domain Name System (DNS) data remained

open. It is a question for how long because of various attempts to encrypt DNS

traﬃc using DNS over TLS (DoT) or DNS over HTTP (DoH) [15,16].

As a reaction to the encryption, researchers focused their activity on

analysing behavior of encrypted communication in order to obtain meta data

about the encrypted traﬃc. One research direction is focused on statistical anal-

ysis of the encrypted transmissions [9,29], the other direction deals with the

features obtained from a TLS handshake that form the so called TLS ﬁngerprint

[3,6,18,24]. A popular implementation of TLS ﬁngerprinting called JA3 ﬁnger-

printing was proposed by John B. Althouse, Jeﬀ Atkinson and Josh Atkins in

20151. This method is incorporated into multiple network monitoring and intru-

sion detection systems (IDS) like Flowmon, Bro, or Suricata, where it serves for

the malware detection [4], identiﬁcation of network applications [19], or black

listing2.

In our research, we focus on mobile devices, especially on the detection of

mobile apps in network traﬃc. One of the features of mobile apps is that they reg-

ularly communicate over the Internet without explicit user interaction because

of software updates, data synchronization, or checking on the remote status [24].

1See https://github.com/salesforce/ja3 [April 2020].

2See SSLBL project at https://sslbl.abuse.ch/ [April 2020].

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 3

This makes it possible to identify a mobile device based on a characteristic set

of applications installed on the device [20]. Mobile apps can be identiﬁed from

the captured TLS traﬃc using JA3 hashes (retrieved from the client’s side of

communication) or JA3S hashes (the server’s side of communication).

However, there are important questions related to digital forensics: Are these

ﬁngerprints reliable enough to identify a speciﬁc application? How stable are

they? How can we create a unique ﬁngerprint database of a mobile app? The goal

of this paper is to study the reliability of JA3 ﬁngerprints on selected mobile

apps, to demonstrate how unique ﬁngerprints can be generated and to discuss

the application of JA3 ﬁngerprinting to the digital forensics.

1.1 Contribution

This work analyses the utilization of JA3 ﬁngerprints for mobile apps identiﬁ-

cation. We primarily focus on the reliability and stability of JA3 ﬁngerprints.

Based on our experiments we found out that JA3 hashes alone are not suﬃcient

for mobile app identiﬁcation due to the high number of JA3 hashes common

to multiple apps. By introducing additional TLS features like the JA3S server

hash and Server Name Indication (SNI) extension, more accurate identiﬁcation

becomes possible. One of the contributions is a procedure describing the gener-

ation of unambiguous ﬁngerprints for a given app. We also show the advantages

and limits of the proposed technique. The second contribution is the genera-

tion of datasets with the captured traﬃc of mobile apps that contain the full

TLS communication useful for further experiments with TLS ﬁngerprinting. The

third contribution includes a discussion of the stability and reliability of JA3 ﬁn-

gerprints which is important for digital forensics and mobile app identiﬁcation.

1.2 Structure of the Text

The paper is structured as follows. Section 2overviews recent works related

to TLS ﬁngerprinting and mobile apps identiﬁcation. Section 3gives the back-

ground of JA3 ﬁngerprinting method and discusses its reliability for mobile apps

identiﬁcation. The main part of the paper is in Sect. 4which describes how

extended JA3 ﬁngerprints of mobile apps are created and used for identiﬁca-

tion. Section 5brings the results of our experiments and the evaluation of the

proposed technique on the datasets. Section 6discusses the application of TLS

ﬁngerprinting to digital forensics. The last section concludes our ﬁndings.

2 Related Work

TLS ﬁngerprinting is not a new technique and its development is connected

with the security research of Ivan Risti´c who developed in 2008 an Apache mod-

ule that passively ﬁngerprinted connected clients based on cipher suites. Using

this technique he created a signature base that identiﬁed many browsers and

operating systems [1]. This technique was later applied on the identiﬁcation of

4 P. Matouˇsek et al.

HTTP clients [18] and implemented in IDS systems Bro and Surikata for passive

detection.

Blake Anderson et al. in [4] studied millions of TLS encrypted ﬂows and intro-

duced a set of observable data features from TLS client and server hello messages

like TLS version, TLS ciphers suites and TLS extensions that they used for mal-

ware detection. They also observed the server’s certiﬁcate and the client’s public

key length, sequence of record lengths, times and types of TLS sessions. They

identiﬁed cipher suites and extensions that were present in malware traﬃc and

missing in normal traﬃc. The authors deﬁned the TLS client conﬁgurations for

the 18 malicious families. Similarly, they identiﬁed the TLS server conﬁgurations

most visited by the 18 malicious families. They applied TLS features together

with other features (ﬂow data, inter-arrival times, byte distribution) to malware

classiﬁcation and achieved an accuracy from 96.7% to 98.2%. As demonstrated

by their study, omitting TLS features led to a signiﬁcantly worse performance.

Kotzias et al. [19] passively monitored the TLS and SSL connections from

2012 to 2015 and observed changes in TLS cipher suites and extensions oﬀered

by clients and accepted by servers. They also used client TLS ﬁngerprinting with

features similar to JA3 ﬁngerprinting. From handshakes they omitted GREASE

values. Using the captured data, they observed 7.3% ﬁngerprint collisions in the

TLS ﬁngerprints. They also mapped ﬁngerprints to a program or library and the

version. One of their main results was the observation of the TLS ﬁngerprints

stability. They noticed that the maximum duration of a ﬁngerprint seen in their

databases was 1.235 days (3 years, 4 months). However, the median of duration 1

day and the mean was 158.8 days. They noticed some ﬁngerprints that were seen

very brieﬂy and did not reappear later. They found out that 1,203 ﬁngerprints of

the 69,874 ﬁngerprints were responsible for 21.75% of connections. Further, they

analysed the vulnerability of TLS against various attacks which is a diﬀerent

direction comparing to our research. Their results related to the stability and

collisions of TLS ﬁngerprints was also observed in our experiments.

Another interesting approach published by Anderson and McGrew [3] com-

bines the end host data with the network data in order to understand appli-

cation behavior. This approach, however, requires an access to both the end

hosts and the network. Their ﬁngerprint database represented the real traﬃc

generated by 24,000 hosts and having 471 million benign and millions of mal-

ware connections3. Using the end point data, the authors were able to associate

the destination information with the end point data like the timestamp, end-

point ID, operating system and process name. They also observed that while

GREASE values are generated randomly, their position is deterministic. Thus,

instead of removing GREASE values, they set them to a ﬁxed string 0a0a. They

also studied the similarity of TLS ﬁngerprints using Levenshtein distance. Two

TLS ﬁngerprints were similar if their distance was less than or equal to 10% of

the number of cipher suites, the extension types, and the extension values. The

authors stated that the Levenshtein distance was an intuitive method for identi-

fying close ﬁngerprints. Especially TLS libraries often make minor adjustments

3Data capturing tools are available at https://github.com/cisco/mercury [April 2020].

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 5

to the default cipher suites or extensions between the minor version releases and

more drastic changes between the major version releases. They also noticed that

some TLS libraries change their default parameters to better suit the platform

on which they are running. Another interesting point is the prevalence of appli-

cation categories in the dataset where 37.1% connections belong to browsers,

19.3% to email applications, 17,2% to communication tools, 9% to the system,

etc. Longevity of ﬁngerprints like system libraries, tools osquery and DropBox,

and browsers was 6 months or greater.

The above mentioned approaches worked mostly with common network traf-

ﬁc and network application. Another work closer to ours deals with TLS usage

in Android Apps [24]. The authors analyzed the behavior of TLS in mobile plat-

forms. They developed an Android app Lumen that was installed on a mobile

device where it intercepted the TLS connections and gathered statistics about

the traﬃc. Using Lumen, the authors observed how 7.258 apps use TLS. They

analyzed handshakes with respect to the TLS API and the library that the app

used. Their work was focused on apps security and TLS vulnerabilities. They

showed that TLS libraries and OS API modiﬁed supported cipher suites across

versions which caused changes in the TLS ﬁngerprints. They also showed that

each TLS library and OS version had a unique cipher suite lists. They built

a database of ﬁngerprints paired with corresponding OSes and libraries where

they observed the inﬂuence of major and minor revisions of OS or TLS libraries

on the ﬁngerprint. Unfortunately, Lumen was not able to captured TLS hand-

shakes which would have been useful to our research. Thus, we used an additional

approach of how to obtain reliable TLS ﬁngerprints of mobile apps.

The mobile application ﬁngerprinting using characteristic traﬃc was consid-

ered by St¨ober et al. [28]. They created a classiﬁer that identiﬁed communicating

applications based on the analysis of side-channel information such as timing

and data volume. Mobile application ﬁngerprinting has been tackled by machine

learning techniques using timing and size of packets [31], which improved pre-

vious work presented in [30] that observed the traﬃc that was common among

more than one apps. The method is applicable to encrypted traﬃc, which is

used by most smartphone applications and relies only on information available

from the side channel. The ﬁngerprinting system was trained and tested on 110

most popular Android applications. The training was done automatically using

the implemented application AppScanner. The signiﬁcant feature of the method

was that it analyzed the traﬃc represented as bursts. A burst was deﬁned as

a group of packets within TCP ﬂow representing an interaction for a typical

smartphone application that communicated using HTTPS protocol. Statistical

features were then extracted for bursts and used for training random forests clas-

siﬁer. The method did not rely on any other source of information, e.g., DNS,

TLS, IP addresses, etc. The achieved accuracy as presented by the authors was

between 73 to 96% for the selected set of applications. Recently, the work was

extended by [12] that used a semi-supervised method for both app recognition

and detection of previously unseen apps.

Another line of research that considered mobile device identiﬁcation is rep-

resented by Govindaraj, Verma and Gupta [14]. They proposed a methodology

6 P. Matouˇsek et al.

for extracting and analyzing ads on mobile devices to retrieve user-speciﬁc infor-

mation, reconstruct a user proﬁle, and predict user identity. As the published

results showed it was possible to identify a user in various settings even if he/she

used multiple devices or diﬀerent networks. Their work stemmed from the study

by Castelluccia, Kafar and Tran [7] who demonstrated the possibility to infer

user interests from targeted ads.

Our work uses previously published results and focuses on passive identiﬁca-

tion of mobile apps using JA3 ﬁngerprints. It also observes traﬃc that is common

to multiple apps and that should be excluded from ﬁngerprinting. Based on the

app, we employ JA3, JA3S, and Server Name Indication (SNI) features to accu-

rately identify the unknown traﬃc that was sent by a mobile app. We are able

to detect only apps that were previously learnt and stored in the ﬁngerprinting

database. Unlike some of the above mentioned approaches, our technique for

mobile app detection is simple, fast and reliable. Its accuracy depends on the

quality of learnt ﬁngerprints.

3 How JA3 Fingerprinting Works

In this section we give a brief overview of principles of TLS communication and

JA3 hashing that is necessary for understanding the proposed method.

Transport Layer Security (TLS) [10,26] is a transmission protocol that works

on top of TCP where it provides privacy and data integrity for communicating

applications. The protocol is composed of two parts: TLS Handshake Proto-

col and TLS Record Protocol. TLS Handshake Protocol negotiates the security

parameters, e.g., version, methods for key exchange, encryption, authentication,

and data integrity, secure channel options, etc. TLS handshake communication is

not encrypted. The TLS Record Protocol encapsulates high-level protocol data

and transmits encrypted packets. An example of TLS handshake is in Fig. 1.

TCP Syn

TCP Syn + Ack

Ack

Client He llo

Server Hello+ Certificate + Done

Client K eyExchang e + Change C ipher

Spec

Change C ipher Spec

Application Data

Client Ser ver

TCP

handsh ake

TLS

handsh ake

Fig. 1. Establishing TLS connection.

After opening a TCP connection by a three-way handshake, the TLS negoti-

ates security parameters using TLS Client and Server Hello packets. The client

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 7

application oﬀers a set of supported encryption and authentication methods

using the TLS Client Hello. The TLS server processes these options and sends

back options that are supported on the server side. The server can also include a

server certiﬁcate to authenticate itself. After all security parameters are agreed

on, the application data encapsulated by TLS Record Protocol are exchanged.

Most of TLS ﬁngerprinting methods use the ﬁrst packet sent by the client: the

Client Hello. The Client Hello contains an imprint of TLS conﬁguration of the

client application that depends on the used TLS library and operating system.

In this paper we study JA3 ﬁngerprint that is computed as an MD5 hash from

ﬁve TLS handshake ﬁelds: TLS Handshake version, Cipher suites, Extensions,

Supported Groups (former Elliptic Curve), and Elliptic Curve point format, see

Fig. 2. Some TLS ﬁngerprinting implementations use diﬀerent TLS ﬁelds, e.g.,

Kotzias et al. [19] omit the TLS version.

Version,Cipher Suites, Extensions,Supported Groups,EC format

0x00000303 - 49195,49196,52393,49199,49200,52392,158,159,49161,49162,49171,49172,51,57,156,157,47,53 -

65281,0,23,35,13,16,11,10 - 0x00000017,0x00000018,0x00000019 - 0

771,49195-49196-52393-49199-49200-52392-158-159-49161-49162-49171-49172-51-57-156-157-47-53, 65281-0-

23-35-13-16-11-10,23-24-25,0

n8bvbvyZuTPF4tj89PaJVQ

Fig. 2. Computing JA3 hash

The computation of JA3 ﬁngerprint includes (i) the extraction of selected

ﬁelds from TLS Hello packet, (ii) concatenation of extracted data in decimal for-

mat into one string, and (iii) application of MD5 hash algorithm on the string.

The result is a 32-bit string in hexadecimal format. There are open implementa-

tions of JA3 ﬁngerprinting available4. Unlike nmap or web browser ﬁngerprinting

methods which actively request the source device or application, JA3 ﬁnger-

printing uses a passive approach. The process of creating TLS ﬁngerprints is

fast because it only works with a TLS header. Common network monitoring

and IDS tools implement the extraction of TLS parameters for analysis of the

encrypted network traﬃc.

The application of TLS ﬁngerprints to the identiﬁcation of network apps

requires TLS ﬁngerprint values to be unique, accurate and stable. The following

subsections describe aspects that limits the reliability of TLS ﬁngerprints.

3.1 Impact of TLS Library on JA3 Hashes

A TLS ﬁngerprint of a mobile app depends on the TLS library that was used

during its implementation. There are plenty of TLS libraries available to devel-

opers, e.g., GnuTLS, Oracle JSSE, BSD LibreSSL, OpenSSL, or Mozilla NSS.

4See https://github.com/salesforce/ja3 or https://ja3er.com/ [April 2020].

8 P. Matouˇsek et al.

When two applications are implemented using the same TLS library, their TLS

ﬁngerprints are usually the same. TLS ﬁngerprints can also change with a new

version of the app, TLS library, or operating system. This change can be caused

by adding strong ciphers or removing weak ciphers, changing default parameters

that better suit the running platform, or by adopting a new standard.

Table 2shows JA3 hashes for popular web browsers: Mozilla Firefox v.73,

Chrome v.80, and Opera v.66 under four operating systems: Linux Ubuntu,

Windows 10, Kali Linux and Mac OS. We can see that Firefox has four unique

JA3 ﬁngerprints. Two of them are present in all tested operating systems. In case

of Chrome and Opera, one JA3 ﬁngerprint value corresponds to both browsers

under all operating systems. These browsers were possibly compiled with the

same TLS library. This experiment proves that TLS ﬁngerprints change with

the version and operating system. A similar experiment over a larger dataset

was carried out by Razaghpanak et al. [24].

Table 2. JA3 hashes of common Web browsers

3.2 Randomized Values in TLS Extensions

In 2016, Google started to Generate Random Extensions And Sustain Extensi-

bility (GREASE) values to TLS. This technique was adopted by IETF in Jan-

uary 2020 as RFC 8701 [5]. GREASE values are randomly generated numbers

of cipher suites, extensions and supported groups present in TLS Hello pack-

ets. They prevent extensibility failures in TLS ecosystem. During TLS hand-

shake, the responding side must ignore unknown values. Peers that do not ignore

unknown values fail to inter-operate which means a bug in the implementation.

Therefore, RFC 8701 adds GREASE values as a part of the list of cipher suites,

extensions and supported groups to detect the invalid implementations.

When experimenting with Opera browser under Win 10 we noticed that the

browser generates 155 unique JA3 ﬁngerprints out of 207 TLS handshakes. By

excluding GREASE values, the number of unique JA3 ﬁngerprints decreased

to four. The high number of JA3 ﬁngerprints was caused by random GREASE

values in TLS handshakes. Table 3shows six JA3 ﬁngerprints of Opera browser

under Ubuntu with all extracted TLS values (the upper six lines). The last six

lines presents TLS values without GREASE values. The brown values in the

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 9

upper table represent GREASE values as deﬁned in [5]. When ignoring these

values, the last four lines in the upper table would have the same JA3 hashes.

Table 3. JA3 hashes with and without GREASE values

In addition to GREASE values, it is also good to omit extension value 65281

from TLS ﬁngerprinting. This value represents renegotiation option in TLS hand-

shake [27], see red numbers in the list of extensions. Additionally, TLS Client

Hello Padding Extension deﬁned by RFC 7685 [23] can be omitted. The padding

extension (value 21, depicted by green value in the table) is added by a client to

make sure that the packet is of a desired size.

The above mentioned values can be added by a TLS client or server based on

the local setting of a network connection which means they produce volatility of

JA3 ﬁngerprints. By removing these values we can increase the stability of JA3

ﬁngerprints. Most of the JA3 implementations already ignore GREASE values.

3.3 Ads and Tracking Services in TLS Traﬃc

By observing TLS handshakes of mobile apps, we noticed that an app does

not open the connection to its application server only, but it communicates with

various sides without explicit user activity. These connections include ad servers,

tracking services, or web analytic servers. This is typical especially for free apps

that receive funding from ads providers. The destinations of these services are

usually dynamic which means that each time the application is launched, it

connects to a diﬀerent site with a diﬀerent TLS ﬁngerprint. This causes problem

for ﬁnding ground-truth communication for learning TLS ﬁngerprints.

Dynamic behavior of ad connections is caused by mobile advertising auc-

tions that redirect the app from the ad server to the content provider based on

the results of an auction [21]. Since diﬀerent mobile apps include the same ad,

tracking or analytic plugins, the captured traﬃc of these apps contain the same

TLS ﬁngerprints. This extra traﬃc is called a communication noise or ambiguous

traﬃc [31]. Table 4shows TLS ﬁngerprints obtained from Gmail app communi-

cation. There are ﬁve diﬀerent JA3 ﬁngerprints computed from captured TLS

handshakes that were invoked by the Gmail app. Using the Server Name Indi-

cation (SNI) extension we can recognize the noise traﬃc directed to Google API

(www.googleapis.com) and Google user content (googleusercontent.com). This

traﬃc is not directly related to the app and can be found in communication

10 P. Matouˇsek et al.

of other apps. The remaining ﬁngerprint with SNI mail.google.com uniquely

characterizes the Gmail app. Thus, it is important to exclude ad, tracking and

analytic traﬃc from TLS ﬁngerprinting. One solution how to remove the noise

traﬃc is using available black lists of ad and tracking servers5. By comparing

server names in SNI ﬁeld of TLS handshake with names of ad servers in the black

lists, we can partially clean up the captured TLS communication from the noise

during the learning phase. Table 5shows a percentage of the noise for selected

mobile apps. Especially free apps include ad plugins producing such noise.

Table 4. JA3hashesofGmailApp

3.4 Time Stability of JA3 Hashes

A very important issue related to the mobile apps ﬁngerprinting is the stability

of TLS ﬁngerprints over time. We demonstrated, that a TLS ﬁngerprint depends

on TLS library and operating system, see Sect. 3.1. An update of the TLS library,

adding new or excluding weaker ciphers can change the ﬁngerprint. The longi-

tudinal study of TLS ﬁngerprints of Kotzias et al. [19] shows that the maximum

duration of TLS ﬁngerprints is 3 years and 4 months (median is 1 day, mean

158,8 days). If the app is not updated, it keeps its original TLS ﬁngerprint.

Table 5. The number of TLS connections to Ad servers for selected Apps

5E.g., https://hosts-ﬁle.net/ad servers.txt,https://pgl.yoyo.org/adservers/,orhttps:

//gitlab.com/ookangzheng/dbl-oisd-nl [April 2020].

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 11

The time instability means that for successful identiﬁcation of mobile apps

based on TLS ﬁngerprints, we need to update the ﬁngerprint database whenever

a new version is released, otherwise the app will not be correctly identiﬁed.

Nevertheless, our experiments show that the variability of TLS ﬁngerprints is

not so large and ﬁngerprints stay the same even when an OS is updated.

4 Identification of Mobile Apps Using TLS Fingerprinting

This section describes how TLS ﬁngerprints are created (learning phase) and

used for mobile apps identiﬁcation (detection phase).

4.1 Learning TLS Fingerprints

As mentioned above, the crucial task for mobile apps identiﬁcation using TLS

ﬁngerprints is to create a reliable ﬁngerprint database with unambiguous entries.

Even if an app is running in the controlled environment like the Android Virtual

Studio, the captured traﬃc contains a mixture of app traﬃc with communication

of OS, pre-installed apps and plugins that are common to multiple apps. Here, we

introduced a technique, how to clean up the captured traﬃc in order to receive

only TLS handshake related to the given app, see Fig. 3.

Fig. 3. Creating TLS ﬁngerprints

First, we need to launch an app communication on the mobile device. We

made experiments both with virtual devices running on the Android Virtual

Studio (datasets MA2, MA3) and on real devices (datasets MA1, MA4). When

using the virtual environment, we can capture network traﬃc on the interface

connected to the virtual environment. However, there can also be communication

of virtual OS and other applications installed on the system. When using real

smart phones, we can create a WiFi connection only for this device and capture

traﬃc on the WiFi interface. Fingerprint creation include the following steps:

12 P. Matouˇsek et al.

1. Extract TLS Client Hello packets where tls.handshake.type==1 and obtain

the following data: source and destination IP address, source and destination

port, TLS handshake type (client or server hello), SNI, a list of TLS cipher

suites, extensions, supported groups, and EC point format. Exclude GREASE

values, padding and renegotiation options, see Sect. 3.

2. Compute JA3 hash using TLS values in TLS Client Hello packet as explained

in Sect. 3. Apply MD5 hash function on TLS version, a list of cipher suites,

list of extensions, supported groups and EC point format. JA3 hash uses MD5

function with 32-bit output in hexadecimal format.

3. Compute JA3S hash using TLS values in a Server Hello packet. Link the

JA3S hash with the JA3 hash using IP addresses and ports. The JA3S hash

is a MD5 digest of the TLS version, cipher suite and extensions only.

4. Based on the list of ad servers and tracking servers, remove TLS ﬁngerprints

where SNI matches any domain name present in these lists.

5. From candidate TLS ﬁngerprints select only those ﬁngerprints that are related

to the app based on matching SNI ﬁeld with keywords related to the app.

Keywords can be obtained manually or using the tools Lumen or AppVersion

that show information about the app like domain names. An example of

keywords that match the app SNI names is listed in Table 6. In most cases,

keywords also include the app name. Formally, the keyword is the maximum

common substring of all SNI names related to the app.

Table 6. Example of app keywords

This procedure does not guarantee uniqueness of the obtained ﬁngerprints

which is essential for successful detection. When analysing JA3 ﬁngerprints learnt

from our datasets, we noticed that there were 30 distinct ﬁngerprints, how-

ever, many of them belonged to multiple applications. Only 21 JA3 hashes were

assigned unambiguously reaching uniqueness of 70%. Thus, we added JA3S ﬁn-

gerprint to a feature set and obtained 122 distinct combinations with 114 unique

ﬁngerprints related to only one app. Remember that one app can have a set of

unique ﬁngerprints. Combination of JA3+JA3S increased uniqueness to 93,44%

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 13

but there were still several JA3+JA3S combinations that belonged to more than

one app. After adding SNI to a feature set we received 154 distinct combinations

with 153 combinations related to only one app. The results are given in Table 7.

Table 7. Uniqueness of features in the TLS ﬁngerprint

The number of unique ﬁngerprints does not express, how many applications

from our MA datasets we can cover with these ﬁngerprints. We further analysed

the sets of unique ﬁngerprints to reveal this information. When using JA3 hashes

only, we can uniquely identify only 33,33% of apps from our dataset. Remaining

apps cannot be identiﬁed with JA3 hashes only (66,67%), because there are no

unique JA3 hashes for these apps in our datasets. When adding JA3S hashes,

we are able to cover 79,17% of apps from our datasets. Adding SNI to a feature

set increase the coverage of apps to 91,67%. Using all three features, we were

not able to cover 2 of 24 apps - Messenger and Telegram.

It seems that the combination of JA3, JA3S and SNI provides unique and

reliable TLS ﬁngerprints of mobile apps. This statements is not always true. It

depends on the function of the mobile app. Most mobile apps communicate only

with a limited number of servers related to the app. Some apps, for instance web

browsers, communicate with an open set of destinations based on user activity.

These apps cannot be identiﬁed by JA3S and SNI because these features depend

on the destination which changes by each connection. Also for applications that

connect to servers with random or anonymized domain names, only JA3 hash

can be employed for app identiﬁcation. Interestingly, the JA3 hash of Tor app

was unambiguous and suﬃcient for successful identiﬁcation. Most of the apps,

however, require the full combination of JA3, JA3S and SNI features.

4.2 Detection of Mobile Applications Using TLS Fingerprints

The above written procedure describes a generation of TLS ﬁngerprints from

captured TLS traﬃc. The process includes TLS data pre-processing and reﬁne-

ment that produces a unique TLS ﬁngerprint composed of JA3 hash only, com-

bination of JA3+JA3S or JA3+JA3S+SNI. Having such ﬁngerprints, we can

monitor unknown network traﬃc, retrieve selected values from the TLS Hello

packets, and compute JA3 and JA3S hashes. By comparison with the ﬁngerprint

database, we can identify an app that initiated this communication.

4.3 Stability and Reliability of TLS Fingerprinting

As mentioned in Sect. 3, the stability of TLS ﬁngerprints of a mobile app depends

on an app version, TLS library, and operating system. When using JA3S hashes,

14 P. Matouˇsek et al.

it also depends on the server version and its TLS library. This means that we

have to update our ﬁngerprint database whenever a new version of the app is

released. The ﬁngerprint can be generated using the procedure described in Sect.

4.1. In some cases, a new version may keep the same ﬁngerprint as the previous

one. Fingerprint stability is demonstrated on experiments with dataset MA3

where we observed TLS ﬁngerprints of four apps on Android 7.1, 8.1 and 9.

The results are presented in Table 8. The ﬁrst column represents the number of

unique values of JA3, JA3S and SNI in the TLS ﬁngerprint of a given mobile app

under Android 7. Columns Android 8.1 and 9 show the number of features that

were added or missing in comparison to the previous version. We can see that

SNI for CP app and Mujvlak are stable across versions. JA3S hash of CP app was

changed when migrating from version 7 to 8 but it stayed unchanged to version

9. Adding new values does not negate stability of the ﬁngerprint because the

original ﬁngerprint can still identify the app. If there are more additions, it may

happen that the ﬁngerprint of the older version would not match newly added

features (false negative). However, when updating the ﬁngerprint database by a

new ﬁngerprint, the accuracy of the identiﬁcation is preserved.

Table 8. Stability of TLS ﬁngerprints over OS version

5 Experiments

This section describes our experiments with ﬁngerprinting mobile apps. First,

we describe our datasets and then achieved results of mobile apps identiﬁcation.

5.1 Datasets

This section introduces datasets used in the experiments. First we observed avail-

able datasets with the mobile traﬃc. ReCon dataset6[25] was created to observe

leakage of personal identiﬁers through mobile communication. The dataset con-

tains HTTP(s) logs of 512 mobile apps. The logs do not contain TLS headers that

are important for TLS ﬁngerprinting. However, for a given mobile app, we can

6See https://recon.meddle.mobi/appversions/ [April 2020].

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 15

extract a list of sites the app usually connects to. For example, for accuweather

app, we get fonts.googleapis.com or ssl.google-analytics.com (noise servers), and

vortex.accuweather.com or accuwxturbo.accu-weather.com (app related domain

names). These domain names can be traced in SNI extension during the TLS

analysis which is important for creating unambiguous ﬁngerprints.

An interesting mobile apps dataset is Panoptispy7[22] that was created to

study media permissions and leaks from Android apps. The dataset consists of

network traﬃc that have instances of media in an HTTP requests body. Besides

dumps of HTTP requests, it contains a list of apps with a package name, version,

app name and app md5. However, this is not suﬃcient for TLS ﬁngerprinting.

Andrubis and Cross Platform datasets mentioned in [12] were not located by

the authors of this paper. Nevertheless, we explored Mirage dataset8[2]which

contains mobile app traﬃc for ground-truth evaluation. The captured traﬃc is

stored in a JSON format and contains the bi-ﬂows with src/dst ports, number of

bytes, inter-arrival times, TCP window size, L4 raw data, and various statistics.

Since the TLS header is hidden in byte-wise raw L4 payload, it is not easy to

extract TLS values that are interesting for our research. However, we plan to use

this data for a ground-truth evaluation of our method presented in the paper.

For our experiments we created our own dataset that contains communication

of selected mobile apps, see Table 9. We ran the app ﬁve to ten times on the

same platform in order to receive a representative sample of the traﬃc. In case

of MA3 database we ran each app 10 to 20 times on the three Android’s versions

with and without cache (after restarting a device) in order to observe the impact

on the temporary data saved in the cache. That is why dataset MA3 is larger.

Table 9. Mobile apps communication dataset

Even if using a small number of apps, our datasets are suﬃcient for studying

typical features of TLS mobile apps ﬁngerprints: uniqueness, stability and relia-

bility, and for training and detection of mobile apps. These datasets are available

in PCAP format in github9and contain ﬁve parts:

Web Browsers (WB). The ﬁrst dataset consists of TLS communication of web

browsers Chrome v80, Firefox 68.2, Firefox 73.0, Firefox 70.0, Opera 66.0 and

7See https://recon.meddle/mobi/panoptispy [April 2020].

8See https://ieee-dataport.org/open-access/mirage-mobile- app-traﬃc- capture-and-

ground-truth-creation [April 2020].

9See https://github.com/matousp/ja3s-ﬁngerprinting [July 2020].

16 P. Matouˇsek et al.

Opera 67.0. These browsers were running under four diﬀerent operating systems:

Kali Linux, Mac OS, Windows 10 and Linux Ubuntu. During experiments we

requested 10 diﬀerent URLs. We created TLS ﬁngerprints for all browsers based

on TLS handshakes related to requested URLs. The dataset contains 2.621 TLS

handshakes. It does not contain mobile traﬃc. It was used to observe an impact

of TLS libraries on JA3 ﬁngerprints, see Sect. 3.1.

Mobile Apps I (MA1). The second dataset includes ﬁve mobile applications:

Discord v16.3, Messenger v253.0, Slack v20.03, Telegram v6.0 and WhatsApp

v2.20. The applications were installed on two mobile devices: Sony Xperia X71

Compact with Android 9 (API level 28) and Huawei P9 with Android 7 and

EMUI 5.0.1 (API level 24). Devices were connected to a PC and TLS data cap-

tured using tshark. To make sure that the packets include initial handshake, the

tested application were restarted using ADB commands. The dataset contains

79 TLS handshakes.

Mobile Apps II (MA2). The third dataset includes communication of four

mobile applications: Accuweather, Gmail, Tor and Viber. For tests, we used

Android Emulator which is a part of Android Studio. In the Android Emulator,

we created two virtual devices: Google Pixel C with Android 8.1 and Google

Nexus 10 with Android 6.0. Using ADB interface we installed the above men-

tioned mobile applications on the virtual device and simulated user behavior

using the command-line tool Monkey. The Monkey emulates user behavior on

a given app, thus the captured traﬃc is initiated by this app only. An example

of emulating Viber app on the virtual device is below. The dataset contains 595

TLS handshakes.

$adb shell monkey -p viber -v 500 # emulate 500 events on package viber

Mobile Apps III (MA3). This dataset includes communication of the follow-

ing mobile applications: Cestovne Poriadky (Time Table), Muj vlak (My train),

Reddit and Seznam. TLS ﬁngerprints of these apps were obtained using Virtual

Box where these apps were installed. The apps were tested on Android version

7.1, 8.1 and 9. On each Android system, the app was repeatedly launched and the

communication captured. We also observed if the application cache has inﬂuence

on the communication, so each app was running twenty times without cache and

twenty times with cache on each system. Together, we obtained 3.180.245 TLS

handshakes.

Mobile Apps IV (MA4). The last dataset was focused on a variety of mobile

apps installed on a real device Tecno J8 with Android 6.1. The dataset includes

the following apps: BoomPlay Music, Chrome Browser, Equa Bank app, Face-

book app, Gmail app, Google calender, KB klic, Messenger, Mobilni Banka app,

NextBike, Telegram, TikTok, WhatsApp and Youtube app. Each app was run-

ning ﬁve times on the restarted device so that the captured communication

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 17

corresponds to a typical usage. We extracted 5.308 TLS handshakes from the

captured traﬃc.

5.2 Results

We evaluated our TLS ﬁngerprinting method using datasets MA3 and MA4 as

they contain multiple runs for each application and can be divided into train-

ing and testing sets. In order to get the balanced sets we used reduced dataset

MA3 (11 runs per app). We observed communication of 16 apps captured in

distinguished time windows. We selected one run of each application for test-

ing and the others we used for training. For training, we used the procedure

described in Sect. 4.1. The testing set contained 244 TLS handshakes in total.

These handshakes were classiﬁed as belonging to some application or unknown

traﬃc.

Table 10. Detection of mobile apps based on JA3 hash

Table 10 shows the confusion matrix of TLS handshakes classiﬁcation based

on JA3 hash only. Letters A to P represent mobile apps as follows: BoomPlay

Music (A), EquaBank (B), Facebook (C), Gmail (D), Google Calendar (E),

Chrome App (F), KB Klic (G), Mobilni Banka (H), NextBike (I), TikTok (J),

WhatsApp (K), Youtube (L), Seznam CZ (M), Reddit (N), Muj vlak (O) and

Cestovne Poriadky (P). Letter X describes unknown traﬃc. The rows contain

predicted values, columns represent real values.

We can see the limits of JA3 ﬁngerprinting that works well with apps C

(Facebook), D (Gmail), K (WhatsApp) and L (Youtube) but other apps have

JA3 hashes same as unknown traﬃc (X class). By adding JA3S hash to TLS

ﬁngerprint, the number of correctly classiﬁed apps increases, see Table 11.How-

ever, there is still a high number of false positives (column X). Table 12 presents

classiﬁcation results for three features JA3+JAS3+SNI. We can see that the

classiﬁcation is more accurate when using all these features with the exception

of apps Chrome (F) and Youtube (L). Table 13 shows the accuracy, precision and

18 P. Matouˇsek et al.

recall of classiﬁcation. JA3 hash is reliable only for speciﬁc apps and produces

many false negatives (row X). JA3+JA3S classiﬁcation has the comparable accu-

racy but better recall. This means that it produces a lot of false positives. The

best result shows a combination of JA3+JA3S+SNI. It also places some samples

into the X (unknown app) category, however, this can be improved by extending

a list of keywords and inserting additional SNIs into the ﬁngerprint database.

Table 11. Detection of mobile apps based JA3+JA3S

Table 12. Detection of mobile apps based on JA3+JA3S+SNI

Table 13. Evaluation of combination of TLS features

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 19

6 Application to Digital Forensics

The identiﬁcation of smartphone apps can be applied to digital forensics as

a complementary method to obtain forensically valuable information. First, the

background traﬃc of installed apps can be analyzed to identify a communicating

device [28]. This can distinguish a smartphone model from diﬀerent vendors

based on a pre-installed set of apps [13] and the background traﬃc. Next, by

the identiﬁcation of communicating applications, we can observe user-speciﬁc

information, habits and interests as well [8].

Most digital investigations that include mobile device analysis use a logical

extraction to access the existing ﬁles such as call history, text messages, web

browsing history, pictures and other ﬁles available on the smartphone. However,

logical extraction requires the possession of a device and bypassing the pass-

word. With smartphones better protected against the unauthorized access, the

passive monitoring of their activities stands for the complementary data source

for forensic analysis. The possibility to identify the mobile app, and therefore

the device or even the user of the device is applicable in the following scenarios:

– Forensic analysis. LEAs may send a preservation order to the ISP to collect

the communication for a speciﬁc device. The captured information can be

used for learning about the activities of a suspect at diﬀerent points in time.

Creating a proﬁle of the suspect and correlating identiﬁed activities with the

information obtained from the other sources can bring an important insight

to the case being investigated. Even if most of the app traﬃc is encrypted, the

presented method can detect installed applications. The presence and usage

of a speciﬁc application at a given point of time may reveal the intention

of the suspect. Later, after the device is physically available to an investiga-

tor the information obtained from the monitoring phase can be corroborated

with the ﬁndings of the logical acquisition outcomes to support the reliabil-

ity of the evidence. Criminals aware of secrecy provided by IM apps can use

them for communication to protect against traditional call record analysis

[32]. However, if we can identify the activity of mobile apps, the traﬃc gen-

erated by the communicating IM hosts can be used to record communication

between suspects. Also, posts published under the anonymous social network

account can be revealed by comparing the time of the public posts with the

time of the actions as inferred by the application usage aiding to hate crime

investigations.

– Intelligence operations. The agencies may be able to trace certain individuals

on basis of tracking the communication characteristic of the apps installed on

their smartphones. To be feasible, the amount of information that needs to be

collected and processed has to be limited. For instance, NetFlow-based moni-

toring is considered as suitable technique for this purpose [33]. The advantage

of TLS ﬁngerprinting can be applied at massive scale. Adding TLS ﬁngerprint-

ing to existing NetFlow monitoring requires to include TLS ﬁngerprints to

NetFlow records, which many existing monitoring solutions already provide

for detection of security threats that use encrypted communication.

20 P. Matouˇsek et al.

The presented cases consider the scenarios when the method is applied as a part

of legal investigation done under strict law requirements applied to data collec-

tion and analysis. Unfortunately, as for most communication monitoring tech-

niques collecting sensitive information possibly revealing user privacy, also this

method can be misused. For instance, the totalitarian states can easily adapt the

method to block selected apps and because it is computational inexpensive they

can apply it on a large scale. Avoiding this situation requires the modiﬁcation

of TLS parameters of applications to make their JA3 hashes indistinguishable

or intractable, e.g., by adding randomly generated parameters in the extension

list and avoiding the use of SNI ﬁeld.

7 Conclusion

Mobile apps ﬁngerprinting can be considered a practical method with potential

applications in digital forensics. In this paper, we have presented a study on the

reliability of JA3-based methods for mobile apps identiﬁcation. The advantage

of this method is that it only depends on the TLS handshake information that

is obtained during the establishment of the secure channel.

We have shown that using JA3 is not suﬃcient for the accurate identiﬁcation

of mobile apps. More reliable results are obtained by a combination of JA3,

JA3S and SNI features that can be easily computed from the TLS handshake

messages. We have also considered the issues of TLS ﬁngerprint volatility. Based

on our experiments the variability of TLS ﬁngerprints is not so large. Also, when

a new major version of the application is released, it is not diﬃcult to obtain a

new ﬁngerprint in the virtual environment and update the ﬁngerprint database.

The presented results are valid for existing TLS versions that provide access

to the source information necessary for computing the ﬁngerprints. However,

ongoing work on TLS protocol suggests an increase of user privacy by hiding

some of currently visible ﬁelds, e.g., SNI10, or even the encryption of TLS Hello

message. Addressing these emerging challenges is a topic for our future work.

Acknowledgement. This work was supported by project “Integrated platform for

analysis of digital data from security incidents”, 2017–2020, No. VI20172020062,

granted by Ministry of Interior of the Czech Republic. The authors would like to give

thanks to students Matej Meluˇs, Radovan Babic and Alberts Saulitis who participated

in the generation of datasets for the research experiments.

References

1. Abel, R.: SSL/TLS ﬁngerprint tampering jumps from thousands to billions. SC

Magazine (2019)

2. Aceto, G., Ciuonzo, D., Montieri, A., Persico, V., Pescap´e, A.: MIRAGE: mobile-

app traﬃc capture and ground-truth creation. In: 2019 4th International Confer-

ence on Computing, Communications and Security (ICCCS), pp. 1–8 (2019)

10 See Internet Draft at https://tools.ietf.org/html/draft-ietf-tls-esni-06 [March 2020].

On Reliability of JA3 Hashes for Fingerprinting Mobile Applications 21

3. Anderson, B., McGrew, D.: TLS Beyond the browser: combining end host and

network data to understand application behavior. In: Proceedings of the Internet

Measurement Conference, pp. 379–392 (2019)

4. Anderson, B., Paul, S., McGrew, D.: Deciphering malware’s use of TLS (without

decryption). J. Comput. Virol. Hacking Tech. (2018)

5. Benjamin, D.: Applying Generate Random Extensions And Sustain Extensibility

(GREASE) to TLS Extensibility. IETF RFC 8701, January 2020

6. B¨ottinger, K., Schuster, D., Eckert, C.: Detecting ﬁngerprinted data in TLS traﬃc.

In: Proceedings of the 10th ACM Symposium on Information, Computer and Com-

munications Security, pp. 633–638. ASIA CCS 2015. Association for Computing

Machinery, New York (2015)

7. Castelluccia, C., Kaafar, M.A., Tran, M.D.: Betrayed by your ads!. In: Fischer-

H¨ubner, S., Wright, M. (eds.) Privacy Enhancing Technologies, pp. 1–17. Springer,

Heidelberg (2012). https://doi.org/10.1007/978-3-642-31680-7 1

8. Conti, M., Mancini, L.V., Spolaor, R., Verde, N.V.: Can’t you hear me knocking:

identiﬁcation of user actions on android apps via traﬃc analysis. In: Proceed-

ings of the 5th ACM Conference on Data and Application Security and Privacy,

CODASPY 2015, pp. 297–304. New York, NY, USA (2015)

9. Danezis, G.: Traﬃc Analysis of the HTTP Protocol over TLS (2009). https://pdfs.

semanticscholar.org/9d75/9184cdc524624fe551b9fc15de9a4cd199fa.pdf

10. Dierks, T., Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.2.

IETF RFC 5246, August 2008

11. Eckersley, P.: How unique is your web browser? In: Proceedings of the 10th Inter-

national Conference on Privacy Enhancing Technologies, PETS 2010, pp. 1–18.

Springer, Heidelberg (2010). https://doi.org/10.1007/978-3-642-14527-8 1

12. van Ede, T., et al.: FlowPrint: semi-supervised mobile-app ﬁngerprinting on

encrypted network traﬃc. In: NDSS (2020)

13. Gamba, J., Rashed, M., Razaghpanah, A., Tapiador, J., Vallina-Rodriguez, N.: An

analysis of pre-installed android software. In: 41st IEEE Symposium on Security

and Privacy. IEEE (2020)

14. Govindaraj, J., Verma, R., Gupta, G.: Analyzing mobile device ads to identify

users. DigitalForensics 2016. IAICT, vol. 484, pp. 107–126. Springer, Cham (2016).

https://doi.org/10.1007/978-3-319- 46279-0 6

15. Hoﬀman, P., McManus, P.: DNS Queries over HTTPS. RFC 8484, October 2018

16. Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., Hoﬀman, P.: Speciﬁcation

for DNS over Transport Layer Security (TLS). IETF RFC 7858, May 2016

17. Hupperich, T., Maiorca, D., K¨uhrer, M., Holz, T., Giacinto, G.: On the robust-

ness of mobile device ﬁngerprinting: can mobile users escape modern web-tracking

mechanisms? In: Proceedings of the 31st ACSAC, pp. 191–200. New York, USA

(2015)

18. Hus´ak, M., ˇ

Cerm´ak, M., Jirs´ık, T., ˇ

Celeda, P.: Https traﬃc analysis and client

identiﬁcation using passive SSL/TLS ﬁngerprinting. EURASIP J. Inf. Secur. (2016)

19. Kotzias, P., Razaghpanah, A., Amann, J., Paterson, K.G., Vallina-Rodriguez, N.,

Caballero, J.: Coming of age: a longitudinal study of TLS deployment. In: Pro-

ceedings of the Internet Measurement Conference 2018, pp. 415–428 (2018)

20. Kurtz, A., Gascon, H., Becker, T., Rieck, K., Freiling, F.: Fingerprinting mobile

devices using personalized conﬁgurations. Proc. Privacy Enhancing Technol. 1,

4–19 (2016)

21. Kwakyi, G.: How Do Mobile Advertising Auction Dynamics Work? Incipia

Blog (2018). https://incipia.co/post/app-marketing/how-do-mobile-advertising-

auction-dynamics-work/

22 P. Matouˇsek et al.

22. Pan, E., Ren, J., Lindorfer, M., Wilson, C., Choﬀnes, D.: Panoptispy: characteriz-

ing audio and video exﬁltration from Android applications. Proc. Privacy Enhanc-

ing Technol. 33–50 (2018)

23. Benjamin, D.: A Transport Layer Security (TLS) ClientHello Padding Extension.

IETF RFC 7685, October 2015

24. Razaghpanah, A., Niaki, A.A., Vallina-Rodriguez, N., Sundaresan, S., Amann, J.,

Gill, P.: Studying TLS usage in Android apps. In: Proceedings of the 13th Confer-

ence on Emerging Networking Experiments and Technologies, pp. 350–362. New

York (2017)

25. Ren, J., Rao, A., Lindorfer, M., Legout, A., Choﬀnes, D.: ReCon: revealing and

controlling PII leaks in mobile network traﬃc. In: Proceedings of the 14th Annual

International Conference on Mobile Systems, Applications, and Services, pp. 361–

374 (2016)

26. Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC

8446, August 2018

27. Rescorla, E., Ray, M., Dispensa, S., Oskov, N.: Transport Layer Security (TLS)

Renegotiation Indication Extension. IETF RFC 5746, February 2010

28. St¨ober, T., Frank, M., Schmitt, J., Martinovic, I.: Who do you sync you are?

Smartphone ﬁngerprinting via application behaviour. In: Proceedings of the Sixth

ACM Conference on Security and Privacy in Wireless and Mobile Networks, pp.

7–12 (2013)

29. Sun, G., Xue, Y., Dong, Y., Wang, D., Li, C.: An novel hybrid method for eﬀectively

classifying encrypted traﬃc. In: 2010 IEEE Global Telecommunications Conference

GLOBECOM 2010, pp. 1–5 (2010)

30. Taylor, V.F., Spolaor, R., Conti, M., Martinovic, I.: Appscanner: automatic ﬁnger-

printing of smartphone apps from encrypted network traﬃc. In: IEEE European

Symposium on Security and Privacy (EuroS&P), pp. 439–454 (2016)

31. Taylor, V.F., Spolaor, R., Conti, M., Martinovic, I.: Robust Smartphone App Iden-

tiﬁcation Via Encrypted Network Traﬃc Analysis. CoRR abs/1704.06099 (2017).

http://arxiv.org/abs/1704.06099

32. Tsai, F., Chang, E., Kao, D.: Whatsapp network forensics: discovering the commu-

nication payloads behind cybercriminals. In: 2018 20th International Conference

on Advanced Communication Technology (ICACT), p. 1 (2018)

33. Verde, N.V., Ateniese, G., Gabrielli, E., Mancini, L.V., Spognardi, A.: No nat’d

user left behind: ﬁngerprinting users behind nat from netﬂow records alone. In:

IEEE 34th International Conference on Distributed Computing Systems, pp. 218–

227 (2014)