-

[APT-ZERO]

No description provided.

[Fangliding]

The timeout mechanism of VMESS is designed to prevent replay attacks. As a stateless protocol, this is its only way to prevent replay attacks, which is different from the maxTimeDiff of reality.
Setting the timeout time to 1 hour according to your needs will result in serious performance issues.

[Fangliding]

The timeout mechanism of VMESS is designed to prevent replay attacks. As a stateless protocol, this is its only way to prevent replay attacks, which is different from the maxTimeDiff of reality.

I already know the things you mentioned but the thing you don't know is that using "VMESS noTLS without Timeout Mechanism" is better than "VLESS noTLS"

Setting the timeout time to 1 hour according to your needs will result in serious performance issues.

What is that "serious performance issues"? Is it Impossible to use VMESS without this Timeout Mechanism or by changing it's timeout value? @RPRX

This can be considered(should we?)

[RPRX]

为了覆盖更多应用场景，VLESS 即将有自带加密和 maxTimeDiff（后者上周就写好了），无需修改 VMess

[RPRX]

VLESS 的加密基本上就是 REALITY 的 session id，0-RTT，服务端私钥不泄露就无法解密，不像其它协议拿到客户端密码就能解密

[RPRX]

这个加密不是给你们过墙用的哈，过墙去用 REALITY 或 TLS，别用这个

这个加密就是你不想让 CDN 看到内容时，或者不让转发 TLS 但允许非 TLS 时，以及 VLESS+WS 等骚操作用的

可以手写识别，不是全随机数，可选 XTLS，内层 TLS 直接转发以最大化性能（若你的需求只是至少有个加密，就无需二次加密）

[RPRX]

To Idiocy Intolerant：不懂就问，在河南 REALITY 不开分片也连不上吗？好像没有这种反馈

[RPRX]

To zero X：VLESS 加密相较于其它协议的优点上面说过了，主要是在密码学上更安全，以及可选 XTLS 以最大化性能

[RPRX]

至于加密后的特征，就没有想过要掩盖，我直接告诉观察者这是 VLESS，而且不用加密或混淆 length，性能也会更好

[Cl-He-O]

VLESS 的加密基本上就是 REALITY 的 session id，0-RTT，服务端私钥不泄露就无法解密，不像其它协议拿到客户端密码就能解密

Is there forward secrecy?

[RPRX]

VLESS 的加密基本上就是 REALITY 的 session id，0-RTT，服务端私钥不泄露就无法解密，不像其它协议拿到客户端密码就能解密

Is there forward secrecy?

没有严格意义上的前向保密 但是强于其它协议

[mmmray]

@APT-ZERO I think this debate is completely unproductive. If you believe there is a value in doing so, you should test it and fork xray, deploy it and see about performance. Since there are only server-side changes, it should be very easy to deploy. It shortcuts a lot of discussions like this, and it doesn't put you in a position where you ask somebody else to spend time and prove your theories.

[Fangliding]

VLESS 的加密基本上就是 REALITY 的 session id，0-RTT，服务端私钥不泄露就无法解密，不像其它协议拿到客户端密码就能解密

真的有必要设计成公私钥吗
我觉得它的定义应该简单一点好 多这一点安全性（客户端公钥泄露不会泄露以往信息）意义不大的样子
如果直接用对称加密就写个密码就简单很多 甚至可以直接用现成的UUID 毕竟从用户角度少点字段也是好事 这样就只需要一个开关就行了
或者这样弄
“encryption”:"basic"(直接使用UUID对称加密)
“encryption”:"cv25519"(使用公钥加密)
甚至以后再多一个RTT进行ECDHE实现完整的前向安全都行(再造TLS轮子时间)
想了一下实现ECDHE甚至不需要客户端存公钥 直接用现有的UUID就行了 因为ECDHE过程是窃听安全的 保证握手数据不被窜改就行了（很明显UUID加密可以实现这一点）

[RPRX]

@Fangliding 目前设计目标是 0-RTT，不然无法取代现有的那些加密协议，主要是因为大多数人有 0-RTT 的就不想用 1-RTT 的

客户端是不可信的，配置很容易泄露，如果能拿来解密，很不好，客户端配置也就加个 x25519 公钥，跟 REALITY 差不多，不复杂

[RPRX]

频道消息的 m 就是中级的意思，对应的还有初级和高级，初级就是纯 PSK 加密（没必要，永远都不会出），高级就是完整 ECDHE

都是 0-RTT，肯定搞一个更安全的，没必要提供不够安全的选项，只要我不提供就没人会用，与 REALITY 的设计理念一脉相承

[PoneyClairDeLune]

I saw XTLS mentioned above along with XTLS encryption (nailed that! XD). Since XTLS Visiom only applies to non-multiplexed TCP connections, does this mean that XTLS Switch is coming soon?

[mmmray]

in fact, it seems that OP already raised the same exact proposal, and got the same exact answer: #3008