# Passive, Transparent, and Selective TLS Decryption for Network Security Monitoring

Florian Wilkens, Steffen Haas, Johanna Amann, Mathias Fischer

► To cite this version:

Florian Wilkens, Steffen Haas, Johanna Amann, Mathias Fischer. Passive, Transparent, and Selective TLS Decryption for Network Security Monitoring. 37th IFIP International Conference on ICT Systems Security and Privacy Protection (SEC), Jun 2022, Copenhagen, Denmark. pp.87-105, 10.1007/978-3-031-06975-8_6. hal-05319893

HAL Id: hal-05319893

https://inria.hal.science/hal-05319893v1

Submitted on 17 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Passive, Transparent, and Selective TLS
# Decryption for Network Security
# Monitoring

Florian Wilkens<fnref n="1" />(✉), Steffen Haas<fnref n="1" />, Johanna Amann², and Mathias Fischer<fnref n="1" />

¹ Universität Hamburg, Hamburg, Germany
{florian.wilkens,steffen.haas mathias.fischer}@uni-hamburg.de

² International Computer Science Institute (ICSI), Berkeley, USA
johanna@icir.org

**Abstract.** More and more Internet traffic is encrypted. While this protects the confidentiality and integrity of communication, it prevents network monitoring systems (NMS) from effectively analyzing the now encrypted payloads. Many enterprise networks have deployed man-in-the-middle (MitM) proxies that intercept TLS connections at the network border to examine packet payloads and to regain visibility. However, TLS interception via MitM proxies often reduces connection security and potentially introduces additional attack vectors.

In this paper, we present a cooperative approach in which endpoints selectively send TLS keys to the NMS for decrypting TLS connections. This enables hosts to control which TLS connections an NMS can decrypt and lets users retain privacy for chosen connections. We implement a prototype based on the Zeek NMS that is able to receive key material from hosts, decrypt TLS connections, and analyze the cleartext. Meanwhile, our patch was merged into Zeek upstream and will be part of Zeek v4.3.0. In our evaluation, we initially compare our approach to MitM proxies and can deduce that it significantly reduces the computational overhead. Furthermore, our experimental results on real-world traffic indicate that our TLS decryption adds a runtime overhead of 2.5 times compared to the analysis of cleartext. Additionally, our results indicate that when buffering traffic for only short amounts of time at the NMS, all keys from the hosts arrive in time to completely decrypt 99,99% of all observed TLS connections.

**Keywords:** TLS · NMS · MitM · Network security monitoring · Man-in-the-middle

## 1 Introduction

Nowadays, the majority of Internet traffic is encrypted, and the biggest share of it by Transport Layer Security (TLS). For example, Google reports that about 90% of all websites visited by their Chrome browser use HTTPS<fnref n="1" />. However, TLS

<footnote n="1">¹ https://transparencyreport.google.com/https/overview.</footnote>

<footnote>© IFIP International Federation for Information Processing 2022</footnote>

<footnote>Published by Springer Nature Switzerland AG 2022</footnote>

<footnote>W. Meng et al. (Eds.): SEC 2022, IFIP AICT 648, pp. 87–105, 2022.</footnote>

<footnote>https://doi.org/10.1007/978-3-031-06975-8_6</footnote>
prevents the analysis of packet payloads by network monitoring systems (NMS) and restrict them to connection metadata. While some of these systems can work with metadata only [1], most NMSs require the cleartext payload, i.e., deep packet inspection [2]. Especially in the context of security monitoring, access to cleartext payloads is essential for real-time intrusion detection and for forensic analysis as part of incident response. While metadata can help to identify simple attacks in the network, payload data is required to identify the attack vector and tools the attacker used throughout the incident. In enterprise network administrators often deploy mandatory man-in-the-middle (MitM) proxy servers that terminate TLS at the organization boundary to enable effective security monitoring. These proxies then forward decrypted traffic to an NMS for cleartext payload analysis. However, terminating TLS connections raises several concerns:

1. MitM proxies raise privacy concerns for users as all traffic is intercepted without exception. While this is reasonable in high-security environments, a regular enterprise network should let users retain privacy for domains unlikely to endanger the network.

2. The integrity of the TLS connection is not guaranteed to be end-to-end (with regards to the client and server endpoints), as the MitM proxy essentially maintains two separate TLS connections to client and server and relays messages between them. Thus, a compromised MitM proxy is able to transparently forge packets that both endpoints will treat as valid from the respective counterparty.

3. MitM proxies add a potential attack vector to the network that needs to be maintained. This is especially important as the proxy has complete access to the traffic and could arbitrarily modify it. Recent studies have confirmed, that this setup often weakens the overall connection security [4, 6, 9, 15, 16, 18].

The main contribution of this paper is a generic system for the passive inspection of TLS encrypted traffic without the need for a MitM proxy. Instead, we suggest that endpoints *selectively* forward TLS key material to an NMS, so that it can directly decrypt and analyze packets in TLS connections without intercepting or otherwise modifying the connections. In contrast to other state-of-the-art solutions like MitM proxies or TLS extensions for multi-entity support [3], our approach:

- works without modifications of the TLS protocol,

- adds no additional latency to TLS session establishment,

- enables only trusted observers to inspect cleartext payloads of TLS connections,

- supports policy-based, partial traffic inspection, that is enforced directly on endpoints,

- and preserves the end-to-end integrity of the TLS session for non-authenticated encryption with associated data (AEAD) cipher suites as the NMS only receives decryption keys but no integrity keys.
We implement our approach as a proof-of-concept (PoC) module for the open-source NMS Zeek [17] that can receive key material from endpoints and use it to decrypt TLS connections. The resulting payloads are transparently passed to Zeek's builtin analyzers for inspection. Our patch is available on GitHub<fnref n="2" /> and already has been merged into Zeek mainline. We evaluate our prototype in two different dimensions: (i) We measure the *decryption overhead* by comparing the computational overhead for processing encrypted and cleartext traffic. (ii) We estimate the *impact of key transfer latency* between client and NMS on the number of decrypted packets, bytes, and connections. Our results indicate that decryption imposes a 2.5 times computational overhead compared to the processing of equivalent not encrypted traffic. The latency for key transfer is rather low and requires only a small traffic buffer (of about 40 ms) infront of the NMS to decrypt 99.99% of observed TLS connections in small deployments.

The remainder of the paper is structured as follows: Sect. 2 states objectives for our approach and reviews the state of the art. Section 3 introduces our approach on passive and transparent TLS decryption. Section 4 discusses the computational complexity of our approach compared to MitM proxies, describes our prototype, and summarizes our performance evaluation based on the Alexa Top 1000 websites. Section 5 concludes the paper.

# 2 Objectives and State of the Art

In this section, we describe objectives for passive and transparent TLS decryption on an NMS. Additionally, we summarize and discuss the state of the art in the areas of MitM proxies, and TLS protocol modifications along our objectives.

## 2.1 Objectives for Passive TLS Decryption

Before we summarize state of the art in the next section, we briefly describe objectives for the goal of passive TLS decryption already outlined in Sect. 1. These objectives are used to evaluate both related work and our own concept and prototype described later. To regain visibility into encrypted TLS traffic on a trusted NMS, a well-designed solution should exhibit the following properties:

- **No interception:** TLS is a well-designed protocol to ensure end-to-end data confidentiality and integrity between two endpoints. Additional entities, that intercept this connection, represent new and unwanted attack vectors that may weaken the security of the connection and break mutual authentication [4, 6, 9, 15, 16, 18].

- **No protocol modification:** TLS is deployed widespread across a wide variety of devices and networks. Thus, changes on the protocol-level are unlikely to gain enough traction for widespread adoption.

- **No additional latency:** While security and network monitoring is an important topic in any enterprise network, it should not deter the user experience by introducing additional latency to the connection.

<footnote n="2">² https://github.com/zeek/zeek/pull/1814.</footnote>
- **End-to-end data integrity:** The NMS needs to break end-to-end confidentiality between client and server to perform analysis tasks on the cleartext. However, it does not require integrity violation as application data only needs to be read.

- **Selective decryption:** Endpoints should be able selectively influence which connections are allowed to be decrypted by the NMS to let users retain some privacy for sensitive data. While high-security environments might require inspection of all network traffic, there are also scenarios in which total visibility is not feasible, e. g., for legal or compliance reasons.

- **Low maintenance effort:** Security monitoring is an essential service in an enterprise network and as such should require low maintenance for regular operations. This is both relevant for client machines and any middleboxes deployed in the network.

## 2.2 State of the Art

In this section, we review MitM proxies as current state-of-the-art for TLS visibility in enterprise networks as well as research in the areas of TLS protocol modifications and trusted execution environments. We compare all approaches with our objectives and which areas leave room for improvement.

**TLS Interception via MitM.** The most popular way to decrypt TLS traffic is to use a man-in-the-middle (MitM) proxy that terminates all connections and thus can access cleartext data. As industry best-practice this approach is often deployed in enterprise networks. Many implementations are available depending on the use-case and inner protocol that should be analyzed including open-source tools such as *mitmproxy* [5]. Commercial offerings for network security also often include a component that intercepts TLS either as a separate application or directly integrated into the NMS. Due to its popularity, TLS interception has been discussed broadly in recent years with the overwhelming consensus that it significantly weakens the security properties of intercepted connections [4, 6, 9, 15, 16, 18]. In [9] Jarmoc et al. discuss the security of intercepting end-to-end encryption in general. They state, that there is no implementation solely for the purpose of only intercepting TLS connections, but rather multiple classes of applications such as web proxies, data loss prevention system or network IDSs sometimes include an integrated feature for this. According to the authors all of them introduce potential risk into the environment they protect including legal peril, an increase in the overall threat surface by having a single point of decryption and a possible decreased cipher strength among others. More recently, Durumeric et al. [6] also confirm that intercepting proxies and the corresponding security degradation for clients are still prevalent. They find that there is an order of magnitude more interception than previously estimated. Additionally, they evaluate multiple middleboxes and conclude that nearly all reduce overall connection security and many introduce severe vulnerabilities.
**Modifications of the TLS Protocol.** TLS is designed to support end-to-end encryption between exactly two entities. However, there are proposals to add multi-entity support that would enable previously defined forwarding endpoints to decrypt the payload as well. In [13] the authors propose Multi-Context TLS (mcTLS) that extends the TLS header by multiple so-called contexts that act as a permission system and enable the client to allow selected middleboxes to read and write the TLS payload. However, mcTLS has two major downsides: (i) the additional contexts require additional computation on the client and add additional latency during connection establishment. (ii) the modified TLS header with contexts is incompatible to standard TLS and thus forces all nodes on the path to support mcTLS. The second downside is partially addressed in Middlebox TLS (mbTLS) also by Naylor et al. [12]. mbTLS extends the standard TLS handshake with a custom extension that middleboxes on the path can use to inject themselves into the connection with the client's consent. The endpoints then establish secondary TLS sessions with each of their respective middleboxes. To establish trust in the middleboxes, remote attestation via an enclave is used. Overall, this improves on mcTLS but (i) further complicates deployment and maintenance as middleboxes now require a hardware enclave and (ii) add additional latency through the secondary TLS sessions. Middlebox-aware TLS (maTLS) [10] modifies TLS, such that all middleboxes on the communication path explicitly forward security parameters to the client. This is implemented via a combination of Split TLS with added support of entity checks in a new TLS protocol. It ensures explicit authentication, security parameter validation to ensure confidentiality and modification validity checks for integrity. Like mcTLC, this also is incompatible to standard TLS with all the downsides. Similar to mcTLS and mbTLS the connection establishment requires additional computation time and delay is caused by the multiple entities that potentially perform computations on the connection. Legislators have also pushed to modify TLS encryption in a way that would allow access for law enforcement. Enterprise TLS (ETLS) [7] as proposed by the European Telecommunications Standards Institute (ETSI) adapts TLS 1.3 to make forward secrecy optional and keep the outdated RSA mode available. In practice service providers could then always use the same key and thus leave access to authorities, even at some point in the future.

<table><caption>**Table 1.** Objectives & state of the art. – not achieved (✓) partially achieved ✓ achieved</caption><thead><tr><td>Objective</td><td>MitM proxy</td><td>mbTLS/mcTLS [12, 13]</td><td>maTLS [10]</td><td>ETLS [7]</td></tr></thead><tbody><tr><td>No interception</td><td>–</td><td>–</td><td>–</td><td>✓</td></tr><tr><td>No protocol modification</td><td>✓</td><td>–</td><td>–</td><td>(✓)</td></tr><tr><td>No additional latency</td><td>–</td><td>–</td><td>–</td><td>✓</td></tr><tr><td>Selective decryption</td><td>–</td><td>(✓)</td><td>(✓)</td><td>(✓)</td></tr><tr><td>Low maintenance effort</td><td>(✓)</td><td>–</td><td>–</td><td>✓</td></tr><tr><td>E2E data integrity</td><td>–</td><td>(✓)</td><td>(✓)</td><td>–</td></tr></tbody></table>
**Summary.** Table 1 shoes the state of the art and marks which of our objectives are met by the respective approach. MitM proxies offer the advantage, that the TLS protocol does not need to be modified and maintenance effort is relatively low as only the proxy itself needs to be maintained and the CA needs to be deployed to clients. However, the proxy breaks the E2E data integrity, adds additional latency and conceptually cannot guarantee selective decryption. mcTLS and mbTLS modify the TLS protocol to support middleboxes through a permission system. Maintenance effort is high, as middleboxes and endpoints need to be kept in sync due to the protocol. maTLS checks the same of our objectives. Selective decryption and E2E integrity could potentially be implemented but are not the focus. ETLS checks most of our objectives but has a major flaw: perfect forward secrecy is intentionally disabled to allow external audits through a shared private key. This does not retain the user in control of which connections are decryptable and adds another attack vector as the shared key could be compromised. In summary, no approach fulfills all our objectives. We also note, that true selective decryption can only be achieved, if the client retains control over the TLS key material.

## 3 Passive TLS Decryption at an NMS

In this chapter, we describe the concept of passively decrypting TLS connections at a network monitoring system (NMS). We assume that hosts in a network protected by an NMS are also equipped with a privileged endpoint protection daemon. Figure 1 gives an overview about the complete process and components involved. First, the local daemon obtain TLS session keys. Second, it filters the key for sensitive connections according to policy. Third, they transfer the keys to the NMS. Fourth, the NMS matches the keys to connections and starts passive decryption and further analysis. Steps 1–3 are executed directly on the endpoint and do not require direct user interaction.

<figure><img src="image_3.png" /><figcaption>Fig. 1. Overview on passive TLS Decryption via cooperative endpoints</figcaption></figure>
Keeping authority over keys on the endpoints and performing the decryption directly at the NMS offers increased flexibility. (i) The endpoint can enforce policy-based control about which connections are allowed to be decrypted by the NMS by withholding keys for sensitive connections. (ii) The NMS can opt to skip decryption for performance reasons, e. g., for video conferencing or streaming content. Both use-cases are not easily possible with current state-of-the-art MitM proxies. A concern compared to enterprise MitM deployments might be that visibility could be lost if an attacker should manage to disable the endpoint protection daemon thus disabling key transfer and preventing decryption. However, such an incident would already be detected and flagged even in legacy deployments, as the endpoint protection daemon is already monitored for live-ness. Our approach might seem straight-forward on first sight. However, the individual steps encompass conceptual and technical challenges that we describe in greater detail in the following sections.

## 3.1 Obtaining TLS Keys on Endpoints

In the first step, TLS keys need to be obtained from the client machines as they represent the cryptographic endpoint. This is done in the context of the privileged endpoint protection daemon that has access to the network stack. A typical TLS connection, uses multiple secrets as well as session keys for different purposes. The simplest solution would be to obtain the pre-master secret and forward it to the NMS with the client random as the connection identifier. The NMS would then perform key derivation and obtain all session keys (and IVs if an AEAD cipher suite is used) to decrypt the encrypted application data packets. However, this enables the NMS to derive all session keys including the integrity keys. This would allow a compromised NMS to forge packets on behalf of both endpoints and thus introduce an additional attack vector to the network. For non-AEAD ciphers, we can mitigate this by only forwarding encryption keys to the NMS and keeping the integrity keys used by the HMAC on the client. Unfortunately, AEAD ciphers require both encryption keys and IVs to decrypt the data even if no integrity checks need to be performed by the NMS. From now on, we use the term keys synonymously with either just the encryption keys (if the cipher suite allows for that) or encryption keys and associated IVs. The keys can be obtained in multiple ways depending on operating system, cryptographic library, and application. There may even be a daemon collecting key material on the host already, e. g., `osquery`<fnref n="3" /> as part of a zeek-osquery deployment [8] or a Zeek Agent instance<fnref n="4" />. If keys need to be newly obtained, the simplest way is the **SSL keylog interface** supported by widely used cryptographic libraries such as openSSL and NSS [11]. If enabled, the libraries write TLS pre-master secrets and the corresponding client randoms to the file specified in an environment variable. While this approach is easy to deploy, it might introduce some problems: (i) The logfile is readable by the user, as the browser process is running with user

<footnote n="3">³ https://www.osquery.io/.</footnote>

<footnote n="4">⁴ https://github.com/zeek/zeek-agent-v2.</footnote>
permissions. (ii) Writing secrets to a file and reading them in the aftermath via an application adds additional latency. While this can be partially addressed by using a RAM disk, the NMS might receive keys too late and the first few packets of a TLS connection cannot be decrypted. The **kernel TLS (kTLS)** interface [19] offers another way to obtain the desired keys. kTLS was introduced to the Linux kernel in version 4.13 and moves the TLS packet handling to kernel space. At the time of writing only a limited subset of AEAD cipher suites is supported. To use it, an application opens a regular socket and performs a normal TLS setup via key exchange and derivation. Next, it configures the encryption key as well as IV for the socket via a **setsockopt** system call. From that point on, regular **send** and **receive** operations can be used with the kernel performing encryption and integrity checks. A process with elevated permissions can monitor this system call for keys, extract and forward them to the NMS.

## 3.2 Client-Side Filtering of Sensitive Connections

Once the keys have been obtained by the daemon on the endpoint, it has to decide if the keys should be forwarded to the NMS to enable decryption of the associated connection. This filtering process considers connections attributed like IP addresses, hostnames and domains name to mark a connection as sensitive according to both network and user policy. For sensitive connections, the daemon does not transfer the keys to the NMS, forcing it to fall back to metadata-only analysis. Overall the decision to mark connections as sensitive is governed by:

- The **network policy** establishes the baseline for which connections must be decrypted and thus which keys need to be always forwarded. This will often be a "forward-by-default" policy, as the organization wants as much visibility as possible. However, there are cases where full visibility must not be required, e. g., legal or compliance scenarios in which certain information is not allowed to be decrypted. An example would be medical data in the health-care sector. Such scenarios require a more sensible network policy, that enforces visibility for selected services only and cannot use existing MitM proxies that decrypt all TLS traffic.

- **User policy:** It complements the network policy by allowing the user to opt-out of decryption for selected services that are not covered by the network policy already. The user policy can be implemented via a self-serve portal where users can submit opt-out requests for certain domains (or in special cases IP addresses/hostnames). After review the updated policy is installed on the endpoint. Naturally, the user policy has to be sanctioned by security personnel and thus will likely not allow the user to retain privacy for all desired services. In these cases the network policy would likely overrule the user choice. However, the conceptual mechanism to include user choices itself already offers a large advantage compared to MitM proxies that decrypt all communication without any direct user involvement.
The concrete filtering process can be implemented via cryptographically signed policy lists that are validated via an internal public key infrastructure (PKI). Each connections' attributes are matched to these lists and marked accordingly. The daemon then transfers keys for non-sensitive connections to the NMS. Validation failure of the list integrity implicates unauthorized modification and could be used as an additional indicator of compromise (IoC). In this case, the daemon would fall back to forwarding all keys to the NMS to aid incident response. Overall, we recognize that selective decryption is (i) not feasible in all scenarios (especially high-security environments) and (ii) may impose additional challenges on security personnel. However, it enables organizations to support users in retaining some privacy which is not possible with MitM proxies. Moreover, we believe, that improved user privacy can outweigh the disadvantages in many scenarios or even enable the use of NMS in settings that have previously not been possible because of legal or compliance reasons, e. g., medical institutions. Finally, the lines between private and work activity are blurred and crossed. In such cases, users have legitimate reasons to conceal certain private connections from the organization's NMS which is enabled by our approach.

## 3.3 Transferring Keys to the NMS

After the filtering process is completed or skipped, the key material is forwarded to the NMS. The actual transmission method used is dependent on the NMS in question and conceptually trivial. However, the transport channel should be chosen carefully, as the key material is highly sensitive. Mutually authenticated TLS connections also based on the internal PKI between endpoints and NMS are a solid choice. The transmission should be direct without additional intermediaries to minimize the threat surface and prevent unauthorized decryption outside of the NMS. However, if the network policy requires it, keys could be also stored to a secured database to perform authorized offline decryption of dumped traffic at a later point in time.

## 3.4 Passive TLS Decryption at the NMS

Once the NMS receives TLS key material, it needs to identify the connection the key material belongs to. This identifier differs for TLS versions and different implementations of session resumption. To identify a connection that was established via a full TLS 1.2 handshake, the *client random* that is sent with the *ClientHello* is unique and thus can be used to match key material. For subsequent resumed connections, the NMS needs to associate the key material with the session identifier. This is either *session ID*, *session ticket* or *TLS 1.3 PSK* depending on TLS version and implementation. If the session identifier is then encountered in a later handshake, the NMS matches the key material as for full handshakes. In TLS 1.2 this process is trivial as both *session ID* and *session*
ticket are sent in cleartext. The TLS 1.3 PSK approach is slightly more complicated as the PSK is already encrypted when sent from the server in the first connection and additionally exchanged after the first use in the resumed connection. However, this does not pose a problem to our approach as the NMS can already decrypt the first connection with key material from the client and thus store the decrypted PSK.

Once the connection has been identified, the NMS uses the obtained secrets to decrypt TLS application data in the connection. This poses two major challenges: First, the *cipher diversity* across different versions of TLS forces the NMS to implement many decryption algorithms. This can be mitigated by reusing popular cryptographic libraries such as OpenSSL or NSS. An incremental approach with a subset of supported cipher suites is also possible starting with popular ciphers. Second, *missing key material* at arrival time of the first encrypted packet needs to be addressed. This can happen either because the endpoint withheld the key material due to selective decryption or because the key material is still in transit to the NMS. In the first case, the NMS should simply skip decryption, while the second case would require the NMS to buffer packets until the key material arrives. However, this might introduce a denial of service attack vector if the NMS needs to buffer too many packets for connections especially as the NMS cannot know in advance if key material will arrive at some point in the future. To solve this problem, a traffic buffer in front of the NMS should be deployed that delays only the encrypted traffic for a short time before it is forwarded to the NMS. We quantify the impact of the key transfer latency on the decryption and recommend a buffer size in our evaluation (c.f. Sect. 4.4).

# 4 Evaluation

In this section, we first discuss the computational complexity our approach induces and compare it with the commonly deployed MitM proxy setup. Next, we describe the features and limitations of our PoC that we implemented to evaluate our concept. Finally, we describe the results from two experiments in which we measured the *decryption overhead* and the impact of key transmission latency on the *decryption success rate*.

## 4.1 Computational Complexity

We compare the computational overhead of our approach with MitM proxies on a conceptual level. TLS adds non-negligible computation overhead to every connection and the proxy has to set up and maintain two TLS connections per endpoint connection. A decrypting NMS remains passive and thus does not directly initiate TLS connections. Instead, it only decrypts the encrypted payloads to gain access to cleartext data.
<table><caption>**Table 2.** Simplified computational complexity for typical TLS connections</caption><thead><tr><th>Approach</th><th>CV</th><th>KE</th><th>E<sub>sym</sub></th><th>D<sub>sym</sub></th></tr></thead><tbody><tr><td>TLS client</td><td>1</td><td>1</td><td>s</td><td>r</td></tr><tr><td>TLS server</td><td>0</td><td>1</td><td>r</td><td>s</td></tr><tr><td>Intercepting proxy</td><td>1</td><td>2</td><td>s + r</td><td>s + r</td></tr><tr><td>Decrypting &amp; passive NMS</td><td>0</td><td>0</td><td>-</td><td>s + r</td></tr></tbody></table>

Table 2 summarizes the simplified computational costs of establishing TLS connections for TLS client and server respectively, a MitM proxy, and a passive NMS. We assume the default behavior of HTTPS where the client authenticates the server only. The TLS client performs a *certificate validation* (CV) for the server certificate and a *key exchange* (KE) to establish session keys. The exact number of cryptographic operations here differs based on the cipher suite used, but usually involves CPU-intensive asymmetric cryptography. Once the key material is established, the client encrypts *s* bytes of its request via the symmetric cipher *E<sub>sym</sub>* that was agreed upon and sends them to the server. After a response is received, *r* number of bytes are decrypted. The TLS server performs a similar number of operations, but usually without certificate validation as clients rarely use certificates in HTTPS. The number of encrypted and decrypted bytes are swapped as request bytes from clients *s* have to be decrypted and response bytes *r* encrypted. However, the overall computation effort should be nearly identical as symmetric ciphers require the same amount of computation for encryption and decryption.

The MitM proxy acts as TLS server to the client and as the client for the TLS server and thus performs the combined computations of both endpoints. While the KE results in a predictable amount of computation, *s* and *r* vary in different scenarios. For small connections such as simple websites, the doubled amount of symmetric cryptography is less impactful, while large connections such as large file downloads require significant amounts of additional computation on the proxy. The decrypting NMS has one large conceptual advantage to the proxy: due to its passive analysis, it only needs to decrypt all bytes *s* + *r* of connection once to achieve cleartext access to the payloads. As no TLS connection is established, no KE needs to be performed and even validation of the server certificate is not required as the client would reject the connection in case of failure. However, analysis of the server certificate might be part of regular NMS tasks. Additionally, our approach offers some further potential performance gains compared to MitM as the NMS can decide to skip decryption on-demand if cleartext data is not needed. This is useful for common use-cases such as video-conferencing or streaming services which are notorious for their high bandwidth demands and thus comparatively high decryption cost. While a MitM proxy in theory could skip decryption of the connections, e. g., by detecting the domain and forwarding the *ClientHello* instead of terminating it, the NMS can simply discard the bytes it is only a passive part of the connection. This can help to
reduce $D_{sym}$ below the maximum of $s+r$. Furthermore, our approach offers yet again greater flexibility, as the NMS can adapt this decision based on the current threat level or other intelligence, e. g., by enabling decryption of all connections if a current attack is taking place or imminent threats are expected.

In summary, our approach conceptually requires less computational resources compared to TLS intercepting MitM proxies. While symmetric cryptography is continuously becoming faster to execute on modern hardware, it still represents the largest share of computation in a proxy and thus dictates how machine resources need to be reserved. Our approach requires significantly less computation and offers greater flexibility about which connections to decrypt while still enabling the NMS to perform analysis on cleartext payloads. However, the lowered computational load is shifted from proxy machines to NMS machines that have to be scaled up. Thus, in our first experiment, we aim to quantify this impact of added decryption on NMS performance to estimate the required changes for real-world deployments.

## 4.2 Implementation of Our Zeek Prototype

We implement our approach for passive and transparent TLS decryption as a proof-of-concept (PoC) prototype for the Zeek NMS [17]. While some features were intentionally left out to reduce complexity, our prototype is able to successfully decrypt TLS connections and perform analysis tasks on the cleartext application data payloads in real-world scenarios. Our prototype currently consists of a patched Zeek version based on v3.2.3 and a simple Python daemon that runs on endpoints and forwards key material. Both TLS key derivation and the actual decryption is performed by openSSL, as Zeek already links to this library. At the time of publishing our patch has been merged into Zeek mainline<fnref n="5" />.

**Obtaining TLS Keys on Endpoints:** For simplicity, we *obtain key material* via the SSL keylog interface as described in Sect. 3.1. We instrument Firefox to write TLS pre-master secrets and client randoms to a file monitored by our Python daemon which are then forwarded to Zeek. While we opted for Firefox, our setup it not limited to this browser, as all popular browsers can be configured to dump TLS pre-master secrets in the same format.

**Client-Side Filtering of Sensitive Connections:** The daemon currently does not perform any filtering and thus does not support *selective decryption*. Instead all client randoms and pre-master secrets are forwarded to Zeek independent of the domains involved. A complete implementation would need to match connections identifiers and secrets to domains as this information is not directly present in the SSL keylog file alone.

**Transferring Keys to the NMS:** The Python daemon maintains a connection to the Zeek instance via *broker*, Zeek's default communication library, and *transfers new secrets to Zeek* once they appear in the file.

<footnote n="5">⁵ see: https://github.com/zeek/zeek/pull/1814.</footnote>
**Passive TLS Decryption at the NMS:** Our patched Zeek version is able to receive both pre-master secrets or derived TLS session keys. In the first case, the TLS key derivation is performed once the first packet of the matching connection is encountered and the resulting session keys are cached for later use. Once session keys are available, Zeek *decrypts the TLS application data* and forwards the cleartext to its internal protocol detection engine and subsequent analyzers.

**Current Limitations:** Our prototype was explicitly built as a PoC. It is capable to passively decrypt real-world TLS traffic without actively intercepting the connection. However, it currently exhibits some limitations that prevent complete real-world deployments: (i) Our prototype only supports a single, but one of the most popular, cipher suite, namely TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. This cipher suite was chosen as it is commonly used in TLS 1.2 and exhibits several features of a modern cipher suite like perfect forward secrecy. Galois/Counter Mode (GCM) is favorably to our prototype as it was designed with parallel processing in mind and allows each block to be decrypted separately. Thus, our prototype is in worst-case also able to start the decryption in the middle of the connection if some initial packets could not be decrypted. (ii) Our prototype does not perform any *traffic buffering* and thus may encounter an encrypted packet before the respective keys are received. If this happens, it prints a debug message and skips decryption for this packet. This results in partial decryption of the overall connection. Usually, this means that the contained HTTP1/2 data cannot be fully parsed and analyzed. This limitation is however not directly tied to our implementation, as a real-world deployment likely would not buffer packets in the NMS itself anyway (as this opens up a potential DoS vector) but rather by a dedicated hardware or software appliance. The required size of this network buffer is an important question and we estimate it for small networks in second experiment in Sect. 4.4. (iii) Support for *TLS session resumption* is currently left out of scope to reduce complexity, but can be added by linking the respective connection identifier to the received key material. This is trivially possible as the NMS retains visibility into the complete payload.

## 4.3 Experiment I: Decryption Overhead

In this first experiment, we evaluate the central performance metric for our prototype implementation: *decryption overhead*, i. e., the additional runtime added by performing TLS decryption. This metric is important when deploying TLS decryption, as NMS resources need to be scaled up to accommodate for the additional computation requirements. There are two interesting scenarios to consider:

1. An organization is currently not deploying MitM proxies to terminate and decrypt TLS connections. Instead, a regular NMS is used to analyze encrypted traffic at the network boundary. Due to the encryption, the NMS is only able to analyze connection meta-data resulting in a comparatively low resource utilization.
2. The organization follows industry best-practices and deploys a MitM proxy that forward payloads from terminated TLS connection to an NMS. In this case, the NMS has full cleartext access to all connections and can perform a more sophisticated analysis, which results in higher resource utilization.

In both scenarios the NMS machines need to be scaled up, as more computation will be performed. However, in the second scenario, MitM proxies are no longer required and their previously allocated resources can be used for monitoring. To evaluate the decryption overhead for both scenarios, we design a capture environment that simulates both deployments.

<figure><img src="image_4.png" /><figcaption>Fig. 2. Setup to capture the data set to evaluate decryption overhead</figcaption></figure>

**Setup and Data Set.** Figure 2 shows the setup to capture the data set for this experiment. The client machine runs Firefox in headless mode that visits all Alexa top 1000 websites in order. The traffic is transparently routed through mitmproxy [5] to extract the TLS pre-master secrets and force the cipher suite that our prototype implements. The outgoing traffic from this machine is then routed differently based on the destination port. Web traffic destined for the ports 80/443 is forwarded to another host running PolarProxy [14], while all remaining non-HTTP/S traffic is routed directly to the Internet. We use PolarProxy as it can export decrypted HTTP/2 traffic directly to a pcap file, a feature that mitmproxy does not support. This pcap represents the commonly deployed second scenario described above in which the NMS receives decrypted traffic from a TLS intercepting proxy. The encrypted traffic and noise traffic is also captured and stored in different pcap files. These pcaps represent the aforementioned first scenario in which the NMS analyzes encrypted traffic only.

The resulting data set captured from our deployment comprises the TLS pre-master secrets extracted from mitmproxy and pcaps for encrypted web traffic, other noise traffic as well as the decrypted HTTP/2 payloads. All pcaps and the captures TLS pre-master secrets are freely available online [20]. Please note that this first experiment focuses on decryption performance and overhead alone. As such, we configure Zeek to load all TLS pre-master secrets from disk at the start of the experiment and let it analyze the respective scenario pcaps. This results in all keys being instantly available, which is not comparable to real-world deployments. To address this, we analyze the impact of real-time transmission of TLS keys and their delayed arrival at the NMS in the second experiment (c.f. Sect. 4.4).
**Results.** Figure 3a shows the decryption overhead by comparing the runtime of the unmodified Zeek version and our PoC for three different traffic profiles. Each traffic profile is defined in both *decrypted* and *encrypted* fashion as follows: (i) **https** contains only traffic that was originally sent via HTTPS. This includes most websites from Alexa top 1000 minus a few that did not support TLS at all. The *decrypted* variant is built from the *decrypted* **pcap** written by PolarProxy while the *encrypted* variants derives from the **pcap** captures between mitmproxy and PolarProxy. For HTTPS both pcaps are filtered by destination port 443. (ii) **web** consists of the same pcaps but removes the port filter and consists of all HTTP and HTTPS traffic. (iii) **all** extends the previous traffic profile by adding non-HTTP/S noise traffic and effectively contains all captured traffic.

The first two bars per traffic type show the runtime for the cleartext traffic for both the unmodified Zeek and our prototype. For all three traffic types, the runtime is nearly identical. This is expected as no decryption has to be performed and both version perform identical analysis tasks on cleartext data. These measurements thus resemble the NMS runtime in a typical MitM proxy deployment without including the runtime of the proxy itself. The third bar shows the runtime of the unmodified Zeek version analyzing encrypted traffic. The runtime is smaller than for the cleartext traffic, as this Zeek version cannot decrypt the payloads and thus falls back to metadata only analysis. This difference is most visible from the HTTPS only data set as no noise or HTTP data is present, which would be in cleartext and thus potentially triggering complex analysis scripts. This measurement also establishes a baseline for the first scenario described in the introduction of this section: an NMS processes encrypted network traffic and no MitM proxy is deployed. The fourth bar shows the runtime of our prototype that decrypts the TLS connections and analyzes the contained payloads. The added decryption results in a comparatively large runtime overhead as expected. Compared to the MitM baseline (cleartext traffic), we see an

<figure><img src="image_5.png" /><figcaption>**Fig. 3.** Experimental results</figcaption></figure>
increase by a factor of 2.5. An administrator should scale the resources of NMS machines by this factor when switching from a MitM proxy deployment to our approach. As MitM proxies are no longer needed in this scenario their resources could be repurposed. Compared to the first scenario (encrypted traffic), the overhead grows to about 3 times. However, this is reasonable, as no decryption was performed previously (neither by a MitM proxy nor the NMS). The previous comparison and our discussion in Sect. 4.1 show that deploying a MitM proxy would likely result in higher overall resource usage.

*Note:* While this experiment can be considered a micro-benchmark the results should give a good estimation of the expected decryption overhead in typical scenarios. The missing features, such as support for more ciphers, are not expected to negatively impact performance. Combined with the complexity discussion, we are confident that our approach reduces overall computation efforts compared to a MitM proxy deployment.

## 4.4 Experiment II: Key Transmission Latency

In the second experiment, we evaluate the real-world viability of our approach by examining the delay between the key material being made available on the client machine and the arrival at the NMS after transmission through the network. This is especially relevant, when considering cipher suites that require the cleartext of the previous packet for decryption a newly arriving packets. For these ciphers either the key material needs to be available once the first encrypted packet arrives, the NMS needs to buffer packets, or the network traffic needs to be delayed before being passed to the NMS.

<figure><img src="image_6.png" /><figcaption>**Fig. 4.** Setup to capture the data set to evaluate the impact of key transmission latency</figcaption></figure>

**Setup and Data Set.** We design a setup to capture timestamped TLS pre-master secrets as seen in Fig. 4. The client again runs Firefox in headless mode and is configured to only offer the prototype's supported cipher. It then browses Alexa top 1000 websites and write the SSL keylog file. Our python daemon also runs on the client machine and watches this file for changes. New pre-master secrets are immediately forwarded to Zeek via its Broker communication library. On arrival, Zeek timestamps the key material to document the arrival time and
stores the traffic as pcap. The resulting data set comprises the *traffic* `pcap` as well as the *timestamped TLS pre-master secrets* and is freely available online [20]. The timestamped TLS pre-master secrets are pre-loaded in our prototype that then analyzes the captured `pcap` file. However, the timestamp now dictates when *Zeek* starts to actually use the key. It only starts decryption once the network timestamp in the `pcap` is larger than the timestamp of the corresponding pre-master secret. This resembles a real-world deployment without any traffic buffering. For simulating this buffering, we use the `pcap` as is and simply add the desired delay time to the current network time in the comparison operation in *Zeek*. This enables us to quickly simulate multiple different deployments without altering the `pcap`.

**Results.** In this experiment, we count the number of TLS payload bytes that could be decrypted. As our supported cipher suite can start decryption from any packet in the connection, this can be anything between 0 (if the key arrives after the connection is already finished) or the full amount of payload bytes in the connection. We consider a connection *completely decryptable* if the key is available before the first encrypted payload packet is encountered. This is important for two reasons: (i) some cipher suites can only decrypt complete connections as part of the decrypted payload is used as IV for the next packet. (ii) especially for HTTP the first bytes of the connection are important for the NMS as they contain the client request. If they are missed, the NMS cannot analyze the protocol level. The *decryption success rate* is then calculated as the ratio of decrypted bytes/connections and total bytes/connections respectively.

Our results are shown in Fig. 3b. The x-axis shows the simulated traffic delay in ms and the y-axis the decryption success rate. In regular deployments without any delay only 1.3% of all connections are completely decryptable. This is expected as the key transfer latency prevents the first packets from being decrypted. However, 98.9% of all TLS payload bytes can already be decrypted. This indicates that only few of the first bytes are missed. This is further supported by the sharply increasing success rate in the first few ms. At 10ms traffic delay already 91.3% of all connections can be decrypted and the success rate steadily increases until at 40 ms effectively 100% of both bytes and connections can be decrypted. In summary, our results indicate, that only a small delay (in our setting 40 ms) is sufficient to achieve near-complete decryption. Depending on the utilization of the tapped network link, this results in a buffer size of up to 400M for a typical 10G uplink in a medium sized network. It is important to note that this small delay is only required before passing traffic to the NMS and thus does not impact other hosts in the network.

# 5 Conclusion

In this paper, we present an approach to passively decrypt TLS traffic on a trusted network monitoring system (NMS) that is based on client machines
selectively forwarding TLS key material to a trusted NMS to enable decryp-
tion without intercepting the TLS connection. This provides several advantages
compared to man-in-the-middle (MitM) proxies which are commonly deployed:
(i) No latency is added, as no additional communication partner is involved (ii)
Endpoints retain control about which connections can be decrypted by the NMS
(iii) End-to-end data integrity is preserved if non-AEAD ciphers are used, as the
NMS only receives encryption keys.

We implement our approach as a PoC for the Zeek NMS. While our imple-
mentation currently has some limitations, it shows promising results in both
decryption overhead and real-world applicability. Our evaluation indicates, that
TLS decryption increases the runtime by a 2.5 when compared to analyzing
cleartexts only. It is important to consider that our approach does not require a
MitM proxy to extract cleartext traffic. Our complexity analysis reveals that our
approach requires significantly less computational resources than MitM proxies.
Furthermore, we evaluate how the transfer of TLS key material impacts the
decryption. Our results indicate, that adding a marginal delay infront of the
NMS (in our setting as low as 40 ms) is enough to fully decrypt 99.99% of all
observed TLS connections. This is easily realized via existing hardware or soft-
ware appliances. Overall, we are confident that our approach and PoC are usable
for real-world analysis tasks which is reinforced by the accepted pull request to
Zeek mainline (See footnote 5).

References

1. Anderson, B., McGrew, D.: Identifying encrypted malware traffic with contextual flow data. In: Proceedings of the 2016 ACM Workshop on Artificial Intelligence and Security (2016). https://doi.org/10.1145/2996758.2996768

2. Antonello, R., et al.: Deep packet inspection tools and techniques in commodity platforms: challenges and Trends. J. Netw. Comput. Appl. (2012). https://doi.org/10.1016/j.jnca.2012.07.010

3. Badra, M.: Securing communications between multiple entities using a single TLS session. In: 2011 4th IFIP International Conference on New Technologies, Mobility and Security (2011). https://doi.org/10.1109/NTMS.2011.5721148

4. de Carné de Carnavalet, X., Mannan, M.: Killed by proxy: analyzing client-end TLS interception software. In: Proceedings 2016 Network and Distributed System Security Symposium (2016). https://doi.org/10.14722/ndss.2016.23374

5. Cortesi, A., Hils, M., Kriechbaumer, T.: Mitmproxy - an interactive HTTPS proxy (2022). https://mitmproxy.org. Accessed 31 Mar 2022

6. Durumeric, Z., et al.: The security impact of HTTPS interception. In: Proceedings 2017 Network and Distributed System Security Symposium (2017). https://doi.org/10.14722/ndss.2017.23456

7. ETSI Technical Committee Cyber Security (CYBER): ETSI TS103523-3 v1.1.1: Middlebox Security Protocol, Part3: Enterprise Transport Security (2018). Technical Specification

8. Haas, S., Sommer, R., Fischer, M.: Zeek-Osquery: host-Network Correlation for advanced monitoring and intrusion detection. In: ICT Systems Security and Privacy Protection (2020). https://doi.org/10.1007/978-3-030-58201-2_17
9. Jarmoc, J.: SSL/TLS interception proxies and transitive trust. In: Black Hat Europe 2012 (2012)

10. Lee, H., et al.: maTLS: how to Make TLS middlebox-aware? In: Proceedings 2019 Network and Distributed System Security Symposium (2019). https://doi.org/10.14722/ndss.2019.23547

11. MDN Contributors: Firefox Source Docs: NSS Key Log Format (2022). https://firefox-source-docs.mozilla.org/security/nss/legacy/key_log_format/index.html.
Accessed 31 Mar 2022

12. 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 (2017)

13. Naylor, D., et al.: Multi-context TLS (mcTLS): enabling secure in-network functionality in TLS. ACM SIGCOMM Comput. Commun. Rev. 45, 199–212 (2015). https://doi.org/10.1145/2829988.2787482

14. NETRESEC AB: PolarProxy TLS proxy (2022). https://www.netresec.com/?page=PolarProxy. Accessed 31 Mar 2022

15. O'Neill, M., Ruoti, S., Seamons, K., Zappala, D.: TLS proxies: friend or foe? In: Proceedings of the 2016 Internet Measurement Conference (2016). https://doi.org/10.1145/2987443.2987488

16. O'Neill, M., Ruoti, S., Seamons, K., Zappala, D.: TLS inspection: how often and who cares? IEEE Internet Comput. 21, 22–29 (2017). https://doi.org/10.1109/MIC.2017.58

17. Paxson, V.: Bro: A system for detecting network intruders in real-time. In: 7th USENIX Security Symposium (USENIX Security 99) (1999). https://doi.org/10.1016/S1389-1286(99)00112-7

18. Waked, L., Mannan, M., Youssef, A.: To intercept or not to intercept: analyzing TLS interception in network appliances. In: Proceedings of the 2018 on Asia Conference on Computer and Communications Security (2018). https://doi.org/10.1145/3196494.3196528

19. Watson, D.: KTLS: linux kernel transport layer security. In: Netdev 1.2 (2016). https://netdevconf.org/1.2/papers/ktls.pdf

20. Wilkens, F., Haas, S., Fischer, M.: Evaluation dataset: cooperative TLS-decryption via Zeek (2022). https://doi.org/10.25592/uhhfdm.10116