search

Snawoot / windscribe-proxy

Standalone client for proxies of Windscribe browser extension
MIT License
162 stars 19 forks source link

Session call failed: server gave HTTP response to HTTPS client #21

Closed talljosh closed 1 year ago

talljosh commented 1 year ago

After downloading the binaries for the first time, I'm trying to run winscribe-proxy.linux-amd64 -list-locations. I get the following output:

main.go:130: INFO     windscribe-proxy client version v1.3.0 is starting...
main.go:197: WARNING  Failed to load client state: open wndstate.json: no such file or directory. Performing cold init...
main.go:200: CRITICAL Cold init failed: Session call failed: Post "https://api.windscribe.com/Session?platform=chrome": http: server gave HTTP response to HTTPS client

When I use my browser go to the API URL mentioned in the error message it definitely gives me an HTTPS response not an HTTP one (though the JSON response is an error about missing client authentication values, presumably because I was using GET to view a POST API).

Running winscribe-proxy with -verbosity 10 didn't give me any additional debugging information.

Snawoot commented 1 year ago

Interesting... Please try to add option -fake-sni api.windscribe.com or try version 1.2.0. And tell me how it went.

talljosh commented 1 year ago

Running with -fake-sni api.windscribe.com works correctly for me, as does version 1.2.0 without the -fake-sni argument.

Snawoot commented 1 year ago

@talljosh That means your internet connection is behind some middlebox which doesn't let TLS sessions with fake SNI through. Apparently some corporate firewall or DPI doesn't like TLS session which has just com domain in ServerName extension field of TLS handshake.

talljosh commented 1 year ago

Ok. So should I expect things to work normally if I use the -fake-sni api.windscribe.com option?

At a quick test, in my network configuration HTTPS works through version 1.2 but doesn't work through 1.3 even with that flag.

Snawoot commented 1 year ago

So should I expect things to work normally if I use the -fake-sni api.windscribe.com option?

I guess so. Also you may experiment with values. Some other random domain (sometimes helps against censorship) or an empty string "".

At a quick test, in my network configuration HTTPS works through version 1.2 but doesn't work through 1.3 even with that flag.

Directly or through hola-proxy? Either way looks like a forced downgrade to inspect ClientHello and ServerHello messages.

talljosh commented 1 year ago

Sorry if I wasn't clear. When I run windscribe-proxy version 1.2 and try to do an HTTPS request through the proxy, it seems to work fine. When I run windscribe-proxy version 1.3 with -fake-sni api.windscribe.com and then try to do an HTTPS request through the proxy, I get this error in the windscribe-proxy logs:

handler.go:39: ERROR    Can't satisfy CONNECT request: x509: certificate is valid for *.windscribe.com, sni.cloudflaressl.com, windscribe.com, not uk-019.totallyacdn.com
Snawoot commented 1 year ago

Oh, okay. Seems like a regression. Thanks!

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.