You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is --http-upgrade-path-prefix (or even --http-upgrade-credentials, although I don't really understand how to use it) to check whether a client is allowed to connect to WSTunnel. This is good to avoid unexpected client connecting to the tunnel, and maybe having access to the LAN of the server. Something that could be good is that if a client tries to connect, and fails to authenticate, its request is automatically proxied to an HTTP server.
Describe the reason for such feature
Some firewalls uses aggressive filtering and checks if the server the client is connecting to is what is pretends to be - in our case, an HTTP and WebSocket server. Furthermore, this would prevents curious or malevolent persons to find out that there is a WSTunnel running. This is currently a feature of most Trojan implementations, and since WSTunnel is as awesome as Trojan (and it is actively developed :) ) it would be good to have it support this feature as well.
Describe alternatives you've considered
I'm pretty sure this could be done with a proxy like nginx, but I didn't tried yet. Be that as it may, some users use WSTunnel as it, without a proxy, so implementing this feature would allow them to have another security mechanism without having to install a configure a proxy :).
I can eventually help to implement this, but since I'm not a very good developer, especially when it comes to low-level languages like Rust, the code I'll produce will very probably be either inefficient or insecure
The text was updated successfully, but these errors were encountered:
I am not sure to understand the benefit of acting like an HTTP proxy. Usually, you are not allowed to run a random HTTP proxy on a network you don't own. So what would be the benefit beside being directly being flagged as malicious activity ?
Maybe I am missing something ?
For now, wstunnel server try to return the least information possible in case of an invalid tunnel request, especially to avoid being easily probed and flagged.
The current problem is that anyone checking the activity of a user would see that the user is connecting for a long time to and using WebSocket on a server with... nothing. Looks suspicious, doesn't it?
What I propose is that if WSTunnel receive an incorrect request, it passes the request to an HTTP server which could host some random WebSocket application, so WSTunnel is almost invisible. Of course, this wouldn't be mandatory, only defined by the user with something like --invalid-request-http-server.
Ha, I understand better thank you, it makes sense indeed to disguise as a random webpage.
I put it in my backlog for when I will have time to work on it ;P
Describe the feature
Currently, there is
--http-upgrade-path-prefix
(or even--http-upgrade-credentials
, although I don't really understand how to use it) to check whether a client is allowed to connect to WSTunnel. This is good to avoid unexpected client connecting to the tunnel, and maybe having access to the LAN of the server. Something that could be good is that if a client tries to connect, and fails to authenticate, its request is automatically proxied to an HTTP server.Describe the reason for such feature
Some firewalls uses aggressive filtering and checks if the server the client is connecting to is what is pretends to be - in our case, an HTTP and WebSocket server. Furthermore, this would prevents curious or malevolent persons to find out that there is a WSTunnel running. This is currently a feature of most Trojan implementations, and since WSTunnel is as awesome as Trojan (and it is actively developed :) ) it would be good to have it support this feature as well.
Describe alternatives you've considered
I'm pretty sure this could be done with a proxy like nginx, but I didn't tried yet. Be that as it may, some users use WSTunnel as it, without a proxy, so implementing this feature would allow them to have another security mechanism without having to install a configure a proxy :).
I can eventually help to implement this, but since I'm not a very good developer, especially when it comes to low-level languages like Rust, the code I'll produce will very probably be either inefficient or insecure
The text was updated successfully, but these errors were encountered: