Capturing HTTPS on a Server: GoReplay vs mitmproxy vs Speedscale
To record requests arriving over HTTPS without changing every client, first identify where TLS ends. If your load balancer forwards plaintext HTTP to the application, GoReplay can copy that HTTP on a reachable interface. If the application receives encrypted traffic all the way to its process, raw packet capture alone cannot read the requests.
This guide compares documented capture approaches. It is not a hands-on performance benchmark of these products.
The short version
| Your setup or task | Candidate | What to verify |
|---|---|---|
| Plaintext HTTP behind your TLS terminator; capture and replay without an inline proxy | GoReplay | Interface access, capture permissions, upstream encryption and replay-target isolation |
| Inspect or modify traffic through a proxy you operate | mitmproxy | Proxy mode, routing and the certificate presented to clients |
| Capture supported encrypted workloads in Kubernetes using eBPF | Speedscale | Its current kernel, runtime and deployment requirements |
GoReplay does not terminate or decrypt TLS. A separate capture method is needed when no accessible plaintext HTTP leg exists. See the HTTPS setup guide.
GoReplay: capture behind TLS, then replay
A common layout is:
client --HTTPS--> TLS terminator --HTTP--> application :8080
|
GoReplay capture
|
isolated target
The HTTP leg must be visible from the capture host or network namespace. A load balancer that re-encrypts its upstream connection does not provide plaintext merely because it terminates the client’s TLS session.
The following is a source-reviewed setup example, not an executed capture test. Choose the interface, port and capture scope for your environment. The capture needs appropriate permissions; the replay target must be isolated from production side effects.
capture_dir=$(mktemp -d)
sudo gor --input-raw :8080 --http-allow-method GET \
--output-file "$capture_dir/requests.gor" --output-file-append --exit-after 30s
# Inspect and transform the captured data before replaying it.
gor --input-file "$capture_dir/requests.gor" \
--output-http http://staging.internal --exit-after 30s
The fresh directory and append option keep the capture and replay filename consistent. A time limit can interrupt capture or replay; check completeness. GET filtering is not sanitization and does not guarantee absence of side effects. Follow the capture, file and middleware documentation.
For an example with a narrower recorded result, use the synthetic file replay exercise. Its saved September 8 check observed two GETs with application-specific 200/422 responses and excluded a POST. It did not test packet capture, TLS or production performance.
mitmproxy: decrypt by becoming the TLS peer
mitmproxy’s certificate requirements depend on how it is deployed. In a client-interception setup, the client typically trusts mitmproxy’s CA. Reverse mode instead places the proxy in front of a server; a custom server certificate can be supplied. For a domain you control, a valid server certificate trusted by the clients avoids installing a new interception CA on each client. This does not remove the proxy from the request path.
Use this option when inspecting or modifying requests through a proxy fits the task. Check host-header handling, upstream TLS and application redirects as part of the setup. See proxy modes and custom server certificates.
Speedscale: Kubernetes capture as a product
Speedscale documents eBPF collection for supported TLS workloads without adding a proxy or distributing interception certificates. Its requirements still depend on the workload, runtime and host. Check eBPF collection for the current compatibility boundaries.
Its documentation also retains a sidecar TLS path for existing deployments and workloads that cannot use eBPF. That path has separate certificate and routing requirements. The sidecar TLS guide now marks sidecar capture deprecated for new Kubernetes installations. Avoid choosing an installation method from an older comparison alone.
Decision rule
- Locate the actual capture point and establish whether the bytes are HTTP or encrypted TLS.
- Choose copying plaintext, operating a TLS-aware proxy, or supported process-level capture according to that topology.
- Decide how to remove sensitive fields and isolate replayed writes, notifications and dependencies.
- Define the request sample and application checks that will make the replay useful.
If you already have a plaintext capture point, start with GoReplay capture. For continuous copies to a candidate, follow shadow testing. For a saved workload, use record and replay testing.