Today we're releasing DevTools - a browser-based interface that gives you the Chrome Network tab experience for server-side HTTP/S traffic.

The problem: You're debugging a production issue. An external dependency is returning errors. Your logs say "request failed" but not what was actually sent. Adding debug logging means redeploying and restarting services - which takes time and often changes the conditions you're trying to debug. tcpdump shows encrypted blobs. Setting up mitmproxy means certificates, restarts, reconfiguration.

Our solution: install qtap, enable DevTools, open localhost:10001 in your browser. You're now watching live HTTP/S traffic - every request, response, header, body - in plaintext. No restarts, no certificates, no code changes.

It works by hooking into TLS libraries (OpenSSL, Go crypto, Java SSL, Node.js, etc) via eBPF before encryption happens.

Getting started:

    # Option A: Install script (inspect it first if you prefer)
    curl -s https://get.qpoint.io/install | less
    curl -s https://get.qpoint.io/install | sudo sh
    sudo qtap --enable-dev-tools

    # Option B: Direct binary download (use the link for your architecture)
    curl -L https://downloads.qpoint.io/qpoint/qtap-latest-linux-amd64.tgz -o qtap.tgz
    # curl -L https://downloads.qpoint.io/qpoint/qtap-latest-linux-arm64.tgz -o qtap.tgz
    tar -xzf qtap.tgz
    sudo ./qtap --enable-dev-tools

    # For remote servers, use SSH port forwarding or Tailscale/Twingate
    ssh -L 10001:localhost:10001 user@remote-server

DevTools is free and open source (AGPL-3.0).

GitHub: https://github.com/qpoint-io/qtap Docs: https://docs.qpoint.io/release-notes/devtools

Questions we'd love feedback on: - What debugging scenarios would you use this for? - Any protocols beyond HTTP you'd want? (Postgres, MySQL, Redis coming soon)

Comments URL: https://news.ycombinator.com/item?id=46707863

Points: 30

# Comments: 0

On an unrelated note, your work has inspired most of my career in Solaris/Illumos/Linux systems and honestly this project likely wouldn't have happened if it wasn't for all of your books/blogs/projects to help me along the way. Thank you!

The long answer is that the offsets are the byte alignment offsets for the go structs containing the pointers to the file descriptor and buffers. Fortunately we only have to calculate these for each version where the TLS structs within go actually change, so not even for every version. For instance, if a field is added, removed, or changes type then the location in memory where those pointers will be found changes. We can then calculate the actual offset at runtime where we know which architecture (amd64, arm64, etc) with a simple calculation. Within the eBPF probe, when the function is called, it uses pointer arithmetic to extract the location of the file descriptor and buffer directly.

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.

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.

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:

    Do you face similar challenges monitoring encrypted egress traffic?
    What are your thoughts on using eBPF for this compared to other methods?
    Any suggestions or potential use cases we haven't considered?

Comments URL: https://news.ycombinator.com/item?id=43928118

Points: 259

# Comments: 78

If you're reading this list of comparisons out of genuine interest, I would suggest also looking into Nanobox: https://nanobox.io

Comments URL: https://news.ycombinator.com/item?id=14419622

Points: 2

# Comments: 0