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
Would you consider adding SOCKS support, with a TCP listener, {rather than,as well as} tunnelling over websockets?
In a way, that actually simplifies the processing, because there is less encapsulation required. On accept on the named pipe, open a connection back to your own TCP listener, via the specified SOCKS server. Copy bytes received in either direction. Close the connection if either the named pipe or the TCP connection is closed. This could even be used to discriminate between concurrent connections to the named pipe, by using a random TCP port to listen on for each incoming named pipe connection. The port would then be specified in the SOCKS connection negotiation.
This would make it trivial to support tools such as Mallet (https://github.com/SensePost/Mallet), which can then be used to decode the protocol in use. (From the screenshots, I can see that even the Docker protocol has some binary encoding going on).
The text was updated successfully, but these errors were encountered:
Hi @RoganDawes ,
Thanks for your comment!
I will definitely look into it. In the beginning I thought of using HTTP POST requests, but I decided to go with WebSockets since they provide full-duplex. I didn't think about TCP through a SOCKS proxy, sounds like a good option.
You could also support HTTP CONNECT, I suspect that there is not much difference in the implementation effort. While Mallet doesn't have current support for CONNECT proxies, it would be pretty trivial to add it.
Would you consider adding SOCKS support, with a TCP listener, {rather than,as well as} tunnelling over websockets?
In a way, that actually simplifies the processing, because there is less encapsulation required. On accept on the named pipe, open a connection back to your own TCP listener, via the specified SOCKS server. Copy bytes received in either direction. Close the connection if either the named pipe or the TCP connection is closed. This could even be used to discriminate between concurrent connections to the named pipe, by using a random TCP port to listen on for each incoming named pipe connection. The port would then be specified in the SOCKS connection negotiation.
This would make it trivial to support tools such as Mallet (https://github.com/SensePost/Mallet), which can then be used to decode the protocol in use. (From the screenshots, I can see that even the Docker protocol has some binary encoding going on).
The text was updated successfully, but these errors were encountered: