When early bytes become a request
02A proxy client can be trusted by its proxy server while forwarding bytes from an untrusted TCP application.
CONNECT receives 504. The vulnerable pre-mitigation server continues HTTP parsing and accepts the following POST under the client’s identity. The modern default must instead close without processing another request.
Source for this drawing: RFC 9931 · Read RFC section 4.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Keep the application’s bytes out of the proxy client’s authority.
- The published attack has three logical actors: an untrusted TCP application, a proxy client and a proxy server. Connection-level authentication can make the proxy client trusted by the server.
- An unsafe client sends CONNECT and forwards attacker-controlled bytes before knowing whether CONNECT succeeded. The example destination does not exist, so CONNECT fails.
- A vulnerable server then interprets the following bytes as another HTTP request under the trusted client’s identity. Continuing to parse this rejected CONNECT is contrary to the current §8 default mitigation.
This is a harmless fictional POST /demo illustration of the failure, not a live exploit or recommended forwarding policy. Parser bugs at a trusted/untrusted protocol boundary are a separate risk (§4.2). No real requests leave this drawing.
Read the RFC section ↗