electronics

Article
Encrypted Traffic Decryption Tools: Comparative Performance
Analysis and Improvement Guidelines
Minwoo Jo, Hayong Jeong, Binwon Song and Heeseung Jo *

Department of Computer Science, Chungbuk National University, Cheongju 28644, Republic of Korea;
[email protected] (M.J.); [email protected] (H.J.); [email protected] (B.S.)
* Correspondence: [email protected]

Abstract: With the exponential growth of encrypted communication over the internet, research into
systems capable of analyzing large volumes of encrypted traffic is essential. This study focuses
on evaluating the performance of two prominent tools, ssldump and tshark, in decrypting and
inspecting encrypted network traffic, assuming an environment where decryption keys are available.
The performance of ssldump and tshark was assessed using various metrics, including execution
time, and the ability to handle different file sizes and session counts. The results showed that tshark
exhibited faster processing speeds for smaller file sizes and a higher number of sessions, while
ssldump demonstrated better performance for larger file sizes and fewer sessions. However, notable
performance differences were not observed based solely on the type of cipher suite or encryption
method used. To enhance performance, the study proposes the session-based split and conquer (SSC)
technique for automating parallelization using a multi-process approach. SSC shows up to a 39×
improvement in performance, depending on system capabilities and workload.

Keywords: decryption; TLS/SSL; packet; sniffing; network; performance

1. Introduction
The worldwide advancement in AI computing trends and the evolution of big data
have elevated data security as a critical issue. Encryption of data is a key means of keeping
Citation: Jo, M.; Jeong, H.; Song, B.; Jo,
information secure. However, as encryption technology progresses, the importance of
H. Encrypted Traffic Decryption Tools:
decrypting encrypted traffic is also becoming more pronounced. While encrypted com-
Comparative Performance Analysis
and Improvement Guidelines.
munication over networks is a fundamental and essential method of data protection, they
Electronics 2024, 13, 2876. https://
present significant challenges for system administrators responsible for security manage-
doi.org/10.3390/electronics13142876 ment. Encrypted data, being indecipherable in its encrypted state, poses considerable
difficulties for administrators in addressing issues such as data leaks and virus detection
Academic Editor: Hung-Yu Chien
over the network.
Received: 5 June 2024 There are several methods available for encrypting data, and the choice of method
Revised: 15 July 2024 depends on factors such as the type of data, security requirements, and available technolo-
Accepted: 20 July 2024 gies. One of the most common methods is symmetric key encryption, where the same
Published: 22 July 2024 key is used for both encrypting and decrypting data. This method offers high encryption
efficiency and fast processing speeds. Representative algorithms include the Advanced
Encryption Standard (AES) [1], Data Encryption Standard (DES) [2], Blowfish [3], and
Twofish [4]. However, because the same key is used for both encryption and decryption in
Copyright: © 2024 by the authors. symmetric key encryption, ensuring secure key distribution is crucial.
Licensee MDPI, Basel, Switzerland.
Asymmetric Key Encryption, also known as Public Key Encryption, utilizes a pair of
This article is an open access article
keys, a public key and a private key, to encrypt and decrypt data. Encryption is performed
distributed under the terms and
using the public key, while decryption is carried out using the private key. Representa-
conditions of the Creative Commons
tive algorithms include Rivest–Shamir–Adleman (RSA) [5], Elliptic Curve Cryptography
Attribution (CC BY) license (https://
(ECC) [6], and Diffie–Hellman Key Exchange (DH) [7]. The advantages of asymmetric
creativecommons.org/licenses/by/
key encryption include relatively simple key management and the ability to address key
4.0/).

Electronics 2024, 13, 2876. https://doi.org/10.3390/electronics13142876 https://www.mdpi.com/journal/electronics

Electronics 2024, 13, 2876 2 of 15

exchange challenges inherent in symmetric key encryption. However, compared to sym-

metric key encryption, asymmetric key encryption tends to be slower and requires more
computational resources for encryption/decryption operations.
A hash function is an algorithm that transforms data into a fixed-size hash value. Hash
functions are one-way functions, meaning that the original data cannot be recovered from
the hash value. A well-known hash function is SHA-256. Hash functions are commonly
used to verify data integrity or store important information, like passwords, securely.
Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are cryptographic
protocols used to provide security in network communications. TLS is the successor to
SSL and, currently, SSL is discouraged from use due to security vulnerabilities. These
encryption protocols encrypt and protect communication between clients and servers,
thereby safeguarding against Man-In-The-Middle (MITM) attacks, data theft, and surveil-
lance. TLS/SSL is widely used in various applications, including the HTTPS protocol
between web browsers and web servers, making it the primary focus for data decryption
in this study.
There are several methods available for capturing network traffic in real-time, includ-
ing using network protocol analysis tools, switch port mirroring, network hub monitoring,
network tap replication, or installing proxy servers. These methods enable the capture
of network traffic, which is typically saved in data file formats for subsequent analysis.
The pcap library [8] is commonly used for this purpose. In this study, we aim to capture
network traffic using network protocol analysis tools and save it in the pcap format for
decryption. There are various tools available for decrypting encrypted traffic, with popular
choices including Wireshark, ssldump, and Microsoft Network Monitor.
Upon analyzing the decryption process, we observed that these programs spend more
time on packet disassembly and reassembly than on actual decryption. To address this
issue, we employed the Session-based Split and Conquer (SSC) method to divide the pcap
file into segments and utilized multiprocessing techniques to decrypt each segmented
pcap file. Furthermore, to increase the disk I/O speed of a huge amount of pcap files,
we devised an additional in-memory version using asynchronous processing with tmpfs.
When evaluating the execution time performed by SSC for tshark4 with packet sizes of
4096k with 10 sessions, the following time reductions were observed compared to standard
execution: 40.2% reduction in the native environment, 50.3% reduction in the asynchronous
environment, and 68.2% reduction in the in-memory environment. For packet sizes of
4096k with 1000 sessions, tshark4 demonstrated a time reduction of 93.5%, while ssldump
showed a reduction of 97.4%.
The structure of this paper is as follows. This chapter describes the motivation for the
research and summarizes this paper. Section 2 explains the issues concerning the differences
between related research and this study. Section 3 briefly summarizes and explains the
background knowledge used in this study. Section 4 presents a detailed analysis of the
decryption performance of TLS encrypted traffic data for the two selected decryption tools,
tshark and ssldump. In Section 5, we propose an SSC technique to improve performance
based on the analysis. We evaluate the performance when a pcap file is divided and
executed through multiprocessing. Section 6 provides a discussion, and Section 7 concludes
the paper.

2. Related Work
This study focuses on analyzing and improving performance in the process of decrypt-
ing encrypted traffic to inspect the plaintext. Related research can be classified into the
following categories based on decryption methods and performance aspects.
Research on decryption methods: Research on decrypting encrypted traffic has been
ongoing for a long time, dating back to the inception of encrypted communications. Blake
et al. [9] conducted a study to enhance the efficiency of malware detection by increasing
the understanding of HTTPS confidentiality limitations. Florian et al. [10] presented a col-
laborative approach where endpoints selectively send TLS keys to the NMS for decrypting
Electronics 2024, 13, 2876 3 of 15

TLS connections. They implemented a prototype based on Zeek NMS that can decrypt TLS
connections and analyze plaintext. Husak et al. [11] proposed a mechanism for real-time
identification of HTTPS clients based on network monitoring and SSL/TLS fingerprinting.
They developed a list of SSL/TLS encryption suites and an HTTP user agent dictionary,
assigning user agents to observed SSL/TLS connections to identify communication clients.
Moriconi et al. [12] implemented X-ray-TLS, which operates in major TLS libraries by using
a memory change reconstruction algorithm to extract TLS secrets from process memory. It
has the advantage of an operation based on existing kernel functions, thus not requiring
modifications to hypervisors or existing programs. However, most research on decryption
focuses on the methods, not paying much attention to execution time and performance,
which differentiates our study.
Research focused on performance: Markus et al. [13] investigated the performance
impact of Post-Quantum cryptography on TLS 1.3, examining various signature algorithms
and key agreements through black-box and white-box measurements to present their
performance. Yildiz [14] proposed a combination of quantitative and qualitative methods
by scanning the HTTPS configurations of domains and analyzing case studies and literature
reviews. This approach has been known to yield good results in improving security
and privacy for public websites and promoting the adoption of best practices. Junghan
et al. [15] based their research on the observation that traffic monitoring middleboxes on
the client side are often read-only. Given that generalized architectures, like mbTLS [16]
or maTLS [17], are very inefficient due to the complexity of key sharing and additional
computations, they suggested improvements. These proposals are either for performance
enhancement in decryption or mechanisms operating under specific conditions, thus having
limitations in universality. Our research deals with performance analysis and enhancement
by achieving complete decryption to view plaintext.

3. Background Knowledge
This section presents the results of the evaluation of the performance of leading tools
for decrypting existing network traffic data. The analysis offers detailed insights into
performance variations based on data size, number of sessions, protocols, and cipher suites.

3.1. SSL/TLS Handshake

The SSL/TLS protocol is designed as an encryption protocol to provide secure com-
munication over computer networks, primarily used for protecting data transmission via
the internet, such as websites, email, VPNs, VoIP, and instant messaging applications. The
SSL protocol ceased updates due to significant security issues after its 3.0 version in 1996.
Currently, most communications utilize versions 1.2 and 1.3 of TLS. The process of SSL/TLS
handshake proceeds as follows.
1. Client hello: Client sends a client hello message to the server detailing the client’s
configuration settings. It passes the SSL/TLS version, a list of available cipher suites,
a session ID, and a random byte.
2. Server hello: SSL/TLS server receives the client hello packet and sends the client a
cipher suite, SSL protocol version, public key, digital certificate, session identifier, and
server random byte.
3. Certificated: The server sends its SSL certificate to the client. Inside the certificate
is the public key issued by the server. The client decrypts the SSL certificate using
the CA’s public key, which is known to everyone. Successful decryption results in
authentication and successful verification.
4. Key exchange: The symmetric key is generated by the client, encrypted with the
server’s public key extracted from inside the SSL certificate, and passed to the server.
The key encrypts the data that the client and server want to exchange.
5. Finished: Finally, after all the information to be exchanged has been exchanged,
the handshake ends by sending a ‘Finished’ packet to indicate that they are ready
to communicate.
Electronics 2024, 13, 2876 4 of 15

3.2. Cipher Suite

A cipher suite encompasses key exchange algorithms, server authentication algorithms,
symmetric cipher algorithms, block cipher modes of operation, and message authentication
hash algorithms. During the handshake phase, the client lists the cipher suites it can use
in a message to the server (client hello). The server then selects one from the list and
communicates its choice back to the client (server hello), and encryption proceeds using
the selected cipher suite.
The structure of a cipher suite is in the format of ‘SSL/TLS_A_B_with_C_D_E’, where
A through E sequentially represent the key exchange algorithm, authentication algorithm,
symmetric encryption algorithm, block cipher mode of operation, and message authenti-
cation hash algorithm, respectively. For instance, TLS_ECDHE_ECDSA_with_AES_128_
GCM_SHA256 signifies the use of the TLS protocol, with ECDHE as the key exchange
method, ECDSA as the authentication algorithm, AES as the symmetric algorithm with a
128-bit encryption key, GCM as the block cipher mode of operation, and SHA256 as the
hash algorithm.

3.3. Decryption Methods

There are primarily two methods for decrypting encrypted data: the SSLKEYLOGFILE
method and the MITM approach. The decryption process using SSLKEYLOGFILE involves
enabling SSL logging to create a file that records information during the SSL process,
which is then used for decryption. When accessing a domain, the client generates a
pre-master secret key through a key exchange algorithm. This key is used to encrypt
traffic, and browsers such as Chrome and Firefox can record this key. By registering
the SSLKEYLOGFILE environment variable, the log of the pre-master key is saved at a
specified path when HTTPS traffic occurs. By recording and storing such information
through SSLKEYLOGFILE, it is possible to gain information about all cipher suites used in
that session. This information is then used in the decryption process to decipher encrypted
communications.
The MITM method, often used for intercepting information between a server and
a client, leverages various proxy servers to decrypt encrypted traffic. A proxy server is
commonly employed for security reasons, acting on behalf of the client to communicate
with the server, and is utilized for decryption. During the communication between a client
and a server, a handshake occurs in the order of client hello, server hello, certificate, and
client key exchange. SSL/TLS employs a public key-based authentication method where
a symmetric key is generated. During the client key exchange process, for example, the
client sends the symmetric key it generated to the server, encrypted with the server’s public
key. In a MITM attack scenario, the client unknowingly sends the symmetric key to the
interceptor (MITM). The interceptor then generates its own symmetric key and sends it to
the server. The server, believing it to be communicating directly with the client, encrypts
packets using the symmetric key provided by the interceptor and sends them back. The
interceptor decrypts these packets, then re-encrypts them with the symmetric key initially
shared by the client before forwarding them to the client. This process allows the interceptor
to decrypt, read, and re-encrypt the communications, effectively conducting decryption
through the MITM method.

4. Performance Analysis of Conventional Tools

This section presents the results after evaluating the performance of leading tools
for decrypting existing network traffic data. The analysis offers detailed insights into
performance variations based on data size, number of sessions, protocols, and cipher suites.

4.1. Analysis Environment

To generate a workload for measuring and comparing the performance of decryption
tools, we captured encrypted communications between an Nginx web server and a client
using Machine A, as shown in Table 1. Machine B was also used from Section 5 onwards to
Electronics 2024, 13, 2876 5 of 15

evaluate performance with large pcap files. The captured data was saved in pcap format,
and experiments were conducted with varying parameters, such as data size, sessions,
clients, and TLS versions, to create a range of workloads, as outlined in Table 2. To ensure a
diverse range of performance evaluations, we generated workloads using 18 supported
cipher suites from the Nginx web server, excluding 12 that were not supported. The specific
cipher suites used are listed in Table 3.

Table 1. Machine specifications used for evaluation.

Machine A Machine B
Intel(R) Xeon(R) CPU E5-2420 @ 1.90 Intel(R) Xeon(R) CPU E5-2696
CPU
GHz (12 Cores) v4 @ 2.20 GHz (44 Cores)
Memory DDR4 16 GB DDR4 128 GB
Storage PERC H310 1TB x2 (RAID 0) Samsung SSD 850 250 GB
OS Ubuntu 22.04.03 LTS Ubuntu 22.04.03 LTS

Table 2. Workload combinations used for evaluation.

Specification Parameters
Data size 1K, 16K, 256K, 4096K, 65,536K
Number of sessions 10, 100, 1000
Protocols TLS v1.2, TLS v1.3
Clients curl, firefox browser
Server Nginx web server

Table 3. Cipher suites used for evaluation.

Unique ID Cipher Suites

CS1 ECDHE-RSA-CHACHA20-POLY1305
CS2 ECDHE-RSA-AES256-GCM-SHA384
CS3 DHE-RSA-AES128-GCM-SHA256
CS4 DHE-RSA-AES256-GCM-SHA384
CS5 ECDHE-RSA-AES128-SHA256
CS6 ECDHE-RSA-AES256-SHA384
CS7 ECDHE-RSA-AES128-SHA
CS8 ECDHE-RSA-AES256-SHA
CS9 DHE-RSA-AES128-SHA256
CS10 DHE-RSA-AES128-SHA
CS11 DHE-RSA-AES256-SHA256
CS12 DHE-RSA-AES256-SHA
CS13 AES128-GCM-SHA256
CS14 AES256-GCM-SHA384
CS15 AES128-SHA256
CS16 AES256-SHA256
CS17 AES128-SHA
CS18 AES256-SHA

For each evaluation, we used the captured pcap files from all workloads along with
the corresponding encryption key files stored in log format. Decryption was performed
using the decryption tools, and execution times were measured. To assess differences in
decryption execution times based on data size and session count, we analyzed the execution
times of tshark and ssldump with varying data sizes and session counts among the cipher
suites listed in Table 3. Following this, we conducted a performance analysis for each
decryption tool. To represent data size and session count in the experiment results, we
used a format like XK.NN, where “XK” indicates the data size in kilobytes and “NN” rep-
resents the number of sessions. For example, “1K.10” means a data size of 1 kilobyte with
10 sessions. All evaluations were conducted three times, and the average value was pre-
sented.
 CS15 AES128-SHA256
4.2. Execution CS16Time Differences Based on File Size and Number AES256-SHA256
of Sessions
CS17 AES128-SHA
The results showing the differences in execution times for decryption based on file
Electronics 2024, 13, 2876 size using tshark3 CS18 are presented in Figure 1. The ssldump AES256-SHA shows a similar 6 of pattern
15 to
tshark, so we decided it was not necessary to include it. As expected, execution time in
4.2. Execution
creases Time
with file Differences
size, which isBased
logicalongiven
File Size and
that Number
larger filesofrequire
Sessionsmore time for packe
4.2. Execution
analysis and Time Differences
decryption. Based
Notably, on File
while Size
fileand Number
The results showing the differences in execution times for1K,
sizes were of Sessions
tested at 16K, 256K,
decryption and 4096K
based on file
size The
representing
usingresultsa showing
tshark3 are the
16 times differences
increase
presented in execution
atineach step,1.the
Figure times
increase
The for decryption
ssldump shows based
in execution timeonwas
a similar file proporto
pattern
size usingso
tionally
tshark, tshark3
less
wethan are
16presented
decided it wasinnot
times. Figure 1. The ssldump
necessary to includeshows a similar
it. As pattern
expected, to tshark, time in
execution
so weFigure
decided2itillustrates
was not necessary to
the results include
of givenit. As
experimentsexpected, execution
based time
onrequire increases
the number of with
sessions. As
creases with file size, which is logical that larger files more time for packe
file size, which is logical given that larger files require more time for packet analysis and
the session
analysis and count increases,
decryption. the execution
Notably, while time
fileatsizes also
wererises
tested but, again,
at 4096K,
1K, 16K, the increase
256K, is no
and 4096K
decryption. Notably, while file sizes were tested 1K, 16K, 256K, and representing
strictly linear
representing acompared
16 times to the
increase session
at each count.
step, Interestingly,
the increase inthere is
execution
a 16 times increase at each step, the increase in execution time was proportionally less than
no significant
time was differ
propor
ence in performance
tionally
16 times. based on the cipher suite used, which is worth noting.
less than 16 times.
Figure 2 illustrates the results of experiments based on the number of sessions. As
the session count increases, the execution time also rises but, again, the increase is no
strictly linear compared to the session count. Interestingly, there is no significant differ
ence in performance based on the cipher suite used, which is worth noting.

Figure1.1.Execution
Figure Executiontime differences
time for file
differences forsizes.
file sizes.

Figure 2 illustrates the results of experiments based on the number of sessions. As the
session count increases, the execution time also rises but, again, the increase is not strictly
linear compared to the session count. Interestingly, there is no significant difference in
performance based on
Figure 1. Execution thedifferences
time cipher suite
forused, which is worth noting.
file sizes.

Figure 2. Execution time differences for number of sessions.

Figure2.2.Execution
Figure Executiontime differences
time for number
differences of sessions.
for number of sessions.
4.3. Decryption Tool Performance Analysis
Figure 3 shows the results of running tshark version 3 and version 4 with workloads
1K.10 and 4096K.10. As for the other parameters, we did not include them all because the
patterns are similar. tshark3 refers to the stock version that can be installed as a package on
Ubuntu server machines, while tshark4 is built from source code. The versions used were
3.2.3 for tshark3 and 4.0.6 for tshark4. While there are minor variations between cipher
 4.3. Decryption Tool Performance Analysis
Figure 3 shows the results of running tshark version 3 and version 4 with workloads
1K.10 and 4096K.10. As for the other parameters, we did not include them all because the
patterns are similar. tshark3 refers to the stock version that can be installed as a package
Electronics 2024, 13, 2876 7 of 15
on Ubuntu server machines, while tshark4 is built from source code. The versions used
were 3.2.3 for tshark3 and 4.0.6 for tshark4. While there are minor variations between ci-
pher suites, these are considered within the margin of experimental error. It is observed
suites, these are considered within the margin of experimental error. It is observed that
that tshark4 generally shows 10% to 20% better performance than tshark3. Therefore, for
tshark4 generally shows 10% to 20% better performance than tshark3. Therefore, for future
future experiments,
experiments, tshark3
tshark3 is is excluded,
excluded, and only
and only tshark4 tshark4
is used is usedtesting.
for further for further testing.

Figure 3.
Figure Execution time
3. Execution timedifferences
differences between tshark
between version
tshark 3 and3version
version 4.
and version 4.
Next, to compare tshark and ssldump, we conducted experiments in the same way
Next, Figure
as before. to compare tshark
4 presents theand ssldump,differences
performance we conducted experiments
between tshark andinssldump.
the same way
as before. Figure 4 presents the performance differences between tshark andthe
This experiment utilized the 1K.10 and 4096K.10 workloads, and the results show that ssldump.
This
two experiment
tools exhibit utilized
opposite the 1K.10 andtrends.
performance 4096K.10
Whenworkloads, and the
using the 1K.10 results show
workload, tsharkthat the
two tools exhibit
demonstrates oppositesuperior
significantly performance trends.whereas,
performance When using the4096K.10
with the 1K.10 workload,
workload, tshark
ssldump performs
demonstrates much better.
significantly superior performance whereas, with the 4096K.10 workload,
The completely opposite
ssldump performs much better. performance trends between the two decryption tools de-
pending on file size differences are noteworthy. In the 1K.10 workload, tshark4 is much
faster while, in the 4096K.10 workload, ssldump shows better results. Therefore, to further
evaluate the performance of tshark and ssldump across all workloads, we conducted a
comprehensive comparison. Since the differences between ciphersuites are not significant,
the results of experiments conducted using only the ECDHE-RSA-AES256-GCM-SHA384
for all workloads are shown in Table 4. The execution time marked in red indicates better
performance, and the ratio column indicates how much better one performs compared
to the other. tshark exhibits up to 27 times better performance for 1K.1000 workloads,
whereas ssldump shows up to 25 times improved performance in the 65,536K.10 workload.
These experimental results suggest that ssldump tends to perform better when dealing
 Electronics 2024, 13, 2876 8 of 15

Electronics 2024, 13, x FOR PEER REVIEW 8 of 15

with larger single encrypted contents, whereas tshark yields superior performance when
handling smaller size packages.

Figure
Figure 4. 4. Execution
Execution time
time differences
differences between
between tshark
tshark and
and ssldump.
ssldump.
Table 4. Execution time differences between tshark and ssldump.
The completely opposite performance trends between the two decryption tools de-
pending onSize
File file size differences
Sessionare noteworthy.
TsharkIn the 1K.10 workload, tshark4Ratio
Ssldump is much
faster while,
1K in the 4096K.10 workload,
10 ssldump0.29shows better results.
2.74 Therefore, to further
9.45
evaluate the1K performance of
100 tshark and ssldump
0.82 across all workloads,
15.51 we conducted
18.91 a
comprehensive
1K comparison. Since the differences
1000 5.72 between ciphersuites
157.07 are not significant,
27.46
the results 16K 10
of experiments conducted 1.97
0.36 the ECDHE-RSA-AES256-GCM-SHA384
using only 5.47
256K 10 0.97 2.47
for all workloads are shown in Table 4. The execution time marked in red indicates 2.55better
4096K 10 10.59 1.69 0.16
performance, and the ratio column indicates how much better one performs compared to
4096K 1000 1259.35 279.22 0.22
the other. tshark exhibits up
65,536K 10 to 27 times 119.99
better performance for 1K.1000 workloads,
5.21 0.04
whereas ssldump
The text in shows
bold and red showsuptheto 25 times
minimum improved
execution performance
time within in the 65,536K.10 work-
the same workload.
load. These experimental results suggest that ssldump tends to perform better when deal-
ing with
4.4. larger single
Performance encrypted
Analysis contents,
of TLS Protocol whereas tshark yields superior performance
Versions
when handling smaller size packages.
To analyze performance across different TLS protocol versions, we conducted a com-
parative experiment with TLS versions 1.0, 1.1, 1.2, and 1.3. The evaluation was performed
Table 4. Execution
using time and
both tshark4 differences between
ssldump, withtshark and ssldump.
a 4096K.10 workload. However, TLS versions 1.0
andFile
1.1Size
are no longer supported
Session by the industry
Tshark and are not available in NginxRatio
Ssldump web servers.
Attempts
1K to establish communication
10 with versions 1.0 and2.74
0.29 1.1 resulted in failure.
9.45
The
1K results comparing100 TLS 1.2 and TLS
0.82 1.3 are shown in Figure 5. Using
15.51 tshark, we
18.91
1K that TLS 1.3 takes
observed 1000 slightly longer
5.72than TLS 1.2. However,
157.07 27.46ssldump,
when using
16K
the performance 10
was similar 0.36
within the margin 1.97
of experimental 5.47
error. This suggests that
256K 10 0.97 2.47 2.55
there is no significant difference in decryption performance between TLS 1.2 and TLS 1.3.
4096K 10 10.59 1.69 0.16
4096K 1000 1259.35 279.22 0.22
65,536K 10 119.99 5.21 0.04
 using both tshark4 and ssldump, with a 4096K.10 workload. However, TLS versions 1.0
and 1.1 are no longer supported by the industry and are not available in Nginx web serv-
ers. Attempts to establish communication with versions 1.0 and 1.1 resulted in failure.
The results comparing TLS 1.2 and TLS 1.3 are shown in Figure 5. Using tshark, we
Electronics 2024, 13, 2876 observed that TLS 1.3 takes slightly longer than TLS 1.2. However, when using ssldump, 9 of 15
the performance was similar within the margin of experimental error. This suggests that
there is no significant difference in decryption performance between TLS 1.2 and TLS 1.3.
Therefore,
Therefore,from
from aa decryption
decryption performance
performanceperspective,
perspective,the
thechoice
choice between
between TLSTLS
1.2 1.2
andandTLS
TLS
1.3 does not show substantial significance. Therefore, we used TLS 1.2 which is theismost
1.3 does not show substantial significance. Therefore, we used TLS 1.2 which the
most popular
popular afterafter Section
Section 5. 5.

Executiontime
Figure5.5.Execution
Figure timedifferences
differencesbetween
betweenTLS
TLSversion
version1.2
1.2and
and1.3.
1.3.

4.5. Library and Function Levels Performance Analysis

4.5. Library and Function Levels Performance Analysis
To conduct a more detailed analysis of tshark and ssldump, we used the perf tool to
To conduct
examine a more at
performance detailed analysis
the library and of tshark levels.
function and ssldump, we used
Given that the perf
previous tool to
evaluations
examine performance at the library and function levels. Given that previous evaluations
indicated minimal differences across cipher suites, we selected two representative cipher
indicated minimal differences across
suites; AES256-GCM-SHA384 cipher suites, we selected two representative
and ECDHE-RSA-AES256-GCM-SHA384. The 1K.1000cipher
and
suites; AES256-GCM-SHA384 and ECDHE-RSA-AES256-GCM-SHA384.
4096K.10 workloads were used for each cipher suite. The 1K.1000 and
4096K.10
For workloads
tshark, wewere used that
observed for each cipher suite.of execution time attributed to the de-
the proportion
For tshark, we observed that the proportion of executiondoes
cryption library was less than 1%, indicating that decryption timenotattributed to the
significantly de-
impact
cryption library was less than 1%, indicating that decryption does not significantly
the total execution time. This trend holds regardless of the cipher suite and workload. Inimpact
contrast, ssldump showed a slightly higher proportion for the decryption library compared
to tshark, but it was still relatively low at about 4%, suggesting that decryption is not
a major factor in the overall execution time. Additionally, functions like print_data() or
putc() accounted for a significant proportion of the execution time, indicating that output
operations, such as printing results, are a substantial part of the total time, likely exceeding
the time spent on packet analysis and decryption.
To determine the impact of decryption on overall execution time, we compared the
time taken with and without decryption. Figure 6 shows the results. In the case of tshark,
the difference is not significant, indicating that decryption does not consume significant
CPU time. On the other hand, ssldump shows a more noticeable time difference, likely due
to the additional time required to output the decrypted data. Thus, it can be concluded
that the decryption part has a minimal impact on overall tshark or ssldump performance.
 the difference is not significant, indicating that decryption does not consume significant
CPU time. On the other hand, ssldump shows a more noticeable time difference, likely
due to the additional time required to output the decrypted data. Thus, it can be con-
Electronics 2024, 13, 2876 cluded that the decryption part has a minimal impact on overall tshark or ssldump per-
10 of 15
formance.

Figure 6. Execution time differences between decryption and non-decryption.

Figure 6. Execution time differences between decryption and non-decryption.
5. Enhancing Decryption Performance
5. Enhancing
5.1. Decryption
Session Based Performance
Split and Conquer
5.1. Session Basedthe
To leverage Split and Conquer
benefits of multicore processors and maximize performance, it is worth
considering running
To leverage tshark
the or ssldump
benefits in parallel
of multicore on multipleand
processors cores. However,performance,
maximize tshark and it is
ssldump are not designed to operate in a multi-threaded manner. This design choice is
worth considering running tshark or ssldump in parallel on multiple cores. However,
based on the understanding that the overhead associated with packet disassembly and
tshark and ssldump
reassembly are not designed
in a multi-threaded to operate
environment wouldinresult
a multi-threaded manner. This
in similar performance to a design
choice
single-threaded approach. Therefore, instead of implementing multi-threaded versionsdisassem-
is based on the understanding that the overhead associated with packet of
bly andand
tshark reassembly
ssldump, in weapropose
multi-threaded
a methodenvironment
to run them inwould result
parallel usingina similar performance
multi-process
to a single-threaded
approach, approach.
thereby maximizing Therefore, of
the advantages instead of implementing
multicore multi-threaded
processors [18,19]. Specifically, ver-
we suggest
sions splitting
of tshark and assldump,
single target
we pcap file into
propose multiple
a method tosmaller
run thempcapinfiles and running
parallel using a multi-
multiple instances of tshark or ssldump simultaneously to achieve parallelization.
There are various approaches to splitting pcap files, including by time, packet count,
or session. After evaluating all these methods, we found that splitting by session was the
most stable, because each session might contain all the payload required for decryption. If
the file is split by time or packet count, parts of the payload could get cut off, preventing
successful decryption. Therefore, we implemented a program to automate this process,
naming the technique Session-based Split and Conquer (SSC).
For SSC, it is crucial to consider the ability to split by session and minimize overhead
during the splitting process. The most widely used tool for splitting pcap files is editcap,
which is part of the Wireshark tool package. However, editcap does not support session-
based splitting. Another tool that supports session-based splitting is SplitCap, but it only
 naming the technique Session-based Split and Conquer (SSC).
For SSC, it is crucial to consider the ability to split by session and minimize overhead
during the splitting process. The most widely used tool for splitting pcap files is editcap,
which is part of the Wireshark tool package. However, editcap does not support session-
Electronics 2024, 13, 2876 11 ofbut
15 it only
based splitting. Another tool that supports session-based splitting is SplitCap,
provides executables for Windows, making it unsuitable for SSC. Among open-source
tools, PcapPlusPlus was ultimately selected, as it is open-source, supports session-based
provides executables for Windows, making it unsuitable for SSC. Among open-source tools,
splitting, and is written in C++, offering excellent performance. We modified the source
PcapPlusPlus was ultimately selected, as it is open-source, supports session-based splitting,
code
and isofwritten
PcapPlusPlus to integrate
in C++, offering it into
excellent SSC.
performance. We modified the source code of
To implement session-based
PcapPlusPlus to integrate it into SSC. splitting and multi-process parallelization, we devel-
opedTo a Python
implement program to automate
session-based splittingthe
andSSC technique.parallelization,
multi-process To optimizewe thedeveloped
process of split-
ting and parallelization,
a Python program to automate we configured the workflow
the SSC technique. to split
To optimize in-memory
the process and provide
of splitting and it as
parallelization,
input to tsharkwe or configured
ssldump. the Thisworkflow to splitby
was achieved in-memory and provide
using tmpfs, it as inputfilesystem,
an in-memory to
tshark or ssldump. This was achieved by using tmpfs, an in-memory filesystem,
which completely eliminates disk I/O and avoids the overhead of accessing the OS-level which
completely
page cache.eliminates
This approachdisk I/O
wasand avoidsthe
deemed themost
overhead of accessing
effective the OS-level
optimization pageFigure 7
strategy.
cache. This approach was deemed the most effective optimization strategy. Figure 7 shows
shows the working differences between conventional process and SSC process. The num-
the working differences between conventional process and SSC process. The number of
ber of splitted
splitted pcap
pcap files files is automatically
is automatically set toasthe
set to the same thesame
numberas the number of cores.
of cores.

Figure 7. Process diagram of conventional tool and SSC.

Figure 7. Process diagram of conventional tool and SSC.
5.2. Evaluation Environment
5.2. Evaluation
To compareEnvironment
the performance of parallel processing decryption of SSC with traditional
decryption, the evaluation environment was set as previously described in Table 2. In this
To compare the performance of parallel processing decryption of SSC with tradi-
study, we compare the decryption performance of tshark in the native environment, SSC
tional decryption, the evaluation environment was set as previously described in Table 2.
in the normal environment (denoted by disk), SSC in the asynchronous disk environment
In this study,
(denoted we compare
by async), and SSC inthe
the decryption performance
in-memory environment of tshark
(denoted in the native
by in-memory) usingenviron-
ment,
Machine A to see the performance differences between the disk environments that use SSC. disk
SSC in the normal environment (denoted by disk), SSC in the asynchronous
environment (denotedthe
We also compare bydecryption
async), and SSC in the between
performance in-memory environment
native tshark4, SSC(denoted
tshark, by in-
memory) using Machine
and SSC ssldump A to see
using Machine the performance
A and differences
B to see the difference between the
in performance disk environ-
between
decryption tools
ments that use SSC. using SSC. In this evaluation, to compare performance differences based
on packet size and number, we additionally used workloads consisting
We also compare the decryption performance between native tshark4, SSC of 1000 sessions of tshark,
1 KB each, 10 sessions of 4096 KB each, and 10 sessions of 65,536 KB each.
and SSC ssldump using Machine A and B to see the difference in performance between
decryption tools
5.3. Performance using between
Analysis SSC. InDisk
this Environments
evaluation, to compare
When performance differences based
Using SSC
on packet size and number, we additionally used workloads
Using Machine A, we compared decryption performance between consisting
tshark in of 1000 sessions
a normal
of 1 KB each,with
environment 10 sessions of in
SSC, tshark 4096 KB each, anddisk
an asynchronous 10 environment
sessions of 65,536 KBand
with SSC, each.
tshark in
an in-memory environment with SSC. Figure 8 shows the decryption times for ten 4096 KB
packets encrypted with TLSv1.2_AES256_GCM_SHA384 under each condition. The split
legend indicates the time taken to split the pcap file, while the decryption legend represents
the time taken for decryption.
In this evaluation, compared to the execution time of tshark in a native single-processor
environment, the use of SSC resulted in significant time reductions in different storage
environments. Specifically, in a standard disk environment, SSC achieved a 40.2% reduction
in time. In an asynchronous disk environment, the time reduction was 50.3%. The most
significant improvement was observed in an in-memory environment, where the time
reduction reached 68.2%.
 In this evaluation, compared to the execution time of tshark in a native single-proces-
sor environment, the use of SSC resulted in significant time reductions in different storage
environments. Specifically, in a standard disk environment, SSC achieved a 40.2% reduc-
tion in time. In an asynchronous disk environment, the time reduction was 50.3%. The
Electronics 2024, 13, 2876 most significant improvement was observed in an in-memory environment, where the
12 of 15
time reduction reached 68.2%.

Figure 8. Detailed performance analysis of SSC in different disk environments compared to tradi-
Figure 8. Detailed performance analysis of SSC in different disk environments compared to tradi-
tional
tional tshark.
tshark.
5.4. Performance Differences between SSC with Tshark and Ssldump
5.4. Performance Differences between SSC with Tshark and Ssldump
Initially, the decryption performance was compared among tshark, SSC with tshark,
andInitially,
SSC withthe decryption
ssldump performance
for workloads was compared
consisting amongof
of 1000 sessions tshark, SSCand
1 KB size with
10tshark,
sessions
and SSC with ssldump for workloads consisting of 1000 sessions of 1KB size
of 4096 KB size using machine A. As shown in Figure 9, for a large number of small-sized and 10 ses-
sions of 4096KB
sessions, size using
SSC with tsharkmachine A. As shown
proved superior in Figureacross
performance 9, for aalllarge number
cipher suites.ofSSC
small-
with
Electronics 2024, 13, x FOR PEER REVIEW 13 of 15
sized
ssldump showed lower performance, consistent with its inherent low performance forSSC
sessions, SSC with tshark proved superior performance across all cipher suites. 1000
with ssldump
sessions of 1 showed
KB size inlower performance, consistent with its inherent low performance
the baseline.
for 1000 sessions of 1KB size in the baseline.
However, as shown in Figure 10, for the workload decrypting 10 sessions of 4096KB
size, SSC with ssldump demonstrated exceptionally high performance. This indicates that
the performance difference originates from the inherent performance disparity between
tshark and ssldump, as previously described.

Figure 9.
Figure 9. Performance comparison of SSC with tshark and ssldump
ssldump (1K.1000).
(1K. 1000).

However, as shown in Figure 10, for the workload decrypting 10 sessions of 4096 KB
size, SSC with ssldump demonstrated exceptionally high performance. This indicates that
the performance difference originates from the inherent performance disparity between
tshark and ssldump, as previously described.
To further clarify the performance differences, we conducted evaluations using huge
pcap files and Machine B. The same decryption methods were utilized to decrypt 1000 ses-
sions of 4096 KB size and 10 sessions of 65,536 KB size. As described in Figure 11, when
using significantly larger volumes of data, a reduction in time by up to 39 times was noted,
demonstrating the efficiency of SSC.

Figure 10. Performance comparison of SSC with tshark and ssldump (4096K.10).

To further clarify the performance differences, we conducted evaluations using huge

pcap files and Machine B. The same decryption methods were utilized to decrypt 1000
sessions of 4096KB size and 10 sessions of 65,536KB size. As described in Figure 11, when
 Electronics 2024, 13, 2876 13 of 15
Figure 9. Performance comparison of SSC with tshark and ssldump (1K. 1000).

Figure 10. Performance comparison of SSC with tshark and ssldump (4096K.10).

To further clarify the performance differences, we conducted evaluations using huge

pcap files and Machine B. The same decryption methods were utilized to decrypt 1000
sessions of 4096KB size and 10 sessions of 65,536KB size. As described in Figure 11, when
using significantly larger volumes of data, a reduction in time by up to 39 times was noted,
demonstrating the efficiency of SSC.
10. Performance comparison of SSC with tshark and
Figure 10. and ssldump
ssldump (4096K.10).
(4096K.10).

To further clarify the performance differences, we conducted evaluations using huge

pcap files and Machine B. The same decryption methods were utilized to decrypt 1000
sessions of 4096KB size and 10 sessions of 65,536KB size. As described in Figure 11, when
using significantly larger volumes of data, a reduction in time by up to 39 times was noted,
demonstrating the efficiency of SSC.

Electronics 2024, 13, x FOR PEER REVIEW 14 of 15

Figure
Figure 11. Performance
11. Performance comparison
comparison of SSC
of SSC withwith tshark
tshark andand ssldump
ssldump (4096K.1000,
(4096K.1000, 65,536K.10).
65,536K.10).
6. Discussion
6. Discussion
SSC exhibits superior performance aspects but also presents drawbacks. To utilize the
SSC exhibits superior performance aspects but also presents drawbacks. To utilize the
in-memory approach, a certain amount of memory must be allocated through tmpfs, and
in-memory approach, a certain amount of memory must be allocated through tmpfs, and
the memory occupied by the process itself must also be considered. A method to offset these
the memory occupied by the process itself must also be considered. A method to offset these
memory requirements involves reducing the number of disk I/O operations at the program
memory
level.requirements
However, even involves reducing the number
with optimization throughof disk
this I/O operations
in-memory at the
method, it program
was proved
level. However, even with optimization through this in-memory method, it was proved
that the advantages of the in-memory approach, which eliminates disk I/O and reduces that
the the
advantages of the in-memory approach, which eliminates disk I/O and reduces the
overhead of accessing the page cache at the OS Level, outweigh the disadvantages. over-
head of accessing the page cache at the OS Level, outweigh the disadvantages.

7. Conclusions
In this study, we present a detailed performance analysis using tshark and ssldump,
which are commonly used for decrypting encrypted traffic. According to the research find-
ings, tshark exhibited superior performance for small packet sizes, whereas ssldump
showed excellent performance for large packet sizes. Based on this analysis, we propose
Electronics 2024, 13, 2876 14 of 15

7. Conclusions
In this study, we present a detailed performance analysis using tshark and ssldump,
which are commonly used for decrypting encrypted traffic. According to the research
findings, tshark exhibited superior performance for small packet sizes, whereas ssldump
showed excellent performance for large packet sizes. Based on this analysis, we propose
SSC, a method that involves splitting pcap files by session and applying multiprocessing to
perform TLS decryption. This method achieves performance improvements by utilizing
conventional decryption tools, such as tshark and ssldump. Particularly, by optimizing in
an in-memory environment, it has been able to enhance decryption performance compared
to existing approaches. While the approach of SSC in this study has been primarily focused
on TLS encrypted traffic, it is believed that similar performance improvement effects can
be expected for other encryption methods. SSC achieved up to 39 times improvement
in performance when using CS2 with the ssldump.4096K.1000 workload, reducing time
from 221 s to 5.71 s. These outcomes demonstrate the potential value of SSC in the ar-
eas of network traffic and network security, suggesting efficient decryption for various
encryption protocols.
As future work, the differences in decryption tools required by the workload pattern
must also be considered. As observed in Section 5, tshark shows significant performance
regardless of the number of small-sized packets it handles. However, ssldump consistently
outperforms tshark when dealing with large-sized packets. The reason for this performance
divergence depending on the workload pattern requires a detailed analysis based on the
structure of each encryption library, libgcrypt for tshark and libcrypto for ssldump.

Author Contributions: Conceptualization, M.J. and H.J. (Hayong Jeong); Software, B.S.; Writing—original
draft, M.J., H.J. (Hayong Jeong), B.S. and H.J. (Heeseung Jo). All authors have read and agreed to the
published version of the manuscript.
Funding: This work was supported by Electronics and Telecommunications Research Institute (ETRI)
grant funded by the Korean government [24ZS1100, Research on High-Performance Computing to
overcome Limitations of AI].
Data Availability Statement: Data are contained within the article.
Conflicts of Interest: The authors declare no conflict of interest.

References
1. Rijmen, V.; Daemen, J. Advanced encryption standard. Proc. Fed. Inf. Process. Stand. Publ. Natl. Inst. Stand. Technol. 2001, 19, 22.
2. Diffie, W.; Hellman, M.E. Exhaustive cryptanalysis of the NBS data encryption standard. In Democratizing Cryptography: The Work
of Whitfield Diffie and Martin Hellman; ACM: New York, NY, USA, 2022; pp. 391–414.
3. Schneier, B. Description of a new variable-length key, 64-bit block cipher (Blowfish). In Proceedings of the International Workshop
on Fast Software Encryption, Cambridge, UK, 9–11 December 1993; Springer: Berlin/Heidelberg, Germany, 1993; pp. 191–204.
4. Schneier, B. The Twofish encryption algorithm. Dr. Dobb’s J. Softw. Tools Prof. Program. 1998, 23, 30–34.
5. Rivest, R.L.; Shamir, A.; Adleman, L. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM
1978, 21, 120–126. [CrossRef]
6. Koblitz, N.; Menezes, A.; Vanstone, S. The state of elliptic curve cryptography. Des. Codes Cryptogr. 2000, 19, 173–193. [CrossRef]
7. Diffie, W.; Hellman, M.E. New directions in cryptography. In Democratizing Cryptography: The Work of Whitfield Diffie and Martin
Hellman; ACM: New York, NY, USA, 2022; pp. 365–390.
8. TCPDump&Libpcap. Available online: https://www.tcpdump.org/ (accessed on 6 March 2024).
9. Anderson, B.; Chi, A.; Dunlop, S.; McGrew, D. Limitless http in an https world: Inferring the semantics of the https protocol
without decryption. In Proceedings of the Ninth ACM Conference on Data and Application Security and Privacy, Richardson, TX,
USA, 25–27 March 2019; pp. 267–278.
10. Wilkens, F.; Haas, S.; Amann, J.; Fischer, M. Passive, transparent, and selective TLS decryption for network security monitoring.
In Proceedings of the IFIP International Conference on ICT Systems Security and Privacy Protection, Openhagen, Denmark,
13–15 June 2022; Springer International Publishing: Cham, Switzerland, 2022; pp. 87–105.
11. Husák, M.; Čermák, M.; Jirsík, T.; Čeleda, P. HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting.
EURASIP J. Inf. Secur. 2016, 2016, 6. [CrossRef]
Electronics 2024, 13, 2876 15 of 15

12. Moriconi, F.; Levillain, O.; Francillon, A.; Troncy, R. X-ray-TLS: Transparent decryption of TLS sessions by extracting session keys
from memory. In Proceedings of the 19th ACM ASIA Conference on Computer and Communications Security (ACM ASIACCS),
Singapore, 1–5 July 2024.
13. Sosnowski, M.; Wiedner, F.; Hauser, E.; Steger, L.; Schoinianakis, D.; Gallenmüller, S.; Carle, G. The performance of post-quantum
tls 1.3. In Proceedings of the Companion of the 19th International Conference on emerging Networking Experiments and
Technologies, Paris, France, 5–8 December 2023; pp. 19–27.
14. Yildiz, B.V. The State of HTTPS Configuration of Public Websites Around the World. Bachelor’s Thesis, University of Twente,
Enschede, The Netherlands, 2023.
15. Yoon, J.; Do, S.; Kim, D.; Chung, T.; Park, K. Scaling the Performance of Modern TLS Traffic Monitoring without Compromising
the Security. Available online: https://www.ndsl.kaist.edu/~kyoungsoo/papers/mmTLS_poster.pdf (accessed on 15 July 2024).
16. Naylor, D.; Li, R.; Gkantsidis, C.; Karagiannis, T.; Steenkiste, P. And then there were more: Secure communication for more
than two parties. In Proceedings of the 13th International Conference on emerging Networking EXperiments and Technologies,
Incheon, Republic of Korea, 12–15 December 2017; pp. 88–100.
17. Lee, H.; Smith, Z.; Lim, J.; Choi, G.; Chun, S.; Chung, T.; Kwon, T.T. maTLS: How to Make TLS middlebox-aware? In Proceedings
of the Network and Distributed Systems Security (NDSS) Symposium 2019, San Diego, CA, USA, 24–27 February 2019.
18. Multi-Threaded Tshark. Available online: https://osqa-ask.wireshark.org/questions/56433/multi-threaded-tshark/ (accessed
on 15 July 2024).
19. Does Wireshark Support Multi-Threading for Packet Parsing? Available online: https://ask.wireshark.org/question/33511/
does-wireshark-support-multi-threading-for-packet-parsing/ (accessed on 15 July 2024).

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual
author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to
people or property resulting from any ideas, methods, instructions or products referred to in the content.