今天想发个频道消息，那就解释一下 REALITY example 中提到的“目标 IP 冷门或许更好”吧，它的意思是：中间人找不到你的 dest 就更好了。最近 @yuhan6665 写的 RealiTLScanner 突然火了，你可以用它扫描出某个 IP 段的网站，然后你查其域名的 DNS 解析，如果没有指向被扫出的 IP，而是指向了 CDN，very good。

Update：也就是说 GFW 会以为你的 REALITY 就是源站、仅此一家。

记得点个 Star：https://github.com/XTLS/RealiTLScanner

今天又想发个频道消息，那就科普一下 REALITY 和 ShadowTLS+SS 的加密安全性吧。

首先，前者是真正的 TLS，而后者是 SS 伪装成 TLS。即使假设它伪装得很完美（实际上并不完美），其本质上还是 SS，安全性完全无法和 TLS 相提并论。最明显的就是，SS 并没有“前向安全”等高级安全特性，这一点我在两三年前就提出了，并且经常提到。简单来说，在任何时间点，若你不小心泄露了 SS 的密码或 VMess 的 UUID，GFW 就可以解密你以前、以后的所有加密流量，以及进行完美的中间人攻击，这是非常可怕的。你可能会问，怎么会泄露呢？手机云备份、输入法上传、剪贴板、国产软件等，以及一些我们不知道的途径。如果你直接在微信上分享节点，那就更厉害了。我知道这些原理，以前偶尔用 SS 时都是提心吊胆，生怕手机屏幕被监控拍到，把昨天电脑上的流量都搭进去了。所以我也说了，中转机场在国内段用 SS / VMess 就是自欺欺人，迟早全解密了，在 GFW 面前无异于裸 Socks5。有人提到 IPLC，注意，你的流量还是要过国内公网，还是会被记录，并没有什么区别。

REALITY 作为 TLS 当然有前向安全，且不依赖 CA，比常规 TLS 更安全。之前有人疑惑为什么 REALITY 没有直接拿 VLESS UUID 来做认证，而是加了一套公私钥机制？解答如下：若使用对称密钥，GFW 拿到客户端配置就可以进行中间人攻击，我不喜欢。若使用 X25519 公私钥结合 TLSv1.3 key_share，即使 GFW 拿到了客户端的公钥，它甚至无法用来验证某一条连接是 REALITY，更无法进行有效的中间人攻击。我说过，REALITY 的设计是默认客户端配置已经泄露，所以把安全性拉满了，保护好 REALITY 服务端的私钥，你的流量就非常安全（若私钥泄露，GFW 无法拿它直接解密流量，但可以进行中间人攻击）。当然，定期更换公私钥就更好了。此外，你可以放心地在多个客户端之间共享公钥，服务端也无需像 SS / VMess 一样通过多次解密来区分用户......更多的内容，请等文章。

最后提一下昨天群里聊到的 TLS in TLS 问题，一定要理解本质：它指的是内层 TLS 握手特征，以及加密套娃特征，并不是你把外层 TLS AEAD 换成 SS AEAD 就能消除的，所以 ShadowTLS+SS 当然存在 TLS in TLS 问题，和 Trojan 差不多。REALITY 是 TLS，所以我们可以直接用现成的 XTLS Vision 成熟解决方案，这也是 REALITY 的优点之一，即 TLS 上的东西都可以直接平移过来。包括 H2 与 gRPC，它们自带多路复用，可以缓解问题。

以上只进行了简单的对比，还有更多方面没有列出来。综上，REALITY 比 ShadowTLS 更好，我更建议你使用 REALITY。

REALITY 隐藏玩法：任意 SNI、无 SNI https://github.com/XTLS/Xray-core/discussions/1988#discussioncomment-5736999

REALITY 未来玩法：REALITY + NaiveProxy https://github.com/XTLS/Xray-core/discussions/1993#discussioncomment-5737892

Update：浏览器访问 https://IP，若返回了证书，即该网站有“默认证书”。一般来说该网站收到不认识的 SNI 时，也会返回该证书。

新建了文件夹，等一个有缘人：
https://github.com/XTLS/naiveproxy-reality
https://github.com/XTLS/forwardproxy-reality

💬 New comment on Xray-core#2017 1.8.1 panic
by @RPRX

顺便先简单说一下 v1.8.1 增强版 XUDP 的 Global ID & UoT Migration 有什么效果：

v1.8.1 以前，你用任何 UoT，假设服务端用 A 端口与多目标通信，若 TCP 断了，比如切换网络，重连后服务端会改用 B 端口。
v1.8.1 开始，你用 VLESS（包括 Mux.Cool），即使 TCP 断了，重连后服务端还是会用 A 端口。

尤其是，对 P2P 有奇效。从某种程度上来说，这才是真正的 FullCone。双端 Xray-core v1.8.1+ 自动启用，无需额外配置。

可以用 [NatTypeTester](https://github.com/HMBSbige/NatTypeTester)，先连接家里 WiFi 测一下，再连接手机热点（流量）测一下，你会发现服务端出口端口没变，~~挺神奇的。~~

~~更多内容，咕咕咕，请等文章。~~

Reply to this message to post a comment on GitHub.

看到今天群里有讨论“隧道”，说是听起来很高端的样子。那么，科普一下“隧道”和“代理协议”有什么区别：

本质上没有任何区别。

比如，你可以说自己在用 REALITY 隧道。

Update：有人说 TLS in TLS 是骗流量、炒作，所以我写了这个简单检测 TLS in TLS 的工具，它可以精准地检测出 Trojan 代理，欢迎大家自行对比测试并提交结果至 issue 区。

https://github.com/XTLS/Trojan-killer

看到一份转发出来的聊天记录：https://t.me/projectXray/2379736 。这位自我感觉良好的 webRTCCat (usr_bin_cat) 从别处看到对 Trojan-killer 的评价：“老鼠有四条腿一个尾巴，所以有四条腿一个尾巴的就是老鼠”，所以睿智的他直接就信了，毕竟他的智商不足以注意到这句话存在一个基本谬误：四条腿一个尾巴在动物界中很常见，而 Trojan 的 TLS in TLS 特征在正常流量中却不常见，这两者无法类比。这位智者还说“首先他得知道假阳性这个概念”，显然这位朋友的眼睛也有点问题，没看到 Trojan-killer README 就写了“对于浏览器的 HTTPS 流量，几乎没有阳性结果”。当然了，他能发出这么一番丢人现眼的言论，显然是自己并没有实际部署、对比测试过，否则他会发现：智能发育障碍竟是他自己。

我们这位朋友说“如果靠一个简单的size匹配能过滤全部tls流量，那么密码学的基础就不存在了”。我评价一下，首先，数据长度特征本来就是检测“恶意加密流量”的基础维度，有很多文章讲过，网上一搜一大把，其次这种宏观行为模式匹配和密码学并没有什么关系，可以说是一句话就暴露了水平。还有这位朋友的朋友提到了 SSL VPN，啊这，我想说，你都 SSL VPN 了，真被 Trojan-killer 抓出来了难道很冤枉吗？？

我们这位朋友说应该用捕获的全流量来测试，所以我这边开 Tun 模式进行了 25 分钟的测试，打开各种类型的应用、正常使用电脑，产生了近 2000 条 TCP 连接，其中大部分目标为 443 端口。结果是只有一条误报，并且相同目标还有十条连接并没有被误报，而此时使用 Trojan 是直接刷屏，这已经足以区分、足够实用了。群里正好有人在测试浏览器代理的方式，结论是误报率约为千分之一。这还只是原始的误报率，实际封锁看的是相同目标的整体阳性率，Trojan 直接刷屏肯定是跑不掉的。此外，Trojan-killer README 有提到“白名单域名”会被豁免，推测这是 GFW 用来减少误封的方法之一。

我们这位朋友承认了自己失礼在先，那么，如果现在你要友好交流、探讨，我们当然是欢迎的。我们欢迎任何人把测试方法、数据、结果发送至 https://github.com/XTLS/Trojan-killer/issues ，在事实的基础上进行探讨。注意，前提是，你要自己实际测试过，不要一看到最终判定部分的代码就开始高潮。

我们这位朋友去哪了，为什么不出来说话了？

我们这位朋友现身了，可惜他并没有对“如果靠一个简单的size匹配能过滤全部tls流量，那么密码学的基础就不存在了”这句高度疑似智能发育障碍的言论作出任何说明，估计是他自己也意识到了问题的严重性，圆不回去。为了显得自己有话可说，这位朋友只能继续往上杠，继“捕获的全流量”之后（对于 Tun 模式的数据，我补充一下：不含 Trojan 是 1208 条 443，所以原始误报率也是约千分之一），又说我们应该用 wireshark's ultimate pcap 进行测试。这个文件解压后为 82.7MB，我想先打开看看包含什么，尴尬的是，等了半天，我的外星人电脑竟然没能打开它。那么，本着谁主张谁举证的原则，这位朋友应该自己进行测试、举证，当然他自己是没测的，群友追问他的结果以及如何复现，他就直接哑火。事实上，这位朋友从未拿出过他自己实际的测试数据，一切观点均靠意淫，可以看出这位朋友的精神世界还是非常强大的，毕竟最后还使出了“精神胜利法”：躲回自己的小频道发了一句“不要试图在泥潭里和猪摔跤，肯定不会赢的”，不过，我怎么好像只看到了这位朋友自己被赶到泥潭里打滚表演让大家伙看笑话开心呢？

警惕 SNI 白名单地区隐蔽的大规模“降级攻击”

根据长期的观察，以及多位身处 SNI 白名单地区的群友的反馈，这些地区的 IPv4 TCP 并不封锁 SS、VMess 这类全随机数裸协议，与其它地区的封锁策略形成了鲜明的反差，是一种非常反常的现象。

我们已知对于封锁翻墙流量，SNI 白名单是一种附带伤害极高的方式，我们也知道，其它地区的 GFW 正在轻易识别并封锁全随机数裸协议。那么请大家思考：为什么某些地区并不在乎附带伤害，对 TLS 采用 SNI 白名单这样的强过滤策略，却“完全不管”全随机数裸协议？

只有一种可能：故意留的口子，除此之外没有任何其它合理解释。我们已知相较于 TLS，全随机数裸协议相当于是把翻墙写在了脸上，更便于识别、掌握情况。且它们普遍缺乏 TLS 的“前向安全”等高级安全特性，非常原始，通过某种方式拿到密码就可以解密以前、以后的所有流量，非常利于监控。所以我认为，这种 SNI 白名单+不封锁全随机数裸协议的组合策略，实质上是在迫使人们从较为安全的 TLS 协议迁移到不够安全的全随机数裸协议，是一场隐蔽的大规模“降级攻击”。

SNI 白名单地区存在的这种非常反常的现象也从侧面证实了，我在多个场合曾提醒过的关于全随机数裸协议的种种风险切实存在，就连 GFW 也明确希望你们使用全随机数裸协议而不是 TLS。目前，这些地区仍可直接使用 REALITY，且它解决了 TLS 令人诟病的 CA 风险。或者，配置 REALITY over SS：https://github.com/XTLS/Xray-core/discussions/1811#discussioncomment-5355075

看起来你对 GFW 有一些刻板印象，我知道有不少人是这样，正好借此机会纠正、科普一下... https://github.com/net4people/bbs/issues/254#issuecomment-1562817397

关于为什么我不公开用 TG：简单来说，发的消息越多、越长，越容易定位到个人 https://github.com/net4people/bbs/issues/254#issuecomment-1564142547
补充：https://github.com/net4people/bbs/issues/254#issuecomment-1564481256

有群友问我怎么看，我简单说一下，有个小问题是 CDN 为了阻止对源服务器的攻击，可能不支持 streaming request 回源，比如 cloudflare 就不支持它（worker 没测过）。Workaround 是客户端每次发包都新开一个请求，但不太优雅，且会带来一些新的小问题。

参考：https://github.com/XTLS/Xray-core/issues/1794#issuecomment-1468244324

好消息：不叫 Reality Pro、realityOS
坏消息：它叫 Vision Pro、visionOS
好消息：下一个 XTLS 流控不叫 Vision

现状过于符合三年前我被一些人认为是“过于激进”的一系列观点，他们没想到真的会这么刺激，看来我拿到的是一张预言家的牌。

我都怀疑自己消失那段时间是去升级 GFW 了，你看时间都完全对得上。你品，你细品。那我就不装了，我摊牌了：我开玩笑的。

https://github.com/XTLS/Trojan-killer/issues/6#issuecomment-1586086101

我们已经在 Xray-core main 分支移除了：

1. Legacy VMess 相关代码（alterId）
2. MTProto 协议
3. miekg/dns 编译依赖（0.7 MB）
4. starlark 相关依赖（0.7 MB）

感谢 @yuhan6665，请大家测试 https://github.com/XTLS/Xray-core/commit/9112cfd39c2105d5b513275f9659b26e92fa7b67

有更多报告吗？（顺便提一下，我们也注意到了最近群里相对冷清，分析是因为很多人已经部署了 REALITY，加上墙在该发威时没发威，稳定使用便无需再关注这些，这是好事。参考去年底墙发威后，大家对 Project X 的关注度飙升。）

https://github.com/XTLS/Xray-core/discussions/2211
我的回复：https://github.com/XTLS/Xray-core/discussions/2211#discussioncomment-6183390