mirror of
https://github.com/ProxymanApp/Proxyman.git
synced 2026-04-27 00:55:57 +03:00
[GH-ISSUE #1669] Inconsistent results when SSL proxying is ON vs. OFF #1661
Labels
No labels
Discussion
Feature request
In Progress...
Plugins
Waiting response
Windows
Windows
bug
duplicate
enhancement
feature
good first issue
iOS
macOS 10.11
question
wontfix
✅ Done
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Proxyman#1661
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @seidnerj on GitHub (Jun 7, 2023).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1669
My scenario is as follows: I have a client, connecting to Proxyman locally at http://localhost:9090. Proxyman is set-up with an external socks proxy server.
There is an IP to which access is blocked if I try to connect to it from the external socks proxy server.
When the client uses the socks proxy server directly, requests to the aforementioned IP fail, as expected.
When the client uses http://localhost:9090 (i.e. Proxyman), and SSL proxying is OFF, requests to the aforementioned IP fail, again -as expected.
BUT, when the client uses http://localhost:9090 (i.e. Proxyman), and SSL proxying is ON, requests to the aforementioned SUCCEED. This implies that somehow, for some reason, at least some of the traffic going through Proxyman is not tunneled through the socks proxy server.
I've been wracking my brain over this for the past 10 hours, how is this possible?!
@NghiaTranUIT commented on GitHub (Jun 7, 2023):
Can you use whereismyip to verify your traffic doesn't go through your External Proxy in that the last scenario?
@seidnerj commented on GitHub (Jun 7, 2023):
That's just it, when I use curl to get my IP from a similar service (https://ifconfig.me) and go through Proxyman, with SSL proxying either ON or OFF, I get the same IP. I am unable to create a standalone example, but something is clearly different between those scenarios. Are any headers added by Proxyman or something of the sort? I'm trying to figure out what is different.
@seidnerj commented on GitHub (Jun 7, 2023):
I am able to reproduce this with a curl command (but I can't post it here since it contains private information). When SSL termination is ON, the server returns 200, but when it is OFF, the server returns 503 (as expected):
Here is a the console output from a simple script I created:
With SSL termination:
through socks proxy: <Response [503]>, ip address: ..10.189
through proxyman (with external socks proxy): <Response [200]>, ip address: ..10.189
no proxy: <Response [200]>, ip address: ..22.236
Without SSL termination:
through socks proxy: <Response [503]>, ip address: ..10.189
through proxyman (with external socks proxy): <Response [503]>, ip address: ..10.189
no proxy: <Response [200]>, ip address: ..22.236
@seidnerj commented on GitHub (Jun 7, 2023):
This bug (and the accompanying comments) could be related to this:
https://github.com/ProxymanApp/Proxyman/issues/1670
@seidnerj commented on GitHub (Jun 8, 2023):
Okay, I figured out what is the issue. It seems, for some very strange reason, when Python negotiates a TLS connection directly with the target server, it sometimes fails.
When SSL termination activated, Proxyman is the one doing the TLS negotiation and thus this problem does not happen.
This took a tremendous amount of work to figure out. If anybody else is reading this, the solution I found was to limit the maximum SSL version to TLS v1.2. Strangely, the target server doesn't support TLS v1.3 at all, but there's something in the negotiation phase, when falling back from 1.3 to 1.2 that screws up the connection when connecting directly from Python.