Tracing TLS Traffic — eBPF style

Introduction

TLS traffic inspection — the holy grail of any troubleshooter deep in the network stack scratching his head in despair, or the chance for stealing confidential data and profiting in the black market for a more ill intended user.

Let me clarify before we move on. This article does not showcase or explain any way to intercept TLS traffic using man-in-the-middle setups. TLS was designed for end-to-end encryption so there is really no way to decrypt this information in a realistic time frame if the target is using up-to-date standards or without prior knowledge of the shared information.

However, if we have access to the hosts, or in this particular scenario, the linux kernel that is hosting the application, then the game changes completely.

In this small article, we will show how to intercept TLS communications in plain-text, without any awareness or extra instrumentation from the client-side application, or any TLS proxy that stands in between.

<Insert Dramatic Music>

eBPF — The Dark Knowledge

Let start with an introduction to the strategy we will be using for this interception.

eBPF — Extended Berkeley Packet Filter

eBPF is a technology that essentially allows the user to deploy custom code, sandboxed in order to avoid collateral damages, into the Linux Kernel itself. Thus, this allows the user to essentially enhance the capabilities of the Linux operating system, without the need for this particular piece of code to be merged into the main Linux distributions and wait a couple of years for its general availability.

Traditionally, BPF could only be attached to sockets, with most common scenarios being network packet traces. Over time, eBPF was extended to offer the capability of attaching to User-Space objects. Thus the ‘e’ in eBPF.

In the last few years, there has been an explosion of technologies leveraging this solution from general networking enhancements, load balancing solutions and security auditing, to…