Validate VMess outbound security settings

[OfficialKatana]

Forbid insecure outbound settings.

[RPRX]

要判断一下，只针对公网 IP 段

[Fangliding]

vless都没ban vmess就别吧 这样只会更多人炸掉

[RPRX]

下个版本开始给三个月提示时间吧，这些东西之前不就伊朗在用吗现在估计也用不了了，除此之外也就 CF worker VLESS 有的会用

所以炸的范围也就和 allowInsecure 差不多吧，话说都没任何人汇报新旧版本 mKCP 不兼容，看来是真的没啥人用

[RPRX]

禁掉公网未加密出站还是有必要的，有些小白跟着 YouTuber 学了 CF worker VLESS 80，自己只知道能用都不知道全被 GFW 看光了

[OfficialKatana]

禁掉公网未加密出站还是有必要的，有些小白跟着 YouTuber 学了 CF worker VLESS 80，自己只知道能用都不知道全被 GFW 看光了

针对某水表机场的，某拼音M开头的“专线”机场采用的无内层加密、无TLS的VMess传输层并且采用水表在屋外的先进技术。
我的客户端这种情况会抛异常（第一次看见这种异常我还以为是配置读取错了，不敢想象2077年还有socks5同款危险传输方式），倒是可以给个等待迁移时间，大概一两个月以后合并。

[Fangliding]

禁掉公网未加密出站还是有必要的，有些小白跟着 YouTuber 学了 CF worker VLESS 80，自己只知道能用都不知道全被 GFW 看光了

那也是 vless 啊

[RPRX]

VLESS VMess SS Trojan 都上吧，Socks5 和 HTTP 就不管了，这俩地球人都知道是明文，无所谓明文的就换这俩吧

[OfficialKatana]

Trojan理论上不应该出现明文传输（实际上我也没见过Trojan明文，另外Trojan规定必须外层套TLS），ss无加密应该是退化成socks5了（还没见过没加密的ss），vless倒是可以搞

[RPRX]

人家 CF worker 搭个 VLESS+Trojan，客户端再用个 80 端口不就有明文了吗

[RPRX]

我觉得还是一视同仁吧，土制代理协议都用一样的策略就行，还有新加进来的 Hy2

[OfficialKatana]

根据 Trojan协议的定义，不应该出现没TLS出站的情况，也就是连接Trojan服务器必然是TLS连接（无论内网还是外网），VLess不一定（可能是内网无加密连接，也见过小白一键部署80端口服务端）
Hysteria2基于QUIC，QUIC必然使用TLS v1.3，所以不可能出现没TLS的情况（理论上和Trojan都可以跳过检测）

[LjhAUMEM]

hy 传输层限制需要 tls

Xray-core/transport/internet/hysteria/dialer.go

Line 380 in af2f048

return nil, errors.New("tls config is nil")

hy proxy 部分仍是明文，搭配其他传输层仍可能裸奔，不过得先等入站加进来

[OfficialKatana]

hy 传输层限制需要 tls

Xray-core/transport/internet/hysteria/dialer.go

Line 380 in af2f048

return nil, errors.New("tls config is nil")

hy proxy 部分仍是明文，搭配其他传输层仍可能裸奔，不过得先等入站加进来

啥时候弄出来让老王VPN爱好者、明文上网魔人体验一下？

[LjhAUMEM]

本来下一个就是，wg 入站不通让我突然想看看 wireguard-go，过几天吧

[j4Uq]

所以是真的要强推vless enc，即使已经tls 也要enc？

[KobeArthurScofield]

VMess 的话 zero 和 none 一样数据不加密的，只是头部保护，一样处理吧

[RPRX]

@OfficialKatana 看协议定义没用，任何东西只要进了 Xray-core，怎么组合就不是它说的算的了

@j4Uq 你这理解是咋成 contributor 的

[j4Uq]

趁你不在的时候偷渡的

[patterniha]

Trojan should theoretically not transmit in plaintext (in fact, I've never seen Trojan transmit in plaintext; also, Trojan requires an outer TLS layer), so unencrypted Shadowsocks (SS) has probably degenerated into SOCKS5 (I've never seen unencrypted SS), while Vless is possible.

trojan is the best protocol for passing data from Xray-core, to other-local/lan-custom-app, because:

1. there is no need to send extra response data (for example for vless we need to send extra "\x00\x00" first, or it's even worse for socks)
2. it doesn't use XUDP, so it is very simple to implement trojan-server in other languages like python,...

Except for MMDF (which later became fully supported by Xray-core, except for automatic-alpn-selection) i also wrote other apps and i plan to publish them soon.

Most of them are programs that change packet-ip/tcp-headers to bypass censorship, but Xray-core does not support sock-raw-outbounds, so i cannot implement them in xray-core.

Also socks5 and proxy-protocol have some limitations on udp:

• socks5 cons:
  1. you should implement, two inbounds in your custom-app, one for udp and one for tcp
  2. udp mangement is troublesome, you should implement udp-timeout,... again
• proxy-protocol cons:
  1. all socks5 cons
  2. does not support domain for address
  3. for udp, if first packet lost for any reason, you lose proxy-information

Although even with TLS being mandatory, i can use modified-Xray-core, and tell others to use that, but it's not easy to maintain and keep it up to date, and there's no need to do that at all.

Also, for android/ios users you need to create a new app !!!

so Xray-core-trojan should allow non-tls communication, to be able to communicate with other-local/lan-custom-app.

[RPRX]

我寻思 XUDP 的结构也不复杂啊，还支持 Global ID

[Fangliding]

It seems that the current plan is to allow 127.0.0.1 separately

[patterniha]

It seems that the current plan is to allow 127.0.0.1 separately

sock-raw-apps, does not run on non-root-android/ios, so the helper-app must be installed on pc/laptop, so all private IPs should be allowed.

[Fangliding]

It's just a simple statement, the actual logic is as follows, you just need to take a little look at the code of this PR

[gfw-killer]

VLESS has an optional perfect encryption, so 'VLESS should always with TLS' comment is wrong
or vless+encryption is officially named vlessenc protocol?

You forgot VMESS 'zero' encryption, it's like 'none'

User can add an encryption in other parts of configs, like VLESS+proxySettings/dialerProxy/finalMask
Does it still gives an Error?

There can be an environment variable to allow insecure outbounds, for any special scenario

[RememberOurPromise]

还没见过没加密的ss

有的，已经有youtuber做无加密SS的CF workers，但传输层wss
这毫无意义，建议直接禁