Decrypting TLS
Kubeshark captures TLS traffic in clear text by hooking into the cryptographic libraries used by applications — without requiring access to private keys. Using eBPF, it intercepts data after decryption (on read) and before encryption (on write), capturing the plain text directly from memory.

Supported Libraries
| Library | Languages / Runtimes | Requirement |
|---|---|---|
| OpenSSL | Python, Java, PHP, Ruby, Node.js | Linked as shared library |
| Go crypto/tls | Go services | Non-stripped binaries |
| BoringSSL | gRPC, Chrome, Envoy | Linked as shared library |
If your application uses one of these libraries for TLS termination, Kubeshark can display the traffic in clear text.
How It Works
Kubeshark traces both kernel-space and user-space functions using eBPF (Extended Berkeley Packet Filter) — an in-kernel virtual machine that runs programs passed from user space.
OpenSSL
Kubeshark attaches uprobes to SSL_read and SSL_write, capturing unencrypted data in any TLS/SSL connection. Languages like Python, Java, PHP, Ruby, and Node.js use the OpenSSL library, so any service using TLS via OpenSSL is covered.
Go
Go has two ABIs (ABI0 and ABIInternal), and Kubeshark supports both amd64 and arm64. It probes crypto/tls.(*Conn).Read and crypto/tls.(*Conn).Write, similar to OpenSSL’s SSL_read and SSL_write. Additionally, it disassembles targeted Go binaries using Capstone to locate ret instruction offsets, as uretprobe does not work properly in Go due to its unique ABI. Goroutine IDs are tracked using offsets from the DWARF table.
Kernel
kprobes are used on certain kernel tracepoints for address resolution (learning IP and port for source and destination) and matching request-response pairs.
Performance
These methods have minimal performance impact due to the efficient eBPF in-kernel virtual machine. The Linux kernel limits the number of instructions allowed for probing, ensuring no significant slowdown or crash risk.