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
TGen is incorrectly handling a reply from a Socks5 server after sending the server a socks5 CONNECT request.
TGen always sends CONNECT commands, shown as the second byte (0x01) here and here:
The RFC states that the reply to a CONNECT should be handled like this:
In the reply to a CONNECT, BND.PORT contains the port number that the server assigned to connect to the target host, while BND.ADDR contains the associated IP address. The supplied BND.ADDR is often different from the IP address that the client uses to reach the SOCKS server, since such servers are often multi-homed. It is expected that the SOCKS server will use DST.ADDR and DST.PORT, and the client-side source address and port in evaluating the CONNECT.
However, TGen incorrectly interprets non-zero BND.ADDR and BND.PORT as a request from the server to reconnect to the server at that new BND ADDR:PORT. I believe this reconnection behavior is not part of the CONNECT command, but might be part of the BIND command (which TGen is not sending to the server). See the RFC linked above, under the BIND section.
The is a bug because TGen is incorrectly erroring out of connections to socks servers when the socks server reply contains non-zero BND ADDR and PORTs, here and here
I think the fix is that TGen should just ignore whatever the socks server sends back as the BND.ADDR and BND.PORT in the reply to the CONNECT request.
The text was updated successfully, but these errors were encountered:
TGen is incorrectly handling a reply from a Socks5 server after sending the server a socks5 CONNECT request.
TGen always sends CONNECT commands, shown as the second byte (0x01) here and here:
The RFC states that the reply to a CONNECT should be handled like this:
However, TGen incorrectly interprets non-zero BND.ADDR and BND.PORT as a request from the server to reconnect to the server at that new BND ADDR:PORT. I believe this reconnection behavior is not part of the CONNECT command, but might be part of the BIND command (which TGen is not sending to the server). See the RFC linked above, under the BIND section.
The is a bug because TGen is incorrectly erroring out of connections to socks servers when the socks server reply contains non-zero BND ADDR and PORTs, here and here
I think the fix is that TGen should just ignore whatever the socks server sends back as the BND.ADDR and BND.PORT in the reply to the CONNECT request.
The text was updated successfully, but these errors were encountered: