<a href="https://github.com/coroot/coroot" target="_blank" rel="noopener nofollow">Coroot’s</a> open source node agent uses eBPF to capture network traffic at the kernel level. It hooks into syscalls like <code>read</code> and <code>write</code>, reads the first bytes of each payload, and detects the protocol: HTTP, MySQL, PostgreSQL, Redis, Kafka, and others. This works for any language and any framework without touching application code.
For encrypted traffic, we attach eBPF uprobes to TLS library functions like <code>SSLwrite</code>_ and _<code>SSLread</code> in OpenSSL, <code>crypto/tls in Go</code>, and <code>rustls</code> in Rust. The uprobes fire before encryption or after decryption, so we see the plaintext.
Java is different. And it has been a blind spot until now.
<h1>Why Java is special</h1>
Java’s TLS implementation (JSSE) is not a native shared library. It’s Java code that runs inside the JVM. There are no exported symbols like <code>SSL_write</code> that eBPF could attach to.
So when a Java app connects to MySQL or PostgreSQL over TLS, or makes HTTPS calls, eBPF tools cannot see the plaintext. All they see at the syscall level is encrypted data.
<h1>Our approach</h1>
We solved this by combining a lightweight Java agent with a tiny native library that serves as an eBPF uprobe target.
We dynamically load the agent into running JVMs using the attach API (the same mechanism profilers and debuggers use). The agent hooks <code>SSLSocketImpl$AppOutputStream.write</code> and <code>SSLSocketImpl$AppInputStream.read</code>, the internal JSSE classes where plaintext enters and leaves the TLS layer.
When the application does an SSL write, our hook copies the first 1KB of plaintext into a thread-local native buffer and calls a stub native function. We copy to native memory because the pointer is stored and read later when the underlying <code>write()</code> syscall fires.
By that time our JNI call has already returned, and Java’s GC could have moved the original byte array. We considered using <code>GetPrimitiveArrayCritical</code> to pin the array in place and avoid the copy, but it blocks all garbage collectors while held, which is worse for the application than a small memcpy.
For reads, we do the same after JSSE decrypts the data.
The native stub function does nothing at runtime:
<pre><code>int coroot_java_tls_write_enter(const char *buf, int len) {
 asm volatile(&quot;&quot; ::: &quot;memory&quot;);
 return len;
}
</code></pre>
The asm volatile barrier prevents the compiler from optimizing it away. We attach eBPF uprobes to this function, so every call is captured with the buffer pointer and the payload size. From there, the data goes into our existing protocol detection pipeline, and HTTP, MySQL, PostgreSQL, Redis, Kafka and other protocols are parsed automatically.
The file descriptor (which connection the data belongs to) is discovered without any Java reflection. When JSSE writes, the sequence is always: encrypt, then <code>write(fd, ciphertext)</code> syscall. Our eBPF code stores the plaintext pointer when the stub is called, then the syscall that follows on the same thread provides the file descriptor. This is the same <code>ssl_pending</code> mechanism we use for OpenSSL.
The native library is compiled with <code>-nostdlib</code>, so it has no dependencies and works in any container.
The nice thing about this design is that there is no transport between the JVM and the node agent. No unix sockets, no shared memory, no protocols to maintain. The Java agent just calls a native function, and eBPF picks up the data through uprobes and existing syscall tracepoints.
<h1>Safety</h1>
Our agent modifies the bytecode of two JVM internal classes to insert our hooks. That sounds scary, but all we add is a single method call before each SSL write and after each SSL read. The original code stays exactly the same. Every inserted call is wrapped in a try-catch that catches Throwable, so if our code fails for any reason, the error is silently ignored and the original SSL operation runs as if we were never there.
We use ASM for the bytecode transformation. ByteBuddy would make the code shorter, but the agent JAR would grow from 130KB to over 8MB. Since we deploy the JAR into every container with a running JVM, keeping it small matters.
<h1>Benchmark</h1>
We compared three scenarios on the same workload:
<ul>
<li>No instrumentation (baseline)</li>
<li>eBPF with our Java TLS agent</li>
<li>OpenTelemetry Java agent with traces exported to a collector</li>
</ul>
We included the OpenTelemetry comparison because it is the most common alternative for Java observability without code changes. The OTel agent auto-instruments HTTP clients, JDBC, and other libraries by rewriting bytecode at class load time.
The test uses two machines to avoid resource contention:
<ul>
<li>Machine 1 (8 vCPU): Java HTTP proxy making HTTPS calls + coroot-node-agent</li>
<li>**Machine 2 **(8 vCPU): Go HTTPS server (5ms delay, ~1KB response) + wrk2 load generator</li>
</ul>
Each scenario ran for 15 minutes at 1,000 requests per second.
<img src="https://media.daily.dev/image/upload/s--axFNFqti--/f_auto/v1774451725/ugc/content_23636181-64ed-4502-959a-d037fe16b135?_a=BAMAMiWQ0" alt="screenshot-1774291521279.png">
The baseline (no instrumentation) uses about 370m CPU cores. With our eBPF agent, CPU increases to about 426m, a 15% increase. The eBPF agent delivers the same throughput as the baseline.
<img src="https://media.daily.dev/image/upload/s--fl7m10Iu--/f_auto/v1774451771/ugc/content_56bd0c72-1328-4ae2-88b1-ec91b42471bc?_a=BAMAMiWQ0" alt="screenshot-1774290906072.png">
With the OpenTelemetry Java agent, CPU goes up to 511m, a 38% increase, and the application could only sustain about 800 of the 1,000 target requests per second, a 20% throughput drop.
<img src="https://media.daily.dev/image/upload/s--XRXU2BXW--/f_auto/v1774451795/ugc/content_af731c71-de14-432e-a127-719327d76d6e?_a=BAMAMiWQ0" alt="screenshot-1774290926267 (1).png">
<h1>Limitations</h1>
JVM compatibility. We support HotSpot-based JVMs: OpenJDK, Oracle JDK, Amazon Corretto, Azul Zulu, Eclipse Temurin. OpenJ9 and GraalVM native images are detected and skipped.
**SSLSocket only. **We instrument SSLSocket (blocking I/O), which covers JDBC drivers, HttpsURLConnection, and most traditional Java HTTP clients. SSLEngine (used by Netty and async HTTP clients) is not yet supported.
Dynamic agent loading. On Java 21+ the JVM prints a warning about dynamic agent loading being deprecated. JVMs with -XX:+DisableAttachMechanism or -XX:-EnableDynamicAgentLoading are detected and skipped.
<h1>Disabled by default</h1>
This feature must be explicitly enabled:
<pre><code>coroot-node-agent --enable-java-tls
</code></pre>
Or with an environment variable:
<pre><code>ENABLE_JAVA_TLS=true
</code></pre>
If you use the Coroot Operator on Kubernetes, add it to the Coroot CR:
<pre><code>apiVersion: coroot.com/v1
kind: Coroot
metadata:
 name: coroot
spec:
 nodeAgent:
 env:
 - name: ENABLE_JAVA_TLS
 value: &quot;true&quot;
</code></pre>
Loading an agent into a running JVM without the user asking for it is not something we want to do by default. The agent is safe, but we think this should be the user’s choice.
<h1>What you get</h1>
With this feature enabled, you can automatically detect and parse protocols inside encrypted Java connections: HTTP, MySQL, PostgreSQL, Redis, Kafka, and everything else we support. No code changes, no SDKs, no sidecars. Enable the flag and encrypted Java traffic becomes visible. You can try it open source to make your system more observable <a href="https://github.com/coroot/coroot" target="_blank" rel="noopener nofollow">here.</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

Coroot's open source node agent now supports decrypting and inspecting Java TLS traffic using a combination of a lightweight Java agent and eBPF uprobes. Since Java's TLS (JSSE) is pure Java code with no native symbols, standard eBPF uprobe attachment doesn't work. The solution dynamically loads a Java agent into running JVMs via the attach API, hooks into SSLSocketImpl internals to capture plaintext, copies it to a native buffer, and calls a stub native function that eBPF uprobes can attach to. The file descriptor is correlated via the subsequent syscall on the same thread. The agent is 130KB, has no stdlib dependencies, and wraps all hooks in try-catch for safety. Benchmarks show only a 15% CPU overhead compared to 38% for the OpenTelemetry Java agent, with no throughput degradation. Current limitations include SSLSocket-only support (no SSLEngine/Netty), HotSpot JVMs only, and a deprecation warning on Java 21+. The feature is opt-in via a flag.

Making encrypted Java traffic observable with eBPF