Show HN: Using eBPF to see through encryption without a proxy
17 comments
·May 8, 2025worldsavior
Isn't there already mechanisms for patching specific SSL libraries to view encrypted requests (e.g. frida)? What is the benefit of using eBPF?
compscidr
Have been following this project for a while, cool stuff!
I work a bunch with vpn-like networking on Android phones and it would be cool to have a bit of info on how I might get something like working on phones. I guess its probably not your typical usecase.
Currently since the project is a VPN client, I already intercept all of the packets, I have a pcap writer and can write to files or a tcp sockets and connect wireshark to it - but it needs a bunch of complication to setup the keys so that I can see through encryption, so anything that would make that process easier would be great.
bbkane
Does this work for Go binaries? My understanding is that Go programs do all the encryption "in the process" so the data is encrypted before eBPF can intercept it. I'd love to be wrong about that!
tylerflint
We have Go support, but it is not open sourced yet. Go is a bit more complicated but we were able to get it after some cave diving in the ELF formats. To give you a little insight on how this works, because Go is statically linked, we need to pull several different offsets of the functions we are going to hook into.
We do this by scanning every version of Go that is released to find offsets in the standard library that won't change. Then when we detect a new Go process, we use an ELF scanner to find some function offsets and hook into those with uprobes. Using both of these, we have all the information we need to see Go pre-encryption content as well as attribute it to connections and processes.
bbkane
Ok, that's exciting, and thanks for the insight!
lights0123
Most programs do encryption without syscalls! eBPF can intercept userspace execution, which they do as mentioned in the post:
> The key idea is to hook into common TLS libraries (like OpenSSL) before encryption and after decryption
bbkane
I saw that, but Go doesn't use dynamically linked libraries for encryption, so I don't think it helps in this particular case.
Retr0id
If I want to do something similar, do you know where the relevant parts of the eBPF docs are?
jonfriesen
Qtap scans binaries of processes as well known locations for OpenSSL on startup, then passes the offsets to eBPF where it hooks into the SSL_read and SSL_write to get the content before or after it's been encrypted.
This is the eBPF side: https://github.com/qpoint-io/qtap/blob/main/bpf/tap/openssl....
The Go side which indicates what we are scanning for is here: https://github.com/qpoint-io/qtap/blob/main/pkg/ebpf/tls/ope...
For more docs on the topic: - https://docs.ebpf.io/ is a must read - https://eunomia.dev/en/tutorials/30-sslsniff/ has a tutorial on cracking OpenSSL open and getting the content as well. The tutorials they have are fantastic in general
pclmulqdq
To hook into OpenSSL, don't you either need dynamic linking or userspace programs to compile your hooks in? Go and many Rust and C++ binaries tend to prefer static linking, so I wonder if this solution is workable there.
tylerflint
Great point! Yes it supports both scenarios. Qtap scans the binary ELF (curl, rust, etc) and looks for the TLS symbols. If they were statically compiled the eBPF probes will be attached directly to the binary, if dynamically linked the probes will be attached to the symbols in the library (.so).
nikolayasdf123
sounds like a security breach. how you ensure this does not become link in some next complex CVE?
mberning
My first thought was this is cool. My second thought was that this is going to be impossible to securely manage and administer.
adampk
How easy is the set up, does this need to be deeply integrated in each step of the life-cycle?
tylerflint
Just run the qtap agent on whatever Linux machine has apps running on it and it will see everything through the kernel vs eBPF.
You can customize config and/or integrate with existing observability pipelines, but initially you just need to turn it on for it to work. No app instrumentation required.
Hi HN, I'm Tyler Flint, one of the creators of qtap.
For a while now, my team and I at Qpoint.io have been grappling with the challenge of understanding what's actually happening inside the encrypted traffic leaving our production systems. Modern apps rely heavily on third-party APIs (think payment processors, data providers, etc.), but once TLS kicks in, figuring out exactly what data is being sent, identifying PII exposure, or debugging integration issues becomes incredibly difficult without resorting to complex and often brittle solutions.
Traditional approaches like forward proxies require terminating TLS (MITM), managing certificates, and often introduce performance bottlenecks or single points of failure. Network firewalls usually operate at L3/L4 and lack payload visibility. We felt there had to be a better way.
That's why we built qtap. It's a lightweight agent that uses eBPF to tap into network traffic at the kernel level. The key idea is to hook into common TLS libraries (like OpenSSL) before encryption and after decryption. This gives us deep visibility into the actual request/response payloads of HTTPS/TLS traffic without needing to terminate the connection or manage certs. Because it leverages eBPF, the performance impact is minimal compared to traditional methods.
With qtap, we can now see exactly which external services our apps are talking to, inspect the payloads for debugging or security auditing (e.g., spotting accidental PII leaks), monitor API performance/errors for third-party dependencies, and get a much clearer picture of our egress traffic patterns.
We've found this approach really powerful for improving reliability and security posture. We've packaged qtap as a Linux Binary, Docker container, and Helm chart for deployment.
This is still evolving, but we're excited about the potential of using eBPF for this kind of deep, yet non-intrusive, visibility.
We'd love to get the HN community's feedback:
Happy to answer any questions!