eBPF collects telemetry directly from applications and infrastructure. One of the things it does is capture L7 traffic from TLS connections without any code changes, by hooking into TLS libraries and syscalls.
Works great for OpenSSL. Works for Go.
Then rustls enters the picture and everything stops being obvious. With OpenSSL, everything is nicely wrapped:
<pre><code>SSL_write(ssl, plaintext)
└─ write(fd, encrypted)

SSL_read(ssl, plaintext)
└─ read(fd, encrypted)
</code></pre>
From eBPF’s point of view this is perfect:
<ul>
<li>hook SSL_write, stash plaintext</li>
<li>write() fires immediately → same thread → you know the FD</li>
<li>same idea for reads</li>
</ul>
Everything happens inside one call. Correlation is trivial.
<h1>Rustls does things differently</h1>
Rustls doesn’t own the socket and never calls read or write itself. It works on buffers, and the application (or runtime) is responsible for actually moving bytes over the network.
The API reflects that separation pretty clearly:
<pre><code>// application writes plaintext into rustls
writer.write(plaintext);

// rustls produces encrypted bytes and writes them via io::Write
conn.write_tls(&amp;mut socket);

// application reads encrypted bytes and feeds them into rustls
conn.read_tls(&amp;mut socket);

// rustls decrypts and updates internal state
conn.process_new_packets();

// application reads decrypted data
reader.read(plaintext_buf);
</code></pre>
So instead of one call doing everything, you get a pipeline:
<ul>
<li>plaintext is buffered first</li>
<li>encryption happens later</li>
<li>syscalls happen outside of rustls</li>
<li>decryption happens before the app reads</li>
</ul>
The key difference for eBPF:
<ul>
<li>writes: syscall happens after plaintext</li>
<li>reads: syscall happens before plaintext</li>
</ul>
So the OpenSSL-style correlation only works in one direction.
<h1>Writes work as usual</h1>
On the write side, nothing fundamentally new is needed. You hook Writer::write, stash the plaintext, and correlate it with the following sendto. The ordering is preserved, so the same approach as OpenSSL still applies here.
<h1>Reads are inverted</h1>
The read path is where things really break.
<pre><code>recvfrom(fd, encrypted_buf, ...); // happens first

conn.read_tls(&amp;mut socket);
conn.process_new_packets();

reader.read(plaintext_buf); // plaintext appears here
</code></pre>
By the time we see plaintext, the syscall is already gone.
So the logic has to be reversed. Instead of:
<ul>
<li>“see plaintext → wait for syscall”</li>
</ul>
we do:
<ul>
<li>“see syscall → remember it → use it later”</li>
</ul>
Concretely:
<ul>
<li>on recvfrom → stash FD per thread</li>
<li>on reader.read → pick up that FD and attach it to plaintext</li>
</ul>
It’s basically reverse correlation. Not pretty, but it matches how rustls works.
<h1>When “ret=1” doesn’t mean 1 byte</h1>
This one took longer than expected. We reused the OpenSSL-style exit probe:
<code>ret = PTREGSRC(ctx)</code>
The probe fired, but results were weird:
<pre><code>ret=1
ret=0
</code></pre>
Which made no sense for a read. Turns out Rust returns Result &lt;usize&gt; like this:
<ul>
<li>rax → success or error flag</li>
<li>rdx → actual number of bytes</li>
</ul>
So we were reading rax and treating it as a size. Meaning:
<ul>
<li>ret=1 → actually an error</li>
<li>ret=0 → success, but size is somewhere else</li>
</ul>
Fix was straightforward once understood:
<pre><code>if (PT_REGS_RC(ctx) == 0) { // success
 size = ctx-&gt;dx; // actual byte count
}
</code></pre>
Classic case of “everything works, but the numbers are garbage”.
<h1>Finding rustls in binaries</h1>
Rust symbols are heavily mangled:
<code>ZN55$LT$rustls..conn..Writer$u20$as$u20$std..io..Write$GT$5write17h0ee1e61402b1a37cE</code>
It looks messy, but it encodes the full path: rustls::stream::Writer&lt;T&gt; implementing std::io::Write::write.
The tricky part is that mangling isn’t stable:
<ul>
<li>different compiler versions use different schemes (legacy vs v0)</li>
<li>optimizations and stripping can change what’s left in the binary</li>
</ul>
So matching exact names is fragile.
Instead, we:
<ul>
<li>check ELF .comment for rustc to detect that the binary was built with Rust</li>
<li>then scan symbols for patterns like “rustls”, “Writer”+”write”, “Reader”+”read”</li>
</ul>
Not perfect, but reliable enough in practice.
<h1>Results</h1>
Coroot is an open source observability tool that uses eBPF to simplify setup. Because we instrument rustls at the library level, not the frameworks, this works across most Rust clients that use rustls under the hood.
That includes HTTP stacks like hyper when paired with rustls (hyper-rustls, and frameworks like axum or warp when configured with rustls), database clients like sqlx when using its rustls TLS feature, and any async Rust service using tokio-rustls.
No code changes, no SDKs, no wrappers.
For Rust apps using OpenSSL via native-tls or openssl, the existing OpenSSL instrumentation already works. rustls was the missing piece.
Below is an example of a service talking to MySQL over TLS. Coroot shows the actual queries even though everything on the wire is encrypted.
<img src="https://media.daily.dev/image/fetch/s--FX_bAtBk--/f_auto,q_auto/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qsfb1kv57k5whu8iiv73.png?_a=BAMAMiiu0" alt="Image description">
If you’d like to give our open source tool a try and simplify your own observability, you can check it out at here on <a href="https://github.com/coroot/coroot" target="_blank" rel="noopener nofollow">Github.</a>

The squad for Kubernetes afficionados. 
All things Kubernetes: best practices, tools, tricks, new features, operator building. 
For experienced Kubernetes administrators and Kube-newbies alike.


KubeSquad

Instrumenting rustls with eBPF for L7 traffic capture is non-trivial because rustls separates TLS operations from socket I/O, unlike OpenSSL. On the write path, the OpenSSL-style correlation still works. On the read path, the order is inverted: the syscall fires before plaintext is available, requiring reverse correlation by stashing the file descriptor on recvfrom and attaching it later when reader.read fires. An additional gotcha is that Rust's Result<usize> return convention stores success/error in rax and byte count in rdx, not rax alone. Symbol detection is also tricky due to unstable Rust name mangling, requiring pattern-based scanning rather than exact name matching. These techniques are implemented in Coroot, an open source eBPF-based observability tool, enabling automatic TLS decryption for hyper, axum, sqlx, tokio-rustls, and other rustls-backed libraries with no code changes.

Instrumenting Rust TLS with eBPF