Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Target of CONNECT Sends Data First, Data not seen by Client; Expected?

Jon | Last updated: Nov 01, 2016 02:41PM UTC

Four scenarios: 1) Client -> Target 2) Client -> Squid -> Target 3) Client -> Burp Proxy (CONNECT) -> Target 4) Client -> Burp -> Squid -> Target * The underlying communications between the client and target in not HTTP; it's some custom protocol * Burp 1.7, Java 6 :sad_face:, Windows 32-bit :sadder_face: Scenarios 1 and 2 work no issue. Scenario 2 plays out like this: Client sends a "CONNECT target:port HTTP/1.0", w/ a User-Agent header, to a Squid proxy. Upon receiving the CONNECT request, the Squid proxy responds with "HTTP/1.1 200 Connection established". Immediately, and unsolicited, the target server starts sending data through the Squid proxy to the client. The client is expecting the target to communicate first, reads the data off the wire, and all is good. However, scenarios 3 & 4 don't work. Focusing on Scenario 3, when manually testing with good ol' telnet and sending a CONNECT request directly to Burp, Burp responds with "HTTP/1.0 200 Connection established". All is good up to this point. However, I don't see the gratuitously sent packets from the server. Nor does the client when it's using Burp. Eventually the connection times out, the client throws an exception, and restarts the connection ad infinitum. Scenario 4 is like 3 except more tech involved. Is this expected behavior? RFC 2817 sections 5.2 states this: "data to be tunneled may be sent immediately after the blank line." It doesn't state the client needs to send it first. If this isn't expected behavior, then I'm at a loss :( Any suggestions on troubleshooting would be appreciated!

PortSwigger Agent | Last updated: Nov 01, 2016 02:50PM UTC

It sounds like the problem is that the "underlying communications between the client and target in not HTTP; it's some custom protocol". Burp acts as an intercepting man-in-the-middle HTTP/S proxy. When it responds to a CONNECT request, it then waits for the client to negotiate SSL and send an HTTP request. Try this out with a browser as the client and you will see everything working. Burp can't handle other protocols, which might involve the server sending arbitrary data following the CONNECT handshake.

Burp User | Last updated: Nov 01, 2016 05:05PM UTC