RPRX
1. VLESS 仍在不断变化，务必确保两边的 v2ray-core 均为最新版本（很多问题最后发现是没有升级版本）。 2. 这里不是客服区，也没有客服。问题需要有建设性，或者你认为是 BUG 等，而不是不会配置/不会使用。 3. 最终提出问题前，你应当先仔细地读完 VLESS 的文档：https://www.v2fly.org/config/protocols/vless.html 4. 你应当先广泛地搜索类似的问题，提出问题时应当详细地描述场景，并一次性附上所有相关配置及日志。
我注意到有这么一段常量与描述： https://github.com/apernet/OpenGFW/blob/bc2e21e35dcc747bbc80fdebf5dae6215a0c5206/analyzer/tcp/trojan.go#L14-L27 1. `trojanUpUB` 在 Trojan-killer 中目前是 [750](https://github.com/XTLS/Trojan-killer/blob/02c3683d1e1dba7a4f91462c7831f5caec0e15fc/main.go#L72)，而在 OpenGFW 中是 1000，应该会增加误报率，这是为了匹配内层 ECH 吗 2. OpenGFW 是否只是针对单条连接检测并阻断 Trojan？Trojan-killer 只是一个证明 TLS in TLS 问题存在的 PoC，若从封锁的角度来说，我觉得应该持续监测同一目标（IP+端口+域名）的 M 条连接，若阳性率大于 N 就封锁该目标（用户可自定义），这样可以有效提升精准度 ~~题外话：当初我还和 @yuhan6665 讨论要不要把...
警惕 SNI 白名单地区隐蔽的大规模“降级攻击” / Watch out for hidden mass "downgrade attacks" in SNI whitelisted areas
原文：https://t.me/projectXtls/91 ## 警惕 SNI 白名单地区隐蔽的大规模“降级攻击” 根据长期的观察，以及多位身处 SNI 白名单地区的群友的反馈，这些地区的 IPv4 TCP 并不封锁 SS、VMess 这类全随机数裸协议，与其它地区的封锁策略形成了鲜明的反差，是一种非常反常的现象。 我们已知对于封锁翻墙流量，SNI 白名单是一种附带伤害极高的方式，我们也知道，其它地区的 GFW 正在轻易识别并封锁全随机数裸协议。那么请大家思考：**为什么某些地区并不在乎附带伤害，对 TLS 采用 SNI 白名单这样的强过滤策略，却“完全不管”全随机数裸协议？** **只有一种可能：故意留的口子，除此之外没有任何其它合理解释。** 我们已知相较于 TLS，全随机数裸协议相当于是把翻墙写在了脸上，更便于识别、掌握情况。且它们普遍缺乏 TLS 的“前向安全”等高级安全特性，非常原始，通过某种方式拿到密码就可以解密以前、以后的所有流量，非常利于监控。**所以我认为，这种 SNI 白名单+不封锁全随机数裸协议的组合策略，实质上是在迫使人们从较为安全的 TLS 协议迁移到不够安全的全随机数裸协议，是一场隐蔽的大规模“降级攻击”。**...
https://github.com/2dust/v2rayNG/issues/1027 高效实现，十分感谢 @yuhan6665 协助测试
这个问题是昨天发现的，本来我只是想先给 [**Xray-core**](https://github.com/XTLS/Xray-core) 的 Shadowsocks 明文结构加个时间戳以彻底解决对服务端的重放问题。 顺便研究了一下 SS AEAD 的安全性，我脑洞比较大，考虑得比较多，比如是否可以造成 **对客户端的攻击**，简述如下： 1. **对于 TCP，Shadowsocks AEAD 往返是完全一样的加密结构，HKDF 的 `info` 也相同，且响应的加密完全独立于请求** 2. **对于 UDP，同样存在上面的问题（甚至可以与 TCP 杂交），更糟糕的是，UDP 往返连明文结构都是完全一样的** 以上“特性”的利用方式太多了，真的很难排列组合完，还是主要说对客户端的攻击： **在不需要密码的情况下，可以随意对客户端接收的数据进行移花接木或重放等操作，使得被代理程序收到的数据没有任何可靠性。** **比如将 A、B 两条 TCP...
For the record, I have designed the **VLESS** and **XTLS** protocols, and I started the [**Xray-core**](https://github.com/XTLS/Xray-core) project a month or so ago. So those involved in the discussion should have...
由于 https://github.com/shadowsocks/shadowsocks-org/issues/183 ，我在研究“对服务端与客户端的逐字节重放”，并且取得了一些成果，此时又开了一下脑洞： ~~如果布隆过滤器被人恶意打满呢？不过可操作性不强，还有太多未知变量。~~ 接着就想到了如题：众所周知，某中间人一直在对未知流量进行重放，导致现在大多数实现都有防重放机制。 --- **而利用服务端的防重放，中间人不需要破坏连接，只需提前发送未知流量的前 32 个字节（或更多），即可使这些代理实质性失效。** **不需要封锁任何 IP 或端口，精准阻断未知流量类代理。** 某种程度上还是无解的，允许重放又会存在问题。 这个机制简单可行，好消息是，它尚未被部署，坏消息是，一旦部署会很棘手。
Shadowsocks 现有的设计存在一个非常明显的问题：**无前向安全**。而对于 TLS，非 FS 套件早已被视为不够安全了。 “前向安全”指的是攻击者拿到现有的密钥时无法解密过往的通讯内容，实现前向安全需要依赖动态密钥及可信源。 由于现在的国产安卓系统都有云备份功能，手机上的 SS 密码没有安全保证，它可以被用来解密一切通讯内容。 此外，由于 SS 的加密不依赖于时间戳，防重放只能靠缓存，但缓存并不是无限的，这就导致实质上的 **无法防重放**。 虽然 VMess 也没有前向安全，但它的头部加密依赖于时间戳，至少做到了防重放（不过，时间戳并不是唯一解） 顺便提一下：Shadowsocks 没有 UoT 结构，各个实现都是 TCP、UDP 同端口，这并不常见，是非常明显的特征。 --- 为了解决现在的一些问题，SS 需要设计一个随机密钥滚动下发机制，以下是我的构想： 1. 首先，这只是内层明文结构的改变，复用现有的加密方式，比如 AEAD 系列 2....
[Announcement of NFTs by Project X #3633](https://github.com/XTLS/Xray-core/discussions/3633)
查看 https://t.me/projectXtls/358 所关联的消息，Xray 应当只列出安全的 Web 面板，否则任何协议上的安全设计都是空谈 **安全的 Web 面板不应允许明文 HTTP，应强制不对公网开放并让用户使用 SSH 端口转发**，或者有有效证书和网页伪装的 HTTPS @MHSanaei @alireza0 @qist @hiddify-com @Krr0ptioN @SaintShit @VZiChoushaDui 感谢各位长期以来的努力与支持，但安全漏洞不容忽视，请抓紧时间做出改变，我将于晚些时候合并这个 PR