// the find
qpoint-io/qtap
Qtap: An eBPF agent that captures pre-encrypted network traffic, providing rich context about egress connections and their originating processes.
Qtap is an eBPF agent that hooks the TLS/SSL functions of OpenSSL, Go's crypto/tls, Node, and the JVM to read traffic before it's encrypted (and after it's decrypted), tagging it with the originating process/container/pod. It's aimed at platform and security engineers who want to see what's actually going over the wire without standing up a MITM proxy or injecting certs into every workload.
Capturing at the TLS library boundary via uprobes is a genuinely different approach from proxy-based tools like mitmproxy — no cert management, no app config changes, and it works even when the app pins certs. Being out-of-band (just attaching probes, not sitting in the data path) means it doesn't add latency, which matters if you're running this in production rather than just locally. Protocol decoding goes past raw bytes into HTTP, gRPC, Kafka, MySQL, and Redis, each with example apps in Go/Java/Node/Ruby for testing against, and there's a real e2e test suite, not just unit tests on isolated functions. The DevTools UI (Chrome DevTools-style network tab, screenshots in the README) gives you something usable immediately instead of a firehose of OTel spans you have to build dashboards for.
It needs CAP_SYS_ADMIN, CAP_BPF, host PID namespace, and host networking — for a tool that's marketed partly as a security auditing tool, that's a big attack surface to hand over, and the README doesn't say much about what happens to captured payloads (redaction, retention, where decrypted secrets end up) beyond piping them to OTel/eventstores. The README states outright it's 'early development' with APIs that may change and incomplete docs, so don't build hard dependencies on current config shapes yet. Linux-only with a kernel 5.10+ and BTF requirement cuts out anyone on older kernels or non-Linux hosts, including most managed container platforms that don't expose BTF by default. The JVM and Node hooking paths (bpf2go C shims, javassl, nodetls) are the kind of per-runtime reverse-engineering that tends to break silently on minor runtime version bumps, and there's no visible compatibility matrix for which exact OpenSSL/JVM/Node versions are tested.