Error with http:// prefix for --http-proxy parameters

[SadarSSI]

I am having a problem using wstunnel RUST compiled with a corporate proxy on Windows 10. My environment is as follows:

Operating system: Windows 10 SSH client: OpenSSH_for_Windows_9.1p1 OpenSSL: LibreSSL 3.6.1 wstunnel HASKEL version 6.0 Proxy: Squid with authentication

I have been using the wstunnel program for several years now as a client under Windows in Haskell version. I am trying to use the Rust compiled version.

For information, here is the command line that works in Haskell version:

ssh.exe myuser@192.168.3.19 -t -o proxycommand="wstunnel -L stdio:%h:%p wss://subdom.mydom.fr --httpProxy=ADDom\AdUser:AdUserPWD@Proxy:3129" -L 2222:192.168.3.128:3389

I have tried different things (with versions 8.5.4 and 8.5.2) , but I am still stuck without any information even with log-lvl DEBUG or TRACE.

Here is what I tried:

ssh.exe myuser@192.168.3.19 -t -o proxycommand="wstunnel.exe --log-lvl DEBUG client wss://subdom.mydom.fr --http-proxy ADDom\AdUser:AdUserPWD@Proxy:3129" -L 2222:192.168.3.128:3389

ssh.exe myuser@192.168.3.19 -t -o proxycommand="wstunnel.exe --log-lvl DEBUG client wss://subdom.mydom.fr --http-proxy http://Proxy:3129 --http-upgrade-credential 'ADDom\AdUser:AdUserPWD'" -L 2222:192.168.3.128:3389

I also tried without ssh with the same wstunnel commands without success.

I think the problem is that it is necessary to add "http://" as a prefix because if I transpose the same command with the syntax of the HASKEL version it does not work either.

ssh.exe myuser@192.168.3.19 -t -o proxycommand="wstunnel -L stdio:%h:%p wss://subdom.mydom.fr --httpProxy=http://ADDom\AdUser:AdUserPWD@Proxy:3129" -L 2222:192.168.3.128:3389

With this syntax wstunnel tries to connect directly to wss://subdom.mydom.fr without taking the proxy into account.

ssh.exe myuser@192.168.3.19 -t -o proxycommand="wstunnel -L stdio:%h:%p wss://subdom.mydom.fr --httpProxy=http://Proxy:3129 --upgradeCredentials='ADDom\AdUser:AdUserPWD'" -L 2222:192.168.3.128:3389

This command does not work either.

Of course, I tried to pass the command without putting the "http://" prefix, but in this case I have a syntax error with the message:

error: invalid value ''ADDom\AdUser:AdUserPWD@Proxy:3129'' for '--http-proxy <http://USER:PASS@HOST:PORT>': relative URL without a base

Can you help me with this issue?

Thanks

[erebe]

Would you mind trying with

client --http-proxy "http://ADDom%5cAdUser:AdUserPWD@Proxy:3129" wss://xxxx

I think the login must be url encoded due to the \. So replacing it by %5c should be good

[SadarSSI]

With the Windows cmd.exe shell, I have an error with ssh (percent_expand: unknown key %5) because the character “%” is considered as the first character of a Windows variable.

I took the precaution of putting the string of characters in single quotes like this:

ssh.exe myuser@192.168.3.19 -t -o proxycommand=“wstunnel.exe --log-lvl DEBUG client wss://subdom.mydom.fr --http-proxy ‘http://ADDom%5cAdUser:AdUserPWD@Proxy:3129’” -L 2222:192.168.3.128:3389

I did the same test with Powershell Core 7.4 with the same type of error: “vdollar_percent_expand: unknown key %5”

I seem to remember that we had this discussion a few years ago in the early versions of wstunnel (for windows) in order to be able to interpret Windows variables such as “%http-proxy%”. As a reminder, variables under Windows with cmd.exe are written in the form %xxx% and $xxxx in Powershell.

Moreover, during these last years, I noticed that I could not have an AD\Windows password composed with characters such as “%” or “$” because it caused errors when interpreting the character string by wstunnel HASKEL. I learned to live with it, because given the service that this program provides, it was not that serious! ;-))

Of course, I also tested without ssh such as

wstunnel.exe --log-lvl DEBUG client wss://subdom.mydom.fr "http://ADDom%5cAdUser:AdUserPWD@Proxy:3129"

But in this case, the program remains frozen without any display despite the request for DEBUG or TRACE.

So, do you think you could remove the control on the prefix “http://” in order to test with a HASKEL type syntax like: client --

http-proxy "ADDom/AdUser:AdUserPWD@Proxy:3129" wss://xxxx

vs

client --http-proxy "http://ADDom%5cAdUser:AdUserPWD@Proxy:3129" wss://xxxx

In any case, thank you for your time.

[erebe]

Would you mind trying this pre-release and let me know if it is ok https://github.com/erebe/wstunnel/releases/tag/v8.6.0 ?

You have 2 new cmd line option --http-proxy-login and --http-proxy-password , also --http-proxy does not require anymore http:// as prefix

client --http-proxy "Proxy:3129" --http-proxy-login 'ADDom/AdUser' --http-proxy-passwod 'AdUserPWD' wss://xxxx

[SadarSSI]

Indeed, I no longer have an error with the AD domain name "", but nothing happens. With the HASKEL version, in verbose mode, I can see the trace of the connection to the proxy, but here I see nothing and the program remains frozen.

HASKEL Trace DEBUG :: Opening tcp connection to proxy ProxySettings {host = “proxy”, port = 3129, credentials = Just (“ADDom\ADUser”,“Password”)} DEBUG :: Doing tls Handshake DEBUG :: Opening Websocket stream Last login: Mon Jan 8 17:12:43 2024 from 192.168.1.41

With version 8.6.0 I have no trace, as if the connection to the proxy was not being made and since I am not an administrator of my workstation, I cannot capture a frame. If the connection to the proxy was erroneous with the domain name, the user and the password, I would see it because my Windows account would be locked after several attempts (…)

I tried to put @IP of the proxy instead of the name, it didn’t work, but a proxy syntax with single quotes: --http-proxy ‘172.24.1.150:3129’ causes a RUST error like this (with “set RUST_BACKTRACE=full” in command line) thread 'main' panicked at src\main.rs:665:66: Invalid http proxy url: InvalidIpv4Address stack backtrace: 0: 0x7ff60ad672ba - 1: 0x7ff60ab65a6d - 2: 0x7ff60ad58f81 - 3: 0x7ff60ad68f5a - 4: 0x7ff60ad688a9 - 5: 0x7ff60ad69665 - 6: 0x7ff60ad69175 - 7: 0x7ff60ad690b9 - 8: 0x7ff60ad690a4 - 9: 0x7ff60add1087 - 10: 0x7ff60add1633 - 11: 0x7ff60ab0dd79 - 12: 0x7ff60aafb7af - 13: 0x7ff60a9e6126 - 14: 0x7ff60a9e9326 - 15: 0x7ff60adc807c - 16: 0x7ffd42bb7344 - BaseThreadInitThunk 17: 0x7ffd444226b1 - RtlUserThreadStart

Why the parameters --log-lvl DEBUG or --log-lvl TRACE doesn't work? TRACE says nothing more than this :

  2024-01-08T17:00:41.855857Z TRACE hickory_resolver::async_resolver: handle passed back

[erebe]

humm that's strange indeed. You should have something like

I need to try on Windows to check. Will come back to you

[SadarSSI]

I will try with your command line and putting my proxy settings and I will tell you what happens.

[erebe]

On windows, with this archive https://github.com/erebe/wstunnel/releases/download/v8.6.0/wstunnel_8.6.0_windows_amd64.tar.gz I have correctly the logs

P.s: Indeed for the single quote it create issue on windows, you need to use doble quote " to delimit args if you prefer you can use any of those format

--http-proxy "172.24.1.150:3129"
--http-proxy 172.24.1.150:3129
--http-proxy="172.24.1.150:3129"
--http-proxy=172.24.1.150:3129

[SadarSSI]

with your settings I have 2024-01-08T17:18:19.744711Z TRACE hickory_resolver::async_resolver: handle passed back 2024-01-08T17:18:19.744873Z INFO wstunnel::tcp: Starting TCP server listening cnx on 127.0.0.1:1212

and nothing else

ATTENTION

The syntax for the AD domain and user should be: "AD\UserAD" and not "AD/UserAD".

Sorry if I introduced any confusion or typing error in my previous messages.

[erebe]

Did you tried to make a connection on the listening server ? You need to start at least 1 connection to establish a connection with the proxy.

Or you can start the client with -c 1 to force open one at startup

[SadarSSI]

Something changed with version 8.6.0 via ssh, I now have the message:

Starting STDIO server

But I still don't see any exchange with the company proxy. For information it is an olfeo proxy (squid)

I changed the syntax of my ssh command by using --parameter=value like this

ssh.exe myuser@192.168.19.32 -o proxycommand="D:\tmp_download\wstunnel_8.6.0\wstunnel.exe client --log-lvl TRACE -L stdio://%h:%p --http-proxy=172.24.1.149:3129 --http-proxy-login=ADDom\UserAD --http-proxy-password=password wss://subdom.mysite.fr" -L 2222:LocalC:3389

The same command with the HASKELL version: Makes a connection to the Linux server by opening an ssh session and allows me to make an ssh tunnel to -L 2222:LocalC:3389

A stupid question: for the moment wstunnel on the server side is in HASKELL. I don't know the version because wstunnel --version doesn't answer the version but:

$ ./wstunnel --version
Use the websockets protocol to tunnel {TCP,UDP} traffic
wsTunnelClient <---> wsTunnelServer <---> RemoteHost
Use secure connection (wss://) to bypass proxies

This must be version 6.x installed on a debian linux server

I did a test with version 8.5.x RUST on a debian ARM linux server and the HASKELL client and it works perfectly

I will try to do a test with the RUST client and the server in RUST version to see if that changes anything

[erebe]

yes, you need to have the server and the client at the same version. using the rust client and the haskell server is not going to work.

[SadarSSI]

"Ok, I must very sincerely apologize because what doesn’t work is: a RUST compiled client with a HASKELL server version a HASKELL client with a RUST server version

So, we need to have a client and a server in either RUST or HASKELL but not any RUST/HASKELL or HASKELL/RUST mix.

I don’t know if it’s specified in the README, but if it’s not the case, a warning would probably be useful (…)

Thank you for your help and responsiveness in modifying the settings related to the separation of information regarding the proxy user and password. I will retest the presence of characters such as “%” and “$” in the password to see if this version fixes it."

Thank you again for the excellent work you do with wstunnel, which allows us to work with output restrictions such as only https, proxy, user, password…

I have been using this program for a few years now and I am very happy with it

[erebe]

It's written in the Readme already https://github.com/erebe/wstunnel#note-, but I agree that it is a bit dense now :sweat_smile:

let me know if you see it is ok, (or not)

[SadarSSI]

"You are right, it says: ‘v7.0.0 is a complete rewrite of wstunnel in Rust and is not compatible with previous version.’

When I read this, I misunderstood that Rust and Haskell were incompatible with each other. I've understood that Haskell version 6 was incompatible with Haskell version 7 and later versions (…) and Rust version 6 was incompatible with Rust version 7 and later versions.

I think specifying that the mix between Haskell and Rust is incompatible would remove all ambiguities.

Finally, now that it works ;-))

I regret not having the visibility (the verbose mode of the Haskell client) of the negotiation exchanges between wstunnel and the proxy. In my experience, this part is not always easy to debug because, depending on the companies, the authentication methods vary: .pac files that need to be read to know the names of the proxies, password authentication, others (most often) use Windows access token/session ID (ntlm authentication), etc…

If you could restore this possibility in a future version, it would be great because it is very useful when debugging.

[erebe]

Alright, I will try to add more log on this part :+1:

[erebe]

I release https://github.com/erebe/wstunnel/releases/tag/v9.0.0 with more logs for the http-proxy