mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-19 04:15:01 +03:00
MHSanaei
b9e1d3afee
xray-core parses the inbound-level Shadowsocks-2022 key with ParseKey and refuses one of the wrong size while building the inbound, which keeps the whole core from starting, not only that inbound. Only client keys were checked, so an API caller posting a 32-byte key on aes-128 (or keeping a 16-byte key after switching to aes-256/chacha20) saved fine and took Xray down. AddInbound and UpdateInbound now reject such a key with a message that names the method and the size it needs. The check uses the core's own GetCipherMethod/ParseKey, so a raw non-base64 key the core accepts stays valid. Startup also replaces a stored wrong-size server key: that inbound never worked, so no client holds a working copy of it.
21 lines
668 B
Go
21 lines
668 B
Go
package xray
|
|
|
|
import "github.com/xtls/xray-core/proxy/shadowsocks_2022"
|
|
|
|
// Shadowsocks2022KeyBytes is the key size a Shadowsocks-2022 method takes, or 0
|
|
// for any other method, whose password is free-form.
|
|
func Shadowsocks2022KeyBytes(method string) int {
|
|
cipher, err := shadowsocks_2022.GetCipherMethod(method)
|
|
if err != nil {
|
|
return 0
|
|
}
|
|
return cipher.KeySaltLength
|
|
}
|
|
|
|
// ValidShadowsocks2022Key reads key the way the core does: base64, else the raw
|
|
// string, and either way exactly the method's key size.
|
|
func ValidShadowsocks2022Key(method, key string) bool {
|
|
_, err := shadowsocks_2022.ParseKey(key, Shadowsocks2022KeyBytes(method))
|
|
return err == nil
|
|
}
|