XTLS Vision, fixes TLS in TLS, to the star and beyond

[yuhan6665]

一、XTLS 深入浅出

XTLS 的核心逻辑在于使用真实的 TLS 将代理流量隐藏于互联网最常见的流量之中。
对于普通 TLS 代理协议（比如原版 Trojan），用户的代理客户端与代理服务器建立一个真实的 TLS 连接，通过这个加密的隧道，应用程序（比如浏览器）再与目标服务器（比如 Google）建立一个 TLS 连接。这时浏览器与 Google 服务器就是端对端加密，任何人（包括代理服务）不能解密或者伪装发送信息，这就是所谓的 e2e。

浏览器 ---- 代理客户端 ==== 代理服务器 ---- Google

代理数据经过审查者的时候其实经过了2次加密，而 RPRX 敏锐的发现在这个过程中 99% 的流量其实是不需要做额外加密的。因为经过 TLS 1.3 加密的数据在外观上是完全一致的，审查者无法分辨。也就是说代理逻辑只需要：

1. 建立一条真实 TLS 链接
2. 在加密隧道内，跟踪浏览器与 Google 之间的通信，识别当前的通信是否为 TLS 1.3
3. 如不是，则使用普通 TLS 代理方法，继续使用加密隧道
4. 如是，则等待两端开始传输加密数据，代理客户端在第一个内层加密包中插入 UUID，指示代理服务端：我们准备裸奔了！
5. 从第二个内层加密包之后，XTLS 就不再对数据包做任何操作，只是单纯拷贝

这就是 xtls-rprx-vision
我们可以发现

• 代理发起的外层 TLS 是真实的，所以审查者无法破解
• 裸奔的流量在代理方面只做单纯拷贝，如果审查者进行任何破坏，将会得到浏览器与 Google 服务器的正常 alert 响应，与一般访问无异
• 裸奔的信号是 UUID，此信号是代理私有信息，以避免类似 关于 23 3 3 判断部分的 代码特征的利用漏洞 Go#17 的漏洞

二、近乎完美

10月3日开始大规模识别和封锁 TLS 代理，透过一些相关讨论及内幕信息，我们知道审查者使用了海量资源以及机器学习的方法。众所周知，机器学习的特长在于从海量数据中提取统计学特征。
引用 klzgrad 的话，普通 TLS 代理的一个重要弱点就是加密套娃。上面讨论提及，虽然加密包的外观对于审查者无法分辨，但加密套娃无可避免的一点就是在每个包都会增加一个数据包头，加密层数越多，包头就会越重。
这个增量虽然不大，但对于小数据（比如应答包）可能比较明显，而且会有一些包长超过网络底层的 MTU 限制。最重要的，由于每个包都增加了相同长度，它可能具有某些统计学特征。

RPRX 当年发明 XTLS 主要原因是为了减少额外加密，我们现在推出新流控 Vision，则是因为 XTLS 在对抗审查者有独特的能力。可以说，当传输 TLS 1.3 数据时 XTLS 99% 的数据包，拥有几乎完美的流量特征。因为它是原始数据，没有经过任何代理加工。

三、TLS in TLS

为什么说 99% 的数据包都是原始数据？那 1% 究竟是什么？
我们需要继续探索一个典型的代理在遇到内部 TLS 1.3 流量的时候，最开始是几个包究竟在干什么。
形象的看，当加密通道建立以后：

第一个包 		 代理客户端 -> 代理服务器  		"你好 本次代理访问的目标地址是 Google 这里是我的 UUID"
第二个包 		 代理客户端 <- 代理服务器  		"你好 收到了你的代理请求 请开始发送数据"
第三个包 	浏览器 -> 代理客户端 -> 代理服务器 -> Google 	"你好 Google 我将和你进行加密通话 我支持的加密方式有。。" (这个包也叫 TLS Client Hello)
第四个包 	浏览器 <- 代理客户端 <- 代理服务器 <- Google 	"你好 用户 这是 Google 证书 本次将使用 TLS_AES_128_GCM_SHA256 加密 让我们开始加密通话！" (这个包也叫 TLS Server Hello)
第五个包 	浏览器 -> 代理客户端 -> 代理服务器 -> Google 	"收到 让我们开始加密通话！"

你所知道的代理协议万变不离其宗，只要用户使用了任何 TLS 连接，都需要进行上述的握手过程。前面提到，外层 TLS 加密后可以认为是绝对安全的，但对于审查者而言，除了破解信息以外，还可以利用一些附加信息来识别这5个包。
这就是所谓 TLS in TLS 检测的关键点。

四、生死5包

最明显的特征，是这5个包的长度。其中

第一个包 	很短 	唯一的变数是目标地址 
第二个包 	很短 	几乎固定
第三个包 	短 	变化很少 几乎唯一的变数是目标 SNI
第四个包 	长 	变化较大
第五个包 	很短 	变化很少

可以直观的感受到，它们的包长特征其实是十分明显的。在 Vision 中，我们的应对方法也十分简单，就是将每一个短包的长度填充至 900 到 1400 这么一个区间。注意，这个方法与传统的随机填充不同，我们不是盲目的在所有包都加上填充，而是基于我们对内部流量的分析，有针对性的，对 TLS 握手过程的标志性的包进行填充。

另一个比较隐蔽的特征叫做时序特征。受限于 TLS 握手的设计，你可以注意到，前面这几个包的顺序是固定的。也就是说，浏览器发送 TLS Client Hello 之后，必须等待 Google 发出 TLS Server Hello 这一信息，而这之后浏览器又必须发送一个"收到 让我们开始加密通话！"，如此后面的对话才可以正常进行。
如果把用户到服务端发一个包叫做 C，反方向一个包叫做 S。审查者是否能够根据 CSCSC 这种数据时序，它们的时间间隔特征来判定这是一个 TLS in TLS 连接？
我们认为现在还不足以下结论，Vision 并没有在这个方面做处理。
有很多开发者都提到 MUX 多路复用对抗 TLS in TLS 检测。它在这方面的确有混淆作用，假如多路复用两个不同的 TLS 连接在一个隧道里，就有机会会形成 CCSSCC 等各种不同的时序特征。

可以预期，翻墙的技术战争将从 shadowsocks （加密）-> 主动探测 -> TLS -> 机器学习 继续升级，是生存或者死亡，将很大程度上取决于这5个包的处理。

五、常见问题

问：Vision 的填充长度是写死的，是不是也有统计学特征？
答：首先网络安全概念上没有绝对的安全，理论上讲任何加密都可以暴力破解，只是计算量（投入资源）大小而已。作为安全协议的设计者，我们只需要把破解和识别的难度提高到审查者无法企及的高度即可，这个高度是多高？恐怕需要在战争拉锯中我们才能知晓。
回到我们已知的信息，TLS 1.2 和 1.3 握手包的长度分布是非常稳定的。几个关键包访问主流网站（比如 Google）可以看作是固定长度。如果把 Vision 现有的大包随机长度，跟不加填充的握手包相比，识别难度应当会增加一个数量级。
另外，在一些泄露出来的讨论中，有人提到机器学习可以识别低于 40% 的随机填充。这可以侧面证明机器学习存在辨识上限。

问：为什么新流控取名 Vision
答：我们认为 Vision 代表了 RPRX 原本的设计理念。XTLS 初版事实上是在探索中开发的，而且受限于当时的开发环境，有一些地方过于复杂，可以说，Vision 代表了 XTLS 的理想形态和未来方向。RPRX 说：

Flow.. 要解决什么问题？它影响的是宏观流量时序特征，而不是微观特征，后者是加密要解决的事情。流量时序特征可以是协议带来的，比如 Socks5 over TLS 时的 Socks5 握手 ，TLS 上不同的这种特征对于监测者来说就是不同的协议，此时无限 Schedulers 就相当于无限协议（重新分配每次发送的数据量大小等）

v2ray/v2ray-core#2636

Direct 其实并不需要魔改 TLS 库就可以实现，它不需要读过滤，甚至传输 TLSv1.3 时连写过滤都不需要，非常简洁、高效

XTLS/Go#12 (comment)

问：新流控这么好，你们推荐所有人都使用它翻墙吗
答：正如其它开发者所言，对于当前的审查者，把所有鸡蛋都放在一个篮子里是十分危险的。所以我们鼓励大家善用每个工具的特性，分散特征。

• @klzgrad NaiveProxy 使用 Chrome 浏览器架构当作代理客户端以及 Caddy 当作代理服务端，可以高度模仿一个普通的 HTTPS 访问，它也包含的 TLS 握手以及其它特征包的填充
• @gfw-report 仅仅花一个下午写出的魔改 shadowsocks 通过注入额外数据的方式，改变传统 shadowsocks 无序流量的特征
• 在纯自用的情形下，使用 MITM 代理，目前这种方式工具较少，可以参考 https://github.com/KiriKira/Kirikira.moe/blob/master/articles-md/V2Ray%E7%9A%84%E8%BF%9B%E9%98%B6%E6%95%99%E7%A8%8B(2):MITM.md

问：对于未来你推荐国密比如 sm4 吗？
答：不推荐，正如一开始提到，我们认为最安全的方法就是隐藏于互联网中最常见的流量之中。除了 HTTPS 以外，我们应该考虑什么样的出国流量是常见的。SSH？Remote Desktop？微信视频？Email（雾）？电波通信（大雾）？
而不是使用一个极其小众的加密和协议。

六、我们的一点看法

其实基于 TLS 的代理在2017年就有相当成熟的应用了。2019年大规模封锁 Shadowsocks 服务以来，可以想见，审查者投入了极大人力物力算力，用了至少3年时间，才有了今天的技术。而截至目前的情况，我们看到仍然有误封，CDN大半存活，IPV6存活，以及从 Xray 项目的访问量以及 telegram 群在线人数屡创新高的情况来看，审查者本次阻绝信息的效果，实际上十分有限。

作为开发圈成员，可以毫不夸张的说，我们这群”破铜烂铁“的志愿者队伍，Shadowsocks，*ray，Trojan，Naive，Hystaria，Tuic，Sing，在此之前一直把审查者按在地上摩擦，还是花式的。

TLS 代理战争才刚刚开始，审查者之所以要动用 AI 手段，恰恰从侧面证明了以前的审查方式，包括主动检测对于 TLS 代理都是无效的。而我们面对 AI 对手，必须要在细节层面做的更好。
我们可以充分发挥己方的长处，集思广益，开源，分散特征。具体而言，作为代理工具和服务，可以直接过滤内层流量，这其实是我们对审查者的一个天然优势。利用这个信息差，Vision 的逻辑可以对关键的 TLS 握手包进行填充。这个思路跟 NaiveProxy 针对一些特定包的填充 是一致的。

感谢你耐心阅读本文，欢迎广大技术爱好者留言与我们交流，每一个留言和 idea 都将成为我们战斗的一份力量

最后 To @RPRX
青山不改 绿水长流 愿你归来仍是少年

[chika0801]

旧版 XTLS 的 233 主动探测并不存在，说明详见 XTLS/Go#17 (comment)

[jelly0925]

太强了，辛苦

[lyrl]

辛苦💦

[Miempire]

必须顶

[2020-spring]

青山不改 绿水长流 愿你归来仍是少年.
全文结尾这句，堪称点睛之笔。老大必须是少年！
少年强则国强@所有人

[suzishan]

写得太好了, 都看哭了... 哎呀我竟然看一篇技术文章看哭了...

[wbbo]

顶呱呱

[yoohooyoo]

最后一句泪目。
他会回来的。
或者，他从来没离开。

[hedsbj]

感谢 @RPRX

[Zander-1024]

他回来了

[Oakento]

他已如閃電般歸來（

[gydchenxiao]

R佬如闪电般归来

[missyea]

解释的相当通俗，让我这种TLS小白也能看的津津有味。
很棒的文章，感谢分享。

[seakfind]

@yuhan6665 This is an important post. For the benefit of international readers, may I have permission to post a translation into English by Google Translate?

[yuhan6665]

That's a good idea. A couple of note though, I particular use some feature from Chinese, it might be confusing to translate. Secondly, this post is intended for introduction, I hide some of the implementation details so they may appear inaccurate.
If you post anywhere else, please cite the source. Thanks!

[seakfind]

If you post anywhere else, please site the source.

Thanks. Done! https://github.com/seakfind/examples/blob/main/xtls-vision/README.md

[Michaol]

致敬各位开发者、维护者以及RPRX，你们的无私付出让我更加了解世界！

[shuiliu11]

非常棒，尤其是当我读到“翻墙技术战争”的时候，这四个字完全可以用“较量”“切磋”这么LOW的！这充分反映了我们所处的时代境况。
还有就是“国密”时，完全赞同！
正是使用了这个项目，使我在个人领域学习到了更多国外高级的知识。“谢谢”是我这2年来最想对你们说的话。

[wanxj119]

非常感谢！非常感谢！

[tianlichunhong]

对你们这群开发者，我只有敬仰。不仅仅是你们的程序开发太棒，而是你们的思想。在严酷的环境下，帮助受困的人群。不亚于在二战时期，那些帮助纳粹控制区的犹太人逃出生天的勇士。希望有一天历史能写上你们的名字，一群为中国网民提供自由而奋斗的勇士。

[Qlmuby]

你可能把他看成监狱。 在我眼中它是保护大众免受垃圾、虚假信息伤害的长城。 不得不说长城防火墙这个名字起的太好了。 我觉得现在的情况挺好的，有兴趣的翻墙，没兴趣的也能受到保护。

我看待翻墙有点儿像色情视频的感觉，偶尔看看，有工具可以用，挺好的。 但是你身边充斥着色情视频，那处境就不太妙了。 尤其是目前国外媒体无脑反华的情况下。

我宁可相信世界上有鬼，疫情都开放了，人也死不少了，这玩意也没松懈反而愈演愈烈，出发点哪有你想的那么简单，肯定有比疫情死人更让其在意的理由才会如此，像你所说就是为了让大家免受垃圾、虚假信息伤害？现在连人口都不得不放弃一部分了，为了提高出生率放开点社会情欲都没啥大不了的情况下，孰轻孰重谁心里没点数呢？很多事得自己根据实际情况去分析和感受，你分析出来得才是你能相信的，剩下谁说啥也别信。

[Qlmuby]

你可能把他看成监狱。 在我眼中它是保护大众免受垃圾、虚假信息伤害的长城。 不得不说长城防火墙这个名字起的太好了。 我觉得现在的情况挺好的，有兴趣的翻墙，没兴趣的也能受到保护。
我看待翻墙有点儿像色情视频的感觉，偶尔看看，有工具可以用，挺好的。 但是你身边充斥着色情视频，那处境就不太妙了。 尤其是目前国外媒体无脑反华的情况下。

我宁可相信世界上有鬼，疫情都开放了，人也死不少了，这玩意也没松懈反而愈演愈烈，出发点哪有你想的那么简单，肯定有比疫情死人更让其在意的理由才会如此，像你所说就是为了让大家免受垃圾、虚假信息伤害？现在连人口都不得不放弃一部分了，为了提高出生率放开点社会情欲都没啥大不了的情况下，孰轻孰重谁心里没点数呢？很多事得自己根据实际情况去分析和感受，你分析出来得才是你能相信的，剩下谁说啥也别信。

[Miempire]

你可能把他看成监狱。 在我眼中它是保护大众免受垃圾、虚假信息伤害的长城。 不得不说长城防火墙这个名字起的太好了。 我觉得现在的情况挺好的，有兴趣的翻墙，没兴趣的也能受到保护。

我看待翻墙有点儿像色情视频的感觉，偶尔看看，有工具可以用，挺好的。 但是你身边充斥着色情视频，那处境就不太妙了。 尤其是目前国外媒体无脑反华的情况下。

又被邮件给刷屏了，我也说了，其实这位老哥没必要去争执“墙的意义”之类的话题，因为墙的初衷是以保护大众和政府为了掌控媒体来避免国内过度"资化"思想发展的工具，但它不可能永远是为这个目的的，一切都会随时间变质，就好比国内的贪腐，最开始的国家垄断制盐命脉是为了人民的生活，但后来却变质出了"官员倒卖"这种丑闻，这种垄断却危害了人民，这就需要有东西来制衡它，所以墙可以有，但翻墙也同样得有

[Miempire]

你可能把他看成监狱。 在我眼中它是保护大众免受垃圾、虚假信息伤害的长城。 不得不说长城防火墙这个名字起的太好了。 我觉得现在的情况挺好的，有兴趣的翻墙，没兴趣的也能受到保护。

我看待翻墙有点儿像色情视频的感觉，偶尔看看，有工具可以用，挺好的。 但是你身边充斥着色情视频，那处境就不太妙了。 尤其是目前国外媒体无脑反华的情况下。

又被邮件给刷屏了，我也说了，其实这位老哥没必要去争执“墙的意义”之类的话题，因为墙的初衷是以保护大众和政府为了掌控媒体来避免国内过度"资化"思想发展的工具，但它不可能永远是为这个目的的，一切都会随时间变质，就好比国内的贪腐，最开始的国家垄断制盐命脉是为了人民的生活，但后来却变质出了"官员倒卖"这种丑闻，这种垄断却危害了人民，这就需要有东西来制衡它，所以墙可以有，但翻墙也同样得有

[nujifdd]

粉红们经典的墙是为了你好，是为了屏蔽有害信息，不知道他们的有害信息包括不包括编程随想的赵项目，包不包括巴拿马文件中习近平家族的信息。也不知道他们的有害信息包括不包括墙内各种西方阴谋论和谣言。大家也都不是外宾了，建墙是为了什么心知肚明。这里我想起了鲁迅的的一句话：“做奴隶不可怕，可怕的是从做奴隶中寻出美来，甚至赞美、陶醉，那才是万劫不复的奴才。

[cross-hello]

It is still happening~

…

---------------------------------------- *Từ: *Wilson ***@***.***> *Đến: *XTLS/Xray-core ***@***.***> *CC: *Subscribed ***@***.***> *Ngày: *Nov 9, 2022 02:59:19 *Chủ đề: *Re: [XTLS/Xray-core] XTLS Vision, TLS in TLS, to the star and beyond (Discussion #1295)

对你们这群开发者，我只有敬仰。不仅仅是你们的程序开发太棒，而是你们的思想。在严酷的环境下，帮助受困的人群。不亚于在二战时期，那些帮助纳粹控制区的犹太人逃出生天的勇士。希望有一天历史能写上你们的名字，一群为中国网民提供自由而奋斗的勇士。 — Reply to this email directly, view it on GitHub[#1295 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYFF7GHFDQTTVGRZCFLWHMHQNANCNFSM6AAAAAARSVRFZM]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYHU3YQRKVR7ZS2VFFLWHMHQNA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAHZZSK.gif]Message ID: ***@***.***>

[littlemingone]

根据这个的说法，目前检测主要是根据tls建立连接时几个握手包的长度来识别的，并且vision也是为了解决这个握手包长度特征开发的。

但是这无法解释之前许多人遇到的电脑连接没有事，手机一连接vpn就会被封端口的现象。毕竟在这个握手包的问题上电脑和手机应该是一视同仁的。反而是之前某截图中所说的通过检测aes加密的硬件加速特征，发现流量同时有手机cpu和电脑cpu硬件加速的特征就认为这是一个与翻墙相关的流量更能解释这个现象。

并且我自己将tlsSetting中的cipher Suite改成chacha20后确实没有再被封过端口。为了验证是否放松了，我又把chacha20关掉后重新做了个阳性对照，第二天那端口就没了。当然虽然这做法有效，但是我用wireshark抓包后发现跟代理服务器建立连接时使用的还是aes-128加密。但这确确实实让我没有再被封过端口了。这个cipher Suite具体是怎么工作的可能还需要了解xray内核的大佬解释一下。

所以现在vision效果如何，有效吗？另外就是未来是否会将vision的配置方式改成类似以前xtls的xtlsSetting配置方法，还是说会一直保留目前的配置写在tlsSetting里的做法？

[yuhan6665]

感谢留言，审查者应当使用了多个系统/检测方法。

本次封锁一个明显的特征是针对 TLS，本文所详述的 TLS in TLS 也只是检测 TLS 代理的方法之一。另一个重要的特征是 TLS 客户端握手（外层），你提到的修改 cipher Suite 就是这个特征的一项。我的推荐是不需要手动修改这个配置，而是使用 v1.6.3 中 uTLS fingerprint 选项，它可以更加成熟的模拟常见浏览器或者生成随机握手。（正是由于简化代码架构带来的这些好处 Vision 的配置将保持使用 tlsSetting）

至于手机端连接会导致被墙这一现象，在其它地方已经有一些讨论了，我个人的猜测是由于手机端使用 VPN service 默认是全局代理，国产系统，国产应用会产生大量流量，其目标服务器是国内。审查者在国际出口部署的流量检测可以记录下两个反向 TCP 连接，通过这个信息发现了代理服务器。近期 @iceboy233 设计的一个有趣的实验验证了这一点。

[Bit0r]

现在很多国产安卓系统都会主动上传流量统计数据和软件的流量使用数据，zf只要专门封杀v2rayN/ss等apk的出站和入站数据就很容易找出代理服务器

[tongxiangzheng]

手机连接vpn就封端口，可能是因为DNS泄露。电脑端使用sock5时，浏览器等应用不会进行DNS解析，而是全部交给代理工具处理。然而使用vpn方式时，各种应用会正常发送DNS请求。然而如果对墙外网站的DNS请求通过直连发出，就会产生非常明显的特征

[alan636]

在路由器 放行 vivo的WiFi generate_204+屏蔽所有vivo域名 后，vivo手机会正常使用3-15分钟，之后整台手机断网。很不服气的是，监控用户上网就算了，居然还断网！是不是vivo倒闭了，全部vivo手机都不能使用了？

注：有时断网变成了卡网，访问百度等均非常慢，网速快的10kB/s，慢的0kB/s。营造一种对方服务器不稳定的假象。

[LD-KiLLer]

我之前是用Nginx443反代vless+tls的方式，套cdn都秒封。这两天改成Nginx443直接反代vemss，没有开启tls，直接使用的Nginx的tls。没套cdn，已经正常运行了3天。

[bash99]

请注意控制变量。事实上，哪怕是同一种软件，TLS 版本选择的不同，也会影响 JARM 指纹。

总而言之，我的意思是，JARM 的指纹非常多样，并不能因为你的 JARM 指纹与别人不一样就把你一棒子打死，这个是不对的。

缺省的指纹仍然是一样的，这也就是绝大多数， 同时我也没找到把两个指纹调成一样的办法。
caddy 无论是改key的格式（rsa 2048）或者是tls支持的最小版本，都可以改变jarm指纹，但是仍然和*ray不一样。

[xiaopang0v0]

请注意控制变量。事实上，哪怕是同一种软件，TLS 版本选择的不同，也会影响 JARM 指纹。
总而言之，我的意思是，JARM 的指纹非常多样，并不能因为你的 JARM 指纹与别人不一样就把你一棒子打死，这个是不对的。

缺省的指纹仍然是一样的，这也就是绝大多数， 同时我也没找到把两个指纹调成一样的办法。 caddy 无论是改key的格式（rsa 2048）或者是tls支持的最小版本，都可以改变jarm指纹，但是仍然和*ray不一样。

所以说，JARM 并不能直接导致 xray 被精确识别。因为配置文件每个人都会有很大的不同。

只能说，可以通过对网络上常见的一键脚本进行部署分析，获取这些一键脚本部署后的 JARM 指纹，然后对使用这些一键脚本的用户进行精确识别。我想，这个是可以做到的。

[bash99]

所以说，JARM 并不能直接导致 xray 被精确识别。因为配置文件每个人都会有很大的不同。

只能说，可以通过对网络上常见的一键脚本进行部署分析，获取这些一键脚本部署后的 JARM 指纹，然后对使用这些一键脚本的用户进行精确识别。我想，这个是可以做到的。

xray的各类普通配置对应的指纹是一样的，你可以自行试试。大部分对配置文件的变化对指纹毫无影响。

[LD-KiLLer]

测试了快1个月，后期在良心云上也采用了这套方式，暂时幸存😁

[bash99]

测试了快1个月，后期在良心云上也采用了这套方式，暂时幸存😁

这个模式是哪种？nginx里面直接proxypass？backend 怎么指定的？

我现在倒是各种模式都没被封锁，只不过有备无患多了解一种。

[cross-hello]

Wow, you give a hint. Why people using Nginx/Caddy as traffic agent processing TLS open another TLS certificate in xray...

…

---------------------------------------- *From: *LD-KiLLer ***@***.***> *To: *XTLS/Xray-core ***@***.***> *CC: *Nanyu ***@***.***>; Comment ***@***.***> *Date: *Nov 10, 2022 16:43:45 *Subject: *Re: [XTLS/Xray-core] XTLS Vision, TLS in TLS, to the star and beyond (Discussion #1295)

我之前是用Nginx443反代vless+tls的方式，套cdn都秒封。这两天改成Nginx443直接反代vemss，没有开启tls，直接使用的Nginx的tls。没套cdn，已经正常运行了3天。 — Reply to this email directly, view it on GitHub[#1295 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYAFHXH6AKL3AWYEI53WHUQ4BANCNFSM6AAAAAARSVRFZM]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYGXZYMSHFTXVZ6NDMTWHUQ4BA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAH22HC.gif]Message ID: ***@***.***>

[XgHao]

一直在用vultr的机子，我只要开亚洲和美洲的 隔天就没 用的 vless nginx xtls utls开启
奇怪的是 同样的配置 我把机子开到欧洲 用到了现在还没被ban
感觉vultr里 亚洲和美洲的机子 差不多都被“监视”了

[numieo]

vultr的好像不是cn2线路的，还和cn2的一样贵，可以找找别的机子

[ilifelog]

vultr的好像不是cn2线路的，还和cn2的一样贵，可以找找别的机子

来个aff，最好换ip不花钱

[linusdrop]

Никогда не думал, что наше технологическое дерево будет выглядеть так

[cross-hello]

So 😅, you hide a time to play game, we originally think you came to grow secretly. Jan 13, 2023 22:10:31 RPRX ***@***.***>:

…

Tun 模式的话，其实两年前 @hmol233[https://github.com/hmol233] 就写了代码 https://github.com/XTLS/Xray-tun ，一直是仅 org 可见，前不久刚改为 public，等待有缘人测试测试，发个 PR 把它合进 Xray-core。我还没细看 hysteria 和 tuic 的实现，可以问下 @yuhan6665[https://github.com/yuhan6665] 是否有 port 过来的计划。说起 QUIC，两年前我改 Xray 的 UDP 时顺手写的 Accelerator 协议计划[#197 (comment)]，当时想过用 QUIC 承载但允许丢包， 个人而言我还是更想要这样的东西来打游戏，可能和你们暴力发包的需求不太一样 ，tuic 的 UDP native 模式是类似的，可惜它似乎没有多倍发包或 FEC， 且目前我不怎么打 GTA5，就先咕着，等 GTA6 出了再说 。当然我也看到了在 anti-censorship 的用途上，目前基于 UDP QUIC 的协议存活率还行，但还需要时间的检验，因为看起来它们还没有被分析、针对（就像 IPv6），目前是 TCP TLS 吸引了主要火力。 @yuhan6665[https://github.com/yuhan6665] 已经维护了 Project X 很长时间且写了 XTLS Vision，能力出众。希望大家明白，他也是 Owner，完全可以说 Project X 及其制定标准的协议 VLESS、XTLS、Reality 等要怎么发展， 不要只认我 。我这边的话，大家可以期待一下新年礼物 Reality 协议。 — Reply to this email directly, view it on GitHub[#1295 (reply in thread)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYCCZC5GWAVLVAT3SGLWSFO5NANCNFSM6AAAAAARSVRFZM]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYHJUAKIPNYNXF57FN3WSFO5NA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAI5REQ.gif]

[cross-hello]

🙃 indeed don't know what is GTA*. We don't play game. So maybe it is some jargons? Jan 13, 2023 22:52:57 yuhan6665 ***@***.***>:

…

查了一下 GTA6 确信这只是一个梗 — Reply to this email directly, view it on GitHub[#1295 (reply in thread)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYC53LQL6A24VCVKCLTWSFT4RANCNFSM6AAAAAARSVRFZM]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYATF4XOSOHHB7BBZALWSFT4RA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAI5R6A.gif]

[ghost]

https://en.wikipedia.org/wiki/Grand_Theft_Auto

[vahidx4r4x]

Hi,
thanks for your great effort.
I've configured xtls-vision on my server and its working soo good.
I have 2 Questions:

1. Is it possible to hide xtls-vision behind the nginx and a camo website? kinda like wulabing's vless-tls-ws nginx front.
2. Is it possible to make it work behind the CloudFlare' CDN?

TNX

[amir11235]

Hi
How can I use xray-vision on ios?

[XgHao]

As far as I am concerned，there is no IOS client support currently.
U can use 'xtls-rprx-vision,none' in server,.
it's work for ios.

[cross-hello]

Excuse, why one another don't use openwrt? Jan 18, 2023 17:43:32 XgHao ***@***.***>:

…

As far as I am concerned，there is no IOS client support currently. U can use 'xtls-rprx-vision,none'[https://github.com/XTLS/Xray-core/releases/tag/v1.6.6-2] in server,. it's work for ios. — Reply to this email directly, view it on GitHub[#1295 (reply in thread)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYD3KMT5BPLZZBRCDSDWS63MHANCNFSM6AAAAAARSVRFZM]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYDA3OGWESN4NGLHVX3WS63MHA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAI7Z7S.gif]

[free-the-internet]

Can we have more than one client (UUID) with XTLS-VISION flow?

[FranzKafkaYu]

Can we have more than one client (UUID) with XTLS-VISION flow?

Of course you can.

[free-the-internet]

I created one with https://github.com/reeceyng/v2ray-agent, I can use just the first uuid that I've created. The second one only works with trojan, etc but not VISION.

[free-the-internet]

Probably I'll go to investigate this soon.

[VeganBirdie]

很好，深入浅出，完全不懂计算机网络这些东西都能看明白。接下来就是按图索骥，摸索，学习了。

[sajjadfree]

با درود فراوان خدمت شما دوست عزیز و با تشکر. من یک مبتدی هستم. اگر امکان دارد، مرا راهنمایی کنید، زیرا در ایران سانسور شدید است، مردم از گرسنگی : حتی در سطل زباله ها دنبال غذا و خوراکی می گردند ، قوطی، شیشه، کارتن و امثال اینها را جمع می کنند و آنرا می فروشند و حرفهای زیاد دیگر... معذرت می خواهم از شما و خواهش من این است که vpn های مؤثر را معرفی کنید و سایتهای مربوط به vpn و DNS و کدهای ShadowSocks و دیگر برنامه ها. با تشکر فراوان Sajjad

…

On Mon, Jan 9, 2023, 21:20 RPRX ***@***.***> wrote: 在此我必须要感谢 @yuhan6665 <https://github.com/yuhan6665>，有感而发： 两年半前我在设计 VLESS 时就重点考虑了对抗 TLS 上流量时序、数据量（长度）特征的识别，并在 addons 中预置了 flow 和 seed 这两个参数、推出了 VLESS 的第一个流控 XTLS。当时 @DuckSoft <https://github.com/DuckSoft> 已经在关注 TLS in TLS 检测，并与我交流过。不过当时 TLS 上是个代理协议就能跑，VLESS 协议和它超前的 flow 设计似乎显得有些多余、可有可无，直到去年底剑落，GFW 真正开始大规模部署 TLS 指纹封锁、TLS in TLS 流量识别等（不用怀疑，TLS in TLS ***@***.*** <https://github.com/yuhan6665> 不仅长期花时间维护 Xray-core 项目，还为 VLESS 实现了无需改 TLS/uTLS 库、对内层 TLS 握手 padding、仅裸奔内层 TLSv1.3、自动 splice 的 XTLS Vision 流控，将我的种种预想融合并实践到了极致，让 Xray-core、VLESS、XTLS 都焕发出了新的活力，继续帮助大家自由地访问互联网，真的非常感谢 @yuhan6665 <https://github.com/yuhan6665>！ 顺便说一下尚未启用的 seed 参数，它的定位类似于“我的世界”的种子，是 flow 的辅助项。若以 XTLS Vision 对内层 TLS 握手的处理为例，我的预想中，输入不同的 seed 值可以通过某一算法生成不同的 padding 参数，比如 padding:123456、 padding:abcdef，每个人都可以填不同的 seed 值，让流量长度特征更加多样、混淆、难以被总结出规律；或者 split:123 ，分成小包多次发送；insert:abc，插包，混淆 CSCSC 时序特征；match:xyz，控制流量特征匹配某一可能的“白名单”规律......想象空间很大，我觉得 @yuhan6665 <https://github.com/yuhan6665>，以及任何想参与的人都可以开始着手这方面的研究，wireshark 用起来~ 最后，VLESS 不会只有 XTLS 这一种流控（当然，它是其中性能最强的），若有必要，定会推出牺牲性能来换取其它好处的其它流控 — Reply to this email directly, view it on GitHub <#1295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ3Y5YWLUPTEB66ILPPGJP3WRRFXDANCNFSM6AAAAAARSVRFZM> . You are receiving this because you commented.Message ID: ***@***.***>

[free-the-internet]

میتوانید از کانال تلگرام زیر استفاده کنید. مختوا فارسی است به همراه آموزش. با بقیه ی دوستان و فامیل به اشتراک بگذارید.
https://t.me/wbnet

[free-the-internet]

@RPRX
When the introduction/announcement of REALITY will come? I can't wait to see how it is working ;)

[charure]

和AI对抗，真是非常的Cyber呢

[awaking202002]

燃！！！！

[zizifn]

燃是很燃，但是 tls in tls，和服务器 tls 握手后，vless 下应该只有三个包啊。uuid 是放在 client hello （文章所谓的第三个包） 里面的，不是单独发包。

[RPRX]

对，实际上只有三个包，VLESS header 和内层 TLS Client Hello 是粘一起发的，我给 @yuhan6665 说过，他说是为了便于你们理解

[yuhan6665]

当它引起你思考的时候 你已经变成大佬了
一个小细节 我说的是 “一个典型的代理协议” 所以不一定支持 0rtt 粘包处理 比如 socks5

[lxsq]

如果开启了MUX.cool并且加上vision的填充，是不是就更加没有容易分辨的特征了？

[mS0gxokXEsg5ysJ7J79kzWiqO1fHgFA6ZR8eEls]

大流量协议似乎只有下载类的Torrent模式

[charliez0]

远程桌面也支持TLS1.3，套一个Reality可行吗 @yuhan6665

[iambabyninja]

XTLS

Основная концепция XTLS:

Основная логика XTLS заключается в использовании настоящего TLS для маскировки прокси-трафика среди самого обычного интернет-трафика.
Для обычного TLS прокси-протокола (например, оригинального Trojan), клиент прокси пользователя устанавливает настоящее TLS соединение с прокси-сервером, и через этот зашифрованный туннель приложение (например, браузер) устанавливает еще одно TLS соединение с целевым сервером (например, Google).
В этот момент браузер и сервер Google обеспечивают end-to-end шифрование, и никто (включая наш прокси) не может расшифровать или подделать отправляемую информацию. Это и есть так называемое e2e."

Вот краткая схема:
Браузер ---- Прокси-клиент ==== Прокси-сервер ---- Google

Когда прокси-данные проходят через цензора, они фактически шифруются дважды. Однако, в этом процессе, 99% трафика на самом деле не требует дополнительного шифрования.
Поскольку данные, зашифрованные с помощью TLS 1.3, внешне выглядят абсолютно одинаково, цензор не может их различить.

Таким образом, логика прокси должна быть следующей:

1. Установить настоящее TLS-соединение.
2. Внутри зашифрованного туннеля отслеживать коммуникацию между браузером и Google, определяя, является ли текущее соединение TLS 1.3.
3. Если нет, то использовать обычный метод TLS-прокси, продолжая использовать зашифрованный туннель.
4. Если да, то дождаться начала передачи зашифрованных данных обеими сторонами, а клиент прокси вставляет UUID в первый внутренний зашифрованный пакет, сигнализируя серверу прокси: мы готовы к 'голому' соединению!
5. Начиная со второго внутреннего зашифрованного пакета, XTLS больше не выполняет никаких операций с данными, а просто копирует их.
   Это и есть xtls-rprx-vision.

Мы можем заметить, что:

1. Внешний TLS, инициированный прокси, является настоящим, поэтому цензор не может его взломать.
2. 'Голый' трафик на стороне прокси просто копируется без изменений. Если цензор попытается вмешаться, он получит стандартный ответ от браузера и сервера Google, который не будет отличаться от обычного доступа.
3. Сигналом для 'голого' соединения служит UUID, который является приватной информацией прокси, чтобы избежать уязвимостей, подобных тем, что были в Go, связанных с использованием кодовых характеристик для определения части"

Почти совершенно

С 3 октября, в Китае, началось массовое распознавание и блокирование TLS-прокси. Из некоторых обсуждений и внутренней информации мы узнали, что цензоры использовали огромные ресурсы и методы машинного обучения. Как известно, сильная сторона машинного обучения - извлечение статистических характеристик из больших объемов данных.

Одним из важных недостатков обычного TLS-прокси является 'шифрование в шифровании'. Как обсуждалось выше, хотя внешний вид зашифрованных пакетов неотличим для цензора, неизбежным является увеличение заголовка каждого пакета с каждым уровнем шифрования. Это увеличение может быть незначительным, но для маленьких данных (например, пакетов ответов) оно может быть более заметным, и некоторые пакеты могут превышать ограничения MTU сетевого уровня. Самое важное - каждый пакет увеличивается на одинаковую длину, что может создавать определенные статистические характеристики.

XTLS изначально был разработан , чтобы уменьшить дополнительное шифрование.
Новый потоковый контроль Vision был введен, потому что XTLS обладает уникальной способностью противостоять цензуре. Можно сказать, что когда передаются данные TLS 1.3, 99% пакетов XTLS имеют почти идеальные характеристики трафика, потому что это оригинальные данные, не обработанные прокси.

TLS в TLS

Почему мы говорим, что 99% пакетов являются оригинальными данными? Что представляют собой оставшиеся 1%? Нам нужно исследовать, что происходит в типичном прокси при встрече с трафиком TLS 1.3 в первых нескольких пакетах.

Наглядно, после установления зашифрованного канала:

1. Первый пакет: Прокси-клиент -> Прокси-сервер: "Привет, цель этого прокси-сессии - Google, вот мой UUID."
2. Второй пакет: Прокси-клиент <- Прокси-сервер: "Привет, получил твой запрос на прокси, начинай отправлять данные."
3. Третий пакет: Браузер -> Прокси-клиент -> Прокси-сервер -> Google: "Привет, Google, я собираюсь начать с тобой зашифрованное общение, вот мои поддерживаемые методы шифрования..." (Этот пакет также называется TLS Client Hello).
4. Четвертый пакет: Браузер <- Прокси-клиент <- Прокси-сервер <- Google: "Привет, пользователь, вот сертификат Google, мы будем использовать шифрование TLS_AES_128_GCM_SHA256, давай начнем зашифрованное общение!" (Этот пакет также называется TLS Server Hello).
5. Пятый пакет: Браузер -> Прокси-клиент -> Прокси-сервер -> Google: "Понял, давай начнем зашифрованное общение!"

Как вы знаете, протоколы прокси разнообразны, но основа одна и та же: если пользователь использует любое TLS-соединение, необходимо выполнить вышеупомянутый процесс рукопожатия. Как упоминалось ранее, внешнее TLS-шифрование можно считать абсолютно безопасным, но для цензора, помимо взлома информации, есть возможность использовать некоторые дополнительные данные для идентификации этих пяти пакетов.

Это ключевые моменты обнаружения TLS в TLS."

Пять пакетов

Самой очевидной характеристикой этих пяти пакетов является их длина. В частности:

1. Первый пакет: очень короткий, единственная переменная - целевой адрес.
2. Второй пакет: очень короткий, почти фиксированный.
3. Третий пакет: короткий, с небольшими изменениями, почти единственная переменная - целевой SNI.
4. Четвертый пакет: длинный, с большими изменениями.
5. Пятый пакет: очень короткий, с небольшими изменениями.

Можно интуитивно почувствовать, что характеристики длины этих пакетов довольно очевидны. В Vision подход к решению этой проблемы также прост: мы увеличиваем длину каждого короткого пакета до диапазона от 900 до 1400. Обратите внимание, что этот метод отличается от традиционного случайного заполнения; мы не просто добавляем заполнение ко всем пакетам, а основываясь на нашем анализе внутреннего трафика, целенаправленно заполняем характерные пакеты TLS-рукопожатия.

Другой менее заметной характеристикой является временная последовательность. Из-за дизайна TLS-рукопожатия можно заметить, что порядок первых нескольких пакетов фиксирован. То есть, после отправки браузером TLS Client Hello, он должен дождаться ответа Google с TLS Server Hello, после чего браузер должен отправить сообщение "Понял, давай начнем зашифрованное общение!", чтобы диалог мог продолжаться.

Если обозначить пакеты, идущие от пользователя к серверу, как C, а в обратном направлении - как S, может ли цензор определить TLS в TLS соединение по временной последовательности данных CSCSC и их временным интервалам?
пока недостаточно оснований для таких выводов, и Vision не обрабатывает этот аспект."

Часто задаваемые вопросы

1. Длина заполнения в Vision зафиксирована, не создает ли это статистические характеристики?

В первую очередь, в концепции сетевой безопасности нет абсолютной безопасности, теоретически любое шифрование можно взломать силой, это лишь вопрос вычислительных ресурсов. Как разработчики безопасных протоколов, наша задача - повысить сложность взлома и обнаружения до уровня, недостижимого для цензоров. Насколько высок этот уровень? Это мы узнаем в ходе борьбы.

Возвращаясь к известным нам данным, длина пакетов рукопожатия TLS 1.2 и 1.3 довольно стабильна. Несколько ключевых пакетов, посещающих основные сайты (например, Google), можно считать фиксированной длины. Если сравнить текущую длину больших пакетов Vision с длиной незаполненных рукопожатий, сложность обнаружения, вероятно, увеличится на порядок.

Кроме того, в некоторых утечках обсуждений упоминалось, что машинное обучение может распознавать случайное заполнение менее 40%. Это косвенно подтверждает наличие предела распознавания у машинного обучения."

2. Почему новый потоковый контроль назван Vision?

Ответ: Мы считаем, что Vision отражает первоначальную концепцию дизайна RPRX. XTLS первоначально разрабатывался в процессе исследования и был ограничен тогдашними условиями разработки, что делало некоторые аспекты слишком сложными. Таким образом, Vision представляет идеальное состояние и будущее направление XTLS. RPRX говорит:
"Flow.. Какую проблему он решает? Он влияет на макроскопические временные характеристики трафика, а не на микроскопические, которые являются задачей шифрования. Временные характеристики трафика могут быть вызваны протоколом, например, Socks5 over TLS с рукопожатием Socks5, разные характеристики на уровне TLS означают разные протоколы для наблюдателя, таким образом, бесконечные планировщики (Schedulers) эквивалентны бесконечному количеству протоколов (перераспределение объема данных для каждой отправки и т.д.)"

3. Этот новый потоковый контроль так хорош, рекомендуете ли вы всем использовать его для обхода блокировок?

Ответ: Как говорят другие разработчики, для текущих цензоров опасно класть все яйца в одну корзину. Поэтому мы рекомендуем активно использовать особенности каждого инструмента и разнообразить ваш набор инструментов."