Cybersecurity / Networking

"Connection Reset" Testing API With Burp Proxy

A "connection reset" specifically while routing API requests through Burp usually means the TLS handshake between Burp and the target server is failing — either because of a TLS version mismatch, an SNI issue, or an upstream setting in Burp that doesn't match what the target API expects.

The Problem

Requests that work fine when sent directly (via curl or the browser without a proxy) fail specifically when routed through Burp:

curl: (56) Recv failure: Connection reset by peer

Or, within Burp itself, the request shows as failed with no response, and the Burp event log mentions an SSL/TLS-related error rather than a normal HTTP-level failure.

Why It Happens

Since Burp establishes a separate TLS connection to the actual server (as part of its man-in-the-middle interception), it needs to negotiate that connection correctly, independent of what your client would have done directly. Common causes:

  • The target server only supports newer TLS versions (like TLS 1.3) or requires specific cipher suites, and Burp's default upstream TLS settings don't match what's being offered or expected
  • The API requires SNI (Server Name Indication) to route the request correctly on a server hosting multiple domains, and Burp's outbound connection isn't sending it correctly for this specific target
  • The target server has strict client certificate requirements (mutual TLS) that Burp isn't configured to satisfy
  • A firewall or WAF in front of the target API is specifically blocking or resetting connections that don't match expected browser-like TLS fingerprints, which Burp's TLS implementation can sometimes differ from

The Fix

First, isolate whether the issue is Burp-specific by testing the same request directly without the proxy, to confirm the server itself is reachable and responding normally under regular conditions — if that works fine, the issue is specifically in how Burp negotiates its own connection.

Check Burp's TLS configuration under Project Options > TLS, and confirm the protocols and ciphers offered include what modern APIs commonly require. If older protocols are disabled by default in your Burp version, or if the target requires TLS 1.3 specifically, adjust the enabled protocol list to include it.

If the target API is hosted behind infrastructure that relies on SNI (very common with cloud providers and CDNs hosting many domains on shared IPs), confirm Burp is correctly forwarding the hostname during the TLS handshake — this is typically automatic, but worth confirming isn't disabled under advanced TLS settings if you've customized them previously.

If mutual TLS (client certificates) is required by the API, configure Burp with the appropriate client certificate under Project Options > TLS > Client TLS Certificates, associating it with the specific host so Burp presents it during the handshake rather than connecting without one.

As a diagnostic step, test the raw TLS handshake directly with OpenSSL, bypassing Burp entirely, to see exactly what the server offers and expects:

openssl s_client -connect api.example.com:443 -tls1_3

Comparing this output against Burp's configured protocol/cipher settings often reveals the specific mismatch causing the reset.

Still Not Working?

If the connection reset happens inconsistently — sometimes succeeding, sometimes failing — rather than failing every time, suspect a WAF or bot-detection system on the target's side that's specifically identifying and blocking Burp's TLS fingerprint or request patterns, rather than a straightforward configuration mismatch. In that case, adjusting Burp's TLS settings to more closely mimic a standard browser (matching cipher order and supported extensions) sometimes resolves it, though this crosses into more advanced Burp configuration that varies significantly by version.

It's also worth checking whether the target API is behind a CDN that terminates TLS at the edge and only forwards to the origin server over a separate connection — in these setups, the reset can originate from the CDN's edge layer rather than the actual application server, meaning no amount of adjusting the origin server's TLS configuration will help, since the failure happens one hop earlier than expected.

If you have access to network-level packet capture, running Wireshark alongside Burp while reproducing the issue can show exactly where in the handshake the reset occurs — whether it's during the initial ClientHello, right after the server's certificate is presented, or later during application data exchange. Each stage points to a different category of cause, and having the exact point of failure narrows the investigation considerably compared to only seeing the generic "connection reset" message from the application layer.

You might also like