Xray-core allows connection without tls when vnext is used

[Ilya87]

V2rayN.txt
V2rayNG.txt

There are two configs of the same sudoku + password connection. When I use V2rayNG.txt config file I got
"infra/conf: vless without TLS or other encryption is prohibited unless the server address is a private IP or domain" and I can't establish connection, Xray-core can't start. when I use V2rayN.txt config file, the configuration works normal (of course, I have changed ip in config).

The first question is why sudoku connection with password is prohibited?
"Beneath the obfuscation layer, the protocol optionally employs AEAD to protect data integrity and confidentiality.

Algorithm Support: AES-128-GCM or ChaCha20-Poly1305.
PFS + Key Update: Session keys are derived per connection and rotated during long transfers.
Anti-Replay: Strict nonce de-duplication within a short TTL (plus timestamp skew checks) blocks window replays.

"
The second question is a different behavior, when vnext in configuration is used.

[Fangliding]

VNEXT只是兼容旧配置 不再考虑更新

[Ilya87]

@Fangliding so it is intended behaviour of Xray-core to bypass tls restriction, to use vnext?
And another question, is sudoku+password insecure in Xray-core?

[RPRX]

会修

And another question, is sudoku+password insecure in Xray-core?

目前 Finalmask 的东西都没有被认定为“可靠”，并且 Sudoku 作者给出的建议也是配合 VLESS Encryption

[patterniha]

Anyway you can easily bypass this restriction by using tunnel inbound (and pass it to freedom outbound), because this restriction does not apply to private IPs.

Even if the restriction is applied to private IPs, we can easily bypass it by using MitM.
///
This restriction makes it impossible to use the Cloudflare-worker without TLS (unless we use the tricks above). Often, GFW applies severe restrictions on TLS connections, but not on plain HTTP connections.

Also it is impossible to implement Vless-encryption in Cloudflare-workers due to the Cloudflare-workers-CPU-limitation.
///

So unlike removing "allowInsecure", i disagree with this restriction, because:

1. You can easily bypass this restriction with custom-config, and it only adds hassle to users.

2. Sometimes it is necessary to establish a non-TLS connection to Cloudflare-workers, because GFW imposes severe restrictions on TLS, also it is impossible to implement Vless-encryption in Cloudflare-workers.

@RPRX

[RPRX]

@patterniha 反正常规情况下（比如 GUI 客户端自动生成的配置）肯定不能让它连接公网未加密节点，以给小白最基础的安全兜底

至于你们那边明显是降级攻击蜜罐的“限制 TLS 却放行 non-TLS”，实在知道自己在干啥的人绕过限制了就绕过吧，毕竟你换个核心也能绕过

[xcfa]

Sorry, maybe I'm posting in the wrong thread, but it seemed close to my problem. Now, when I try to create an unsecured vless connection and specify a Unix socket, xray returns an error, asking me to set up security. Is this a bug, or is this intended?

[arinc9]

@patternihaIn any case, under normal circumstances (such as configurations automatically generated by the GUI client), it should definitely not be allowed to connect to unencrypted nodes on the public network, to provide beginners with the most basic security safeguards.

Why are we dumbing down this extremely powerful tool to cater to beginners? I have a product where it makes absolutely perfect sense to use unencrypted VLESS on the public network. Now I can't use it because we're worried some beginner is going to configure xray without proper understanding of the configuration? I am beyond baffled. Put the restrictions on the GUI client if you're so worried. Right now, my product is going to become broken due to this nonsense restriction.

As for your honeypot's obvious downgrade attack—"restricting TLS while allowing non-TLS"—those who know what they're doing can bypass the restrictions if they want. ~After all, you can bypass it by replacing the core. ~

That doesn't matter. I can't just ship a modified xray-core to the platforms I ship my product on.

@Meo597 @OfficialKatana @RPRX please revert the relevant part of #6303.