feat(sslsnoop): capture Go crypto/tls plaintext via uprobe

[dvrkn]

Capture Go crypto/tls request plaintext via uprobe

What & why

ebfw's HTTPS L7 visibility came from an SSL_write uprobe, which only hooks OpenSSL's dynamically-linked libssl. Go statically links crypto/tls and never calls SSL_write, so every native Go net/http client was invisible — no host, path, or headers. This PR closes that gap by attaching a second uprobe to Go's TLS write path, so we recover the same L7 detail before encryption, with no proxy and no TLS MITM.

How it works

• BPF (bpf/sslsnoop.bpf.c) — a new go_tls_write uprobe on crypto/tls.(Conn).Write, feeding the same ringbuf as ssl_write. Go uses the register-based ABIInternal (Go ≥ 1.17), not the C ABI, so BPF_UPROBE's PT_REGS_PARM read the wrong registers — go_arg() reads them by hand per arch (amd64 rax/rbx/rcx/rdi, arm64 user_pt_regs.regs[i]). For (*Conn).Write(b []byte) the args are (c, b.ptr, b.len, b.cap); the *Conn pointer becomes the per-connection key, so the existing HTTP/1.x + HTTP/2/HPACK tracker is reused unchanged. Entry-only probe (a uretprobe would corrupt Go's movable stacks).
• Userspace (internal/sslsnoop) — a second discovery loop scans every /proc//exe, checks the ELF symbol table for the Go TLS symbol, and attaches per unique inode. Dedup is by exe inode (not mount namespace — every process has a distinct executable); it skips the agent's own binary (ebfw links crypto/tls via client-go).
• New ebfw_go_uprobe_attached metric.

It's generic, not just the test fixture

Discovery is fully generic — any Go binary on the node that links crypto/tls is picked up. In testing, the agent captured the host's real tailscaled process alongside the fixture:

attached crypto/tls.(*Conn).Write uprobe via /proc/3196611/exe ...
HTTPS [pid=3196611 tailscaled] POST log.tailscale.com/c/tailnode.log.tailscale.io/107854...
Host: log.tailscale.com
Content-Length: 624
...

Limitations (documented)

• Non-stripped Go only — the symbol must be in .symtab; -ldflags "-s -w" removes it (no offset fallback yet).
• Go ≥ 1.17 (register ABI).
• Long-running processes — a one-shot process can exit before the ~1s discovery scan sees it.
• Still uncovered: Java, rustls, statically-linked OpenSSL.

Testing

• New test/e2e.sh case builds a native Go net/http client from a fixture (test/fixtures/gotls-client/ — its own module + Dockerfile, built in a container so no host Go toolchain is assumed), runs it on the host, and asserts ebfw recovers its host, path, and a custom header. Self-skips without Docker. The client waits just past one discovery interval so the probe attaches, then sends a single request — deterministic proof.
• Verified RESULT: ALL PASS on arm64 (kernel 6.17); the BPF object cross-compiles clean for both __TARGET_ARCH_x86 and __TARGET_ARCH_arm64, and CI exercises the amd64 register path.

Docs

README, ROADMAP, CLAUDE.md, and docs/{comparison,configuration,tests}.md updated to drop the "OpenSSL-only" claim and describe the two-uprobe model + its caveats.