pimterry
commented
1 month ago This probably depends on the implementation of your proxy really, I'm afraid, not these scripts.
This is a bit tricky to solve, because when the traffic is redirected to the proxy, the original TCP packet destination is lost (it's replaced with the proxy's address). To handle this, most proxies use the HTTP Host header that's inside the packet data to work out where to send the request, but that requires handling & parsing the HTTP request, and for HTTPS that means you have to decrypt TLS.
If you don't have decrypt the traffic, for redirected traffic, all the proxy receives is the contents of the client's TLS hello packet. That will probably (not always) include a server name indication (SNI) which tells you which domain name the client is trying to connect to.
SNI doesn't include the port though (you can guess 443, but that's a guess) and it's there's plenty of edge cases. In the specific output you showed, the target port is 8888 so 443 will definitely be wrong. Unless you build some other custom mechanism, there is no standard way that your proxy server will know that the traffic is supposed to go to port 8888 unless you decrypt HTTPS and read the headers, or you add some kind of rule there to send all traffic to that destination.
In practice, this is almost certainly not a problem with these scripts, so I'm going to close this issue. You'll need to work out how to configure your proxy to handle the challenges above, and/or set up full HTTPS interception instead.
closed