Qtap: Capturing Pre-Encrypted Network Traffic with eBPF

What Qtap Solves and Why Pre-Encryption Capture Matters

Most network debugging tools work at the packet level. When traffic is TLS-encrypted, packet capture shows ciphertext. To recover the plaintext, you need either the session keys (available through SSLKEYLOGFILE on cooperating processes) or a man-in-the-middle proxy that terminates TLS for you. Both approaches require application-level changes or infrastructure additions.

Qtap takes a different approach. It attaches to TLS/SSL library functions inside running processes using eBPF. Data is intercepted at the function call boundary, before the encryption step runs, and passed to a plugin system with the full context: process ID, container identity, user, host, and protocol information. The README states explicitly: "without modifying apps, installing proxies, or managing certs."

The primary use cases listed in the README are security auditing (verifying sensitive data is not unintentionally exposed), debugging API errors (seeing the actual request and response that caused a failure), API development (confirming correct formatting without code changes), legacy system investigation, and validation testing. These are all cases where the engineer needs access to the plaintext of a specific application's traffic and cannot or does not want to instrument the application directly.

How Qtap Intercepts Traffic at the TLS Layer

Qtap is written in C and Go. The eBPF probes attach to TLS/SSL functions in the Linux kernel's user space: when a process calls into a TLS library to encrypt outgoing data or decrypt incoming data, the probe fires before the operation completes. At that point the data is in its plaintext form, and Qtap copies it along with the available process and container context.

The data then flows to a plugin system. Plugins can augment existing observability pipelines, feed Grafana dashboards, or serve as the foundation for a custom solution. The repository includes a sample Grafana dashboard under `examples/dashboards/qtap-http-overview.json`.

Qtap's built-in DevTools interface, located in `pkg/devtools/app`, provides a browser-based interface similar to Chrome DevTools for monitoring HTTP transactions, network connections, and processes on a single Linux node. The README references dedicated DevTools documentation at docs.qpoint.io.

OpenTelemetry tracing is available by setting the `OTEL_TRACES_EXPORTER` and `OTEL_EXPORTER_OTLP_PROTOCOL` environment variables. Prometheus metrics are served on `localhost:10001` at `/metrics` (system activity dashboards) and `/system/metrics` (agent health).

Getting Started: Demo Mode, Installation, and Docker

The README offers a demo mode that runs a temporary instance and prints traffic in real time:

curl -s https://get.qpoint.io/demo | sudo sh

For a persistent installation:

curl -s https://get.qpoint.io/install | sudo sh

Once installed, start the agent:

sudo qtap

To run in Docker, Qtap requires `CAP_BPF`, `CAP_SYS_ADMIN`, host PIDs, and host networking. The README provides this example:

docker run \
    --user 0:0 \
    --privileged \
    --cap-add CAP_BPF \
    --cap-add CAP_SYS_ADMIN \
    --pid=host \
    --network=host \
    -v /sys:/sys \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -e TINI_SUBREAPER=1 \
    --ulimit=memlock=-1 \
    us-docker.pkg.dev/qpoint-edge/public/qtap:v0 \
    --log-level=info

The Docker container needs access to the host process namespace so the eBPF probes can attach to processes running outside the container.

Kernel and Permission Requirements

Qtap has hard constraints on the Linux environment. The README lists three requirements: Linux kernel 5.10 or newer, BPF Type Format (BTF) enabled, and elevated permissions.

BTF is required for CO-RE (Compile Once, Run Everywhere) eBPF programs. You can verify it is present by checking whether `/sys/kernel/btf/vmlinux` exists on your system. Without this file, Qtap will not load its eBPF probes.

On the host, the agent must run with `sudo`. Inside Docker, it needs `CAP_BPF` and `CAP_SYS_ADMIN` along with privileged mode and host PID access.

These requirements mean Qtap is not suitable for restricted environments such as managed Kubernetes clusters where privileged pods are disallowed, cloud sandboxes with limited kernel access, or systems running kernels before 5.10. The eBPF approach inherently requires root or equivalent privilege: there is no low-privilege mode.

For development, building from source requires Linux kernel 5.10+, Go 1.27.1 or later, make, and exactly clang version 14. The repository notes that macOS developers at Qpoint use Lima as a Linux VM. The build process compiles the eBPF binaries and then the Go application:

git clone https://github.com/qpoint-io/qtap.git

make build

Qtap vs Wireshark: Different Capture Points

Wireshark is the standard tool for network traffic analysis. It captures packets at the network interface level, which means it sees the encrypted ciphertext when TLS is in use. To decrypt those packets in Wireshark, you need either session keys exported through SSLKEYLOGFILE (which requires configuring the client application) or a separate decryption step.

Qtap captures at the TLS function call boundary inside the application process, not at the network interface. This means it sees plaintext by design and does not require session keys or proxy interception. The trade-off is scope: Wireshark captures all traffic from all processes and interfaces on a machine, while Qtap focuses on egress TLS traffic from processes it has attached to.

Wireshark also supports offline analysis of saved packet captures and runs on macOS and Windows. Qtap operates live on Linux only, processes data through a plugin pipeline rather than saving raw packets, and adds structured context (process, container, user) that Wireshark does not provide natively.

Go Module Embedding and Process Monitor

Go applications can embed Qtap's process discovery component without running the full agent. The `process.NewMonitor` function in `pkg/process` constructs a Linux process monitor, receives lifecycle callbacks for existing and new processes, and releases its resources when no longer needed. The README points to `examples/process-monitor` for usage, runtime requirements, and callback limitations.

This embedding capability is distinct from the main agent: it gives a Go application visibility into Linux process lifecycle events without capturing network traffic. The module is available at `github.com/qpoint-io/qtap` via the standard Go module system.

Project Status, Maintenance, and Licence

The README marks Qtap as "currently in early development." Specifically, it states that some APIs may change, documentation is incomplete in places, and there may be rough edges. The last push to the repository was on 2026-09-25, indicating active work. The project has no published GitHub releases.

Qtap is licensed under Apache-2.0, which permits commercial use. The open-source repository represents the agent component; the README notes that Qtap is also the foundation for Qpoint, a commercial product from qpoint.io.

Telemetry integration with OpenTelemetry is available for tracing, and the Prometheus metrics endpoints are suited for building dashboards. The example configurations under the `examples/` directory cover integration with Axiom, MinIO, Fluentbit, and HTTP access logs.

Editorial conclusion

Qtap is a practical fit for Linux engineers who need to inspect egress TLS traffic without modifying applications, installing proxies, or managing certificates. It requires Linux kernel 5.10+ with BTF enabled and elevated permissions, which limits it to environments where those constraints are acceptable. The project's own README marks it as early development, with APIs that may change. Before adopting it for a production observability pipeline, verify that your kernel has BTF enabled by checking for `/sys/kernel/btf/vmlinux`, and read the release notes closely since the API surface is not yet stable.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. qpoint-io/qtap on GitHub
5. README