Socks5 Compatible with multiple authentication methods #14036
Conversation
| if (version != 1) { | ||
| throw new DecoderException("unsupported subnegotiation version: " + version + " (expected: 1)"); | ||
| } | ||
| Socks5AuthMethod authMethod = Socks5AuthMethod.valueOf(version); |
There was a problem hiding this comment.
version is not an auth mode tag
| @@ -75,7 +75,7 @@ private static void encodeAuthMethodResponse(Socks5InitialResponse msg, ByteBuf | |||
| } | |||
|
|
|||
| private static void encodePasswordAuthResponse(Socks5PasswordAuthResponse msg, ByteBuf out) { | |||
| out.writeByte(0x01); | |||
| out.writeByte(msg.authMethod().byteValue()); | |||
The SOCKS5 protocol does not specify messages format for other authentication methods, so it is an unpredictable variation. Removing the restriction of the authentication method being set to 1 allows for better scalability and reuse. We have a requirement that newly connected customer accounts and passwords need to be encrypted instead of using plaintext, but it also needs to be compatible with the plaintext of old customers. Therefore, there will be two different authentication methods, but the decoding and encoding behaviors are consistent. |
SOCKS5 encoder and decoder are both limited to only performing username password authentication. Such a design obviously violates the SRP. Whether authentication methods are supported should be handled by the application layer rather than the encoding layer. Besides, when we implement other authentication methods, we have to rewrite these decoders and encoders.