Httptap: View HTTP/HTTPS requests made by any Linux program

Original Article ↗ Hacker News Discussion ↗

Overview & Use Cases

  • Tool runs arbitrary Linux commands in an isolated network namespace and prints their HTTP/HTTPS requests and responses.
  • Very popular for “quick and dirty” debugging of app HTTP behavior (e.g., nginx configs, native app telemetry, cloud SDKs like Java/AWS).
  • Users like the DX: httptap <command> with process‑scoped capture and no global system changes.

How It Works (Network & TLS)

  • Uses a TUN device plus a userspace TCP/IP stack (gVisor netstack by default; there’s also a minimal homegrown stack).
  • DNS is handled by overlaying /etc/resolv.conf because network namespaces break access to the usual system resolver.
  • HTTPS decryption is done by generating a temporary CA and pointing the child process at it via env vars; the tool then MITMs TLS and sees plaintext HTTP.
  • This relies on the app honoring custom CA configuration and not doing certificate pinning; commenters note there’s no universal solution that handles all TLS libraries and malware‑like behaviors.

Comparison to Other Tools & Alternatives

  • Compared to Wireshark: much easier process scoping and automated TLS decryption; Wireshark struggles here.
  • Compared to mitmproxy: mitmproxy is richer (interactive modification, devtools UI) but usually needs proxy config or root/eBPF; httptap avoids both.
  • Some suggest eBPF/uprobes or patched TLS libraries to hook read/write or SSL_* calls; others point out complexity, need for root, and library‑specific code.
  • Related tools mentioned: Subtrace (seccomp‑based syscall interception), NetGuard (Android VPN), Podman+pasta+pcap.

Privileges & Environment Constraints

  • Core selling point: no root or capabilities required, only write access to /dev/net/tun (often allowed to normal users, but distro‑dependent).
  • Some debate whether managing namespaces is always unprivileged; in Kubernetes and locked‑down environments this may need policy changes.
  • SOCKS proxy support is requested but not present; tun2socks is cited as inspiration.

Security, Privacy & Certificate Trust Debate

  • Discussion on the risk of normalizing “install this custom CA” for non‑technical users, potentially enabling phishing or ISP abuse.
  • Counter‑argument: overprotective defaults already enable ad‑tech abuses; real safety comes from user understanding.
  • General consensus: trusting a local CA is powerful but tricky to explain safely.

Portability & Monastic Context

  • macOS lacks Linux network namespaces; Network Extension APIs might approximate the approach but would be harder.
  • The project’s origin in a Buddhist monastic tech community sparks side‑discussion about “cult” vs. monastery, futurist religion for AI, and alternative lifestyles, with mixed curiosity and skepticism.