XTLS Vision, fixes TLS in TLS, to the star and beyond #1295
Replies: 61 comments 101 replies
-
|
旧版 XTLS 的 233 主动探测并不存在，说明详见 XTLS/Go#17 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
太强了，辛苦 |
Beta Was this translation helpful? Give feedback.
-
|
辛苦💦 |
Beta Was this translation helpful? Give feedback.
-
|
必须顶 |
Beta Was this translation helpful? Give feedback.
-
|
青山不改 绿水长流 愿你归来仍是少年. |
Beta Was this translation helpful? Give feedback.
-
|
写得太好了, 都看哭了... 哎呀我竟然看一篇技术文章看哭了... |
Beta Was this translation helpful? Give feedback.
-
|
最后一句泪目。 |
Beta Was this translation helpful? Give feedback.
-
|
感谢 @RPRX |
Beta Was this translation helpful? Give feedback.
-
|
他回来了 |
Beta Was this translation helpful? Give feedback.
-
|
他已如閃電般歸來（ |
Beta Was this translation helpful? Give feedback.
-
|
R佬如闪电般归来 |
Beta Was this translation helpful? Give feedback.
-
|
解释的相当通俗，让我这种TLS小白也能看的津津有味。 |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Thanks. Done! https://github.com/seakfind/examples/blob/main/xtls-vision/README.md |
Beta Was this translation helpful? Give feedback.
-
|
致敬各位开发者、维护者以及RPRX，你们的无私付出让我更加了解世界！ |
Beta Was this translation helpful? Give feedback.
-
|
非常棒，尤其是当我读到“翻墙技术战争”的时候，这四个字完全可以用“较量”“切磋”这么LOW的！这充分反映了我们所处的时代境况。 |
Beta Was this translation helpful? Give feedback.
-
|
非常感谢！非常感谢！ |
Beta Was this translation helpful? Give feedback.
-
|
对你们这群开发者，我只有敬仰。不仅仅是你们的程序开发太棒，而是你们的思想。在严酷的环境下，帮助受困的人群。不亚于在二战时期，那些帮助纳粹控制区的犹太人逃出生天的勇士。希望有一天历史能写上你们的名字，一群为中国网民提供自由而奋斗的勇士。 |
Beta Was this translation helpful? Give feedback.
-
|
粉红就收收味吧，你自己愿意给自己栓上锁链，这是你的自由，但是你不能让别人都栓上，搞清楚自己是个什么定位，来GitHub展示你的党性原则性和你所谓的觉悟就有点搞笑了，如果喜欢内循环可以回Gitee |
Beta Was this translation helpful? Give feedback.
-
我宁可相信世界上有鬼，疫情都开放了，人也死不少了，这玩意也没松懈反而愈演愈烈，出发点哪有你想的那么简单，肯定有比疫情死人更让其在意的理由才会如此，像你所说就是为了让大家免受垃圾、虚假信息伤害？现在连人口都不得不放弃一部分了，为了提高出生率放开点社会情欲都没啥大不了的情况下，孰轻孰重谁心里没点数呢？很多事得自己根据实际情况去分析和感受，你分析出来得才是你能相信的，剩下谁说啥也别信。 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
又被邮件给刷屏了，我也说了，其实这位老哥没必要去争执“墙的意义”之类的话题，因为墙的初衷是以保护大众和政府为了掌控媒体来避免国内过度"资化"思想发展的工具，但它不可能永远是为这个目的的，一切都会随时间变质，就好比国内的贪腐，最开始的国家垄断制盐命脉是为了人民的生活，但后来却变质出了"官员倒卖"这种丑闻，这种垄断却危害了人民，这就需要有东西来制衡它，所以墙可以有，但翻墙也同样得有 |
Beta Was this translation helpful? Give feedback.
-
又被邮件给刷屏了，我也说了，其实这位老哥没必要去争执“墙的意义”之类的话题，因为墙的初衷是以保护大众和政府为了掌控媒体来避免国内过度"资化"思想发展的工具，但它不可能永远是为这个目的的，一切都会随时间变质，就好比国内的贪腐，最开始的国家垄断制盐命脉是为了人民的生活，但后来却变质出了"官员倒卖"这种丑闻，这种垄断却危害了人民，这就需要有东西来制衡它，所以墙可以有，但翻墙也同样得有 |
Beta Was this translation helpful? Give feedback.
-
|
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: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
根据这个的说法，目前检测主要是根据tls建立连接时几个握手包的长度来识别的，并且vision也是为了解决这个握手包长度特征开发的。 但是这无法解释之前许多人遇到的电脑连接没有事，手机一连接vpn就会被封端口的现象。毕竟在这个握手包的问题上电脑和手机应该是一视同仁的。反而是之前某截图中所说的通过检测aes加密的硬件加速特征，发现流量同时有手机cpu和电脑cpu硬件加速的特征就认为这是一个与翻墙相关的流量更能解释这个现象。 并且我自己将tlsSetting中的cipher Suite改成chacha20后确实没有再被封过端口。为了验证是否放松了，我又把chacha20关掉后重新做了个阳性对照，第二天那端口就没了。当然虽然这做法有效，但是我用wireshark抓包后发现跟代理服务器建立连接时使用的还是aes-128加密。但这确确实实让我没有再被封过端口了。这个cipher Suite具体是怎么工作的可能还需要了解xray内核的大佬解释一下。 所以现在vision效果如何，有效吗？另外就是未来是否会将vision的配置方式改成类似以前xtls的xtlsSetting配置方法，还是说会一直保留目前的配置写在tlsSetting里的做法？ |
Beta Was this translation helpful? Give feedback.
-
|
感谢留言，审查者应当使用了多个系统/检测方法。 本次封锁一个明显的特征是针对 TLS，本文所详述的 TLS in TLS 也只是检测 TLS 代理的方法之一。另一个重要的特征是 TLS 客户端握手（外层），你提到的修改 cipher Suite 就是这个特征的一项。我的推荐是不需要手动修改这个配置，而是使用 v1.6.3 中 uTLS fingerprint 选项，它可以更加成熟的模拟常见浏览器或者生成随机握手。（正是由于简化代码架构带来的这些好处 Vision 的配置将保持使用 tlsSetting） 至于手机端连接会导致被墙这一现象，在其它地方已经有一些讨论了，我个人的猜测是由于手机端使用 VPN service 默认是全局代理，国产系统，国产应用会产生大量流量，其目标服务器是国内。审查者在国际出口部署的流量检测可以记录下两个反向 TCP 连接，通过这个信息发现了代理服务器。近期 @iceboy233 设计的一个有趣的实验验证了这一点。 |
Beta Was this translation helpful? Give feedback.
-
|
现在很多国产安卓系统都会主动上传流量统计数据和软件的流量使用数据，zf只要专门封杀v2rayN/ss等apk的出站和入站数据就很容易找出代理服务器 |
Beta Was this translation helpful? Give feedback.
-
|
手机连接vpn就封端口，可能是因为DNS泄露。电脑端使用sock5时，浏览器等应用不会进行DNS解析，而是全部交给代理工具处理。然而使用vpn方式时，各种应用会正常发送DNS请求。然而如果对墙外网站的DNS请求通过直连发出，就会产生非常明显的特征 |
Beta Was this translation helpful? Give feedback.
-
|
在路由器 放行 vivo的WiFi generate_204+屏蔽所有vivo域名 后，vivo手机会正常使用3-15分钟，之后整台手机断网。很不服气的是，监控用户上网就算了，居然还断网！是不是vivo倒闭了，全部vivo手机都不能使用了？ 注：有时断网变成了卡网，访问百度等均非常慢，网速快的10kB/s，慢的0kB/s。营造一种对方服务器不稳定的假象。 |
Beta Was this translation helpful? Give feedback.
-
|
我之前是用Nginx443反代vless+tls的方式，套cdn都秒封。这两天改成Nginx443直接反代vemss，没有开启tls，直接使用的Nginx的tls。没套cdn，已经正常运行了3天。 |
Beta Was this translation helpful? Give feedback.
-
缺省的指纹仍然是一样的，这也就是绝大多数， 同时我也没找到把两个指纹调成一样的办法。 |
Beta Was this translation helpful? Give feedback.
-
所以说，JARM 并不能直接导致 xray 被精确识别。因为配置文件每个人都会有很大的不同。 只能说，可以通过对网络上常见的一键脚本进行部署分析，获取这些一键脚本部署后的 JARM 指纹，然后对使用这些一键脚本的用户进行精确识别。我想，这个是可以做到的。 |
Beta Was this translation helpful? Give feedback.
-
xray的各类普通配置对应的指纹是一样的，你可以自行试试。大部分对配置文件的变化对指纹毫无影响。 |
Beta Was this translation helpful? Give feedback.
-
|
测试了快1个月，后期在良心云上也采用了这套方式，暂时幸存😁 |
Beta Was this translation helpful? Give feedback.
-
这个模式是哪种？nginx里面直接proxypass？backend 怎么指定的？ 我现在倒是各种模式都没被封锁，只不过有备无患多了解一种。 |
Beta Was this translation helpful? Give feedback.
-
|
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: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
一直在用vultr的机子，我只要开亚洲和美洲的 隔天就没 用的 vless nginx xtls utls开启 |
Beta Was this translation helpful? Give feedback.
-
|
vultr的好像不是cn2线路的，还和cn2的一样贵，可以找找别的机子 |
Beta Was this translation helpful? Give feedback.
-
来个aff，最好换ip不花钱 |
Beta Was this translation helpful? Give feedback.
-
|
Никогда не думал, что наше технологическое дерево будет выглядеть так |
Beta Was this translation helpful? Give feedback.
-
|
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]
|
Beta Was this translation helpful? Give feedback.
-
|
🙃 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]
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Hi,
TNX |
Beta Was this translation helpful? Give feedback.
-
|
Hi |
Beta Was this translation helpful? Give feedback.
-
|
As far as I am concerned，there is no IOS client support currently. |
Beta Was this translation helpful? Give feedback.
-
|
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]
|
Beta Was this translation helpful? Give feedback.
-
|
Can we have more than one client (UUID) with XTLS-VISION flow? |
Beta Was this translation helpful? Give feedback.
-
Of course you can. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Probably I'll go to investigate this soon. |
Beta Was this translation helpful? Give feedback.
-
|
很好，深入浅出，完全不懂计算机网络这些东西都能看明白。接下来就是按图索骥，摸索，学习了。 |
Beta Was this translation helpful? Give feedback.
-
|
با درود فراوان خدمت شما دوست عزیز و با تشکر. من یک مبتدی هستم. اگر امکان
دارد، مرا راهنمایی کنید، زیرا در ایران سانسور شدید است، مردم از گرسنگی :
حتی در سطل زباله ها دنبال غذا و خوراکی می گردند ، قوطی، شیشه، کارتن و امثال
اینها را جمع می کنند و آنرا می فروشند و حرفهای زیاد دیگر... معذرت می خواهم
از شما و خواهش من این است که 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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
میتوانید از کانال تلگرام زیر استفاده کنید. مختوا فارسی است به همراه آموزش. با بقیه ی دوستان و فامیل به اشتراک بگذارید. |
Beta Was this translation helpful? Give feedback.
-
|
@RPRX |
Beta Was this translation helpful? Give feedback.
-
|
和AI对抗，真是非常的Cyber呢 |
Beta Was this translation helpful? Give feedback.
-
|
燃是很燃，但是 tls in tls，和服务器 tls 握手后，vless 下应该只有三个包啊。uuid 是放在 client hello （文章所谓的第三个包） 里面的，不是单独发包。 |
Beta Was this translation helpful? Give feedback.
-
|
对，实际上只有三个包，VLESS header 和内层 TLS Client Hello 是粘一起发的，我给 @yuhan6665 说过， |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
如果开启了MUX.cool并且加上vision的填充，是不是就更加没有容易分辨的特征了？ |
Beta Was this translation helpful? Give feedback.
-
|
大流量协议似乎只有下载类的Torrent模式 |
Beta Was this translation helpful? Give feedback.
-
|
远程桌面也支持TLS1.3，套一个Reality可行吗 @yuhan6665 |
Beta Was this translation helpful? Give feedback.
![https://github.com/notifications/beacon/AKGBAYHU3YQRKVR7ZS2VFFLWHMHQNA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAHZZSK.gif]Message](https://github.com/notifications/beacon/AKGBAYHU3YQRKVR7ZS2VFFLWHMHQNA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAHZZSK.gif]Message){kind=link}
![https://github.com/notifications/beacon/AKGBAYGXZYMSHFTXVZ6NDMTWHUQ4BA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAH22HC.gif]Message](https://github.com/notifications/beacon/AKGBAYGXZYMSHFTXVZ6NDMTWHUQ4BA5CNFSM6AAAAAARSVRFZOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAH22HC.gif]Message){kind=link}
-
XTLSОсновная концепция XTLS:Основная логика XTLS заключается в использовании настоящего TLS для маскировки прокси-трафика среди самого обычного интернет-трафика. Вот краткая схема: Когда прокси-данные проходят через цензора, они фактически шифруются дважды. Однако, в этом процессе, 99% трафика на самом деле не требует дополнительного шифрования. Таким образом, логика прокси должна быть следующей:
Мы можем заметить, что:
Почти совершенноС 3 октября, в Китае, началось массовое распознавание и блокирование TLS-прокси. Из некоторых обсуждений и внутренней информации мы узнали, что цензоры использовали огромные ресурсы и методы машинного обучения. Как известно, сильная сторона машинного обучения - извлечение статистических характеристик из больших объемов данных. Одним из важных недостатков обычного TLS-прокси является 'шифрование в шифровании'. Как обсуждалось выше, хотя внешний вид зашифрованных пакетов неотличим для цензора, неизбежным является увеличение заголовка каждого пакета с каждым уровнем шифрования. Это увеличение может быть незначительным, но для маленьких данных (например, пакетов ответов) оно может быть более заметным, и некоторые пакеты могут превышать ограничения MTU сетевого уровня. Самое важное - каждый пакет увеличивается на одинаковую длину, что может создавать определенные статистические характеристики. XTLS изначально был разработан , чтобы уменьшить дополнительное шифрование. TLS в TLSПочему мы говорим, что 99% пакетов являются оригинальными данными? Что представляют собой оставшиеся 1%? Нам нужно исследовать, что происходит в типичном прокси при встрече с трафиком TLS 1.3 в первых нескольких пакетах. Наглядно, после установления зашифрованного канала:
Как вы знаете, протоколы прокси разнообразны, но основа одна и та же: если пользователь использует любое TLS-соединение, необходимо выполнить вышеупомянутый процесс рукопожатия. Как упоминалось ранее, внешнее TLS-шифрование можно считать абсолютно безопасным, но для цензора, помимо взлома информации, есть возможность использовать некоторые дополнительные данные для идентификации этих пяти пакетов. Это ключевые моменты обнаружения TLS в TLS." Пять пакетовСамой очевидной характеристикой этих пяти пакетов является их длина. В частности:
Можно интуитивно почувствовать, что характеристики длины этих пакетов довольно очевидны. В Vision подход к решению этой проблемы также прост: мы увеличиваем длину каждого короткого пакета до диапазона от 900 до 1400. Обратите внимание, что этот метод отличается от традиционного случайного заполнения; мы не просто добавляем заполнение ко всем пакетам, а основываясь на нашем анализе внутреннего трафика, целенаправленно заполняем характерные пакеты TLS-рукопожатия. Другой менее заметной характеристикой является временная последовательность. Из-за дизайна TLS-рукопожатия можно заметить, что порядок первых нескольких пакетов фиксирован. То есть, после отправки браузером TLS Client Hello, он должен дождаться ответа Google с TLS Server Hello, после чего браузер должен отправить сообщение "Понял, давай начнем зашифрованное общение!", чтобы диалог мог продолжаться. Если обозначить пакеты, идущие от пользователя к серверу, как C, а в обратном направлении - как S, может ли цензор определить TLS в TLS соединение по временной последовательности данных CSCSC и их временным интервалам? Часто задаваемые вопросы
В первую очередь, в концепции сетевой безопасности нет абсолютной безопасности, теоретически любое шифрование можно взломать силой, это лишь вопрос вычислительных ресурсов. Как разработчики безопасных протоколов, наша задача - повысить сложность взлома и обнаружения до уровня, недостижимого для цензоров. Насколько высок этот уровень? Это мы узнаем в ходе борьбы. Возвращаясь к известным нам данным, длина пакетов рукопожатия TLS 1.2 и 1.3 довольно стабильна. Несколько ключевых пакетов, посещающих основные сайты (например, Google), можно считать фиксированной длины. Если сравнить текущую длину больших пакетов Vision с длиной незаполненных рукопожатий, сложность обнаружения, вероятно, увеличится на порядок. Кроме того, в некоторых утечках обсуждений упоминалось, что машинное обучение может распознавать случайное заполнение менее 40%. Это косвенно подтверждает наличие предела распознавания у машинного обучения."
Ответ: Мы считаем, что Vision отражает первоначальную концепцию дизайна RPRX. XTLS первоначально разрабатывался в процессе исследования и был ограничен тогдашними условиями разработки, что делало некоторые аспекты слишком сложными. Таким образом, Vision представляет идеальное состояние и будущее направление XTLS. RPRX говорит:
Ответ: Как говорят другие разработчики, для текущих цензоров опасно класть все яйца в одну корзину. Поэтому мы рекомендуем активно использовать особенности каждого инструмента и разнообразить ваш набор инструментов." |
Beta Was this translation helpful? Give feedback.
and others
-
一、XTLS 深入浅出
XTLS 的核心逻辑在于使用真实的 TLS 将代理流量隐藏于互联网最常见的流量之中。
对于普通 TLS 代理协议（比如原版 Trojan），用户的代理客户端与代理服务器建立一个真实的 TLS 连接，通过这个加密的隧道，应用程序（比如浏览器）再与目标服务器（比如 Google）建立一个 TLS 连接。这时浏览器与 Google 服务器就是端对端加密，任何人（包括代理服务）不能解密或者伪装发送信息，这就是所谓的 e2e。
浏览器 ---- 代理客户端 ==== 代理服务器 ---- Google代理数据经过审查者的时候其实经过了2次加密，而 RPRX 敏锐的发现在这个过程中 99% 的流量其实是不需要做额外加密的。因为经过 TLS 1.3 加密的数据在外观上是完全一致的，审查者无法分辨。也就是说代理逻辑只需要：
这就是
xtls-rprx-vision我们可以发现
二、近乎完美
10月3日开始大规模识别和封锁 TLS 代理，透过一些相关讨论及内幕信息，我们知道审查者使用了海量资源以及机器学习的方法。众所周知，机器学习的特长在于从海量数据中提取统计学特征。
引用 klzgrad 的话，普通 TLS 代理的一个重要弱点就是加密套娃。上面讨论提及，虽然加密包的外观对于审查者无法分辨，但加密套娃无可避免的一点就是在每个包都会增加一个数据包头，加密层数越多，包头就会越重。
这个增量虽然不大，但对于小数据（比如应答包）可能比较明显，而且会有一些包长超过网络底层的 MTU 限制。最重要的，由于每个包都增加了相同长度，它可能具有某些统计学特征。
RPRX 当年发明 XTLS 主要原因是为了减少额外加密，我们现在推出新流控 Vision，则是因为 XTLS 在对抗审查者有独特的能力。可以说，当传输 TLS 1.3 数据时 XTLS 99% 的数据包，拥有几乎完美的流量特征。因为它是原始数据，没有经过任何代理加工。
三、TLS in TLS
为什么说 99% 的数据包都是原始数据？那 1% 究竟是什么？
我们需要继续探索一个典型的代理在遇到内部 TLS 1.3 流量的时候，最开始是几个包究竟在干什么。
形象的看，当加密通道建立以后：
你所知道的代理协议万变不离其宗，只要用户使用了任何 TLS 连接，都需要进行上述的握手过程。前面提到，外层 TLS 加密后可以认为是绝对安全的，但对于审查者而言，除了破解信息以外，还可以利用一些附加信息来识别这5个包。
这就是所谓 TLS in TLS 检测的关键点。
四、生死5包
最明显的特征，是这5个包的长度。其中
可以直观的感受到，它们的包长特征其实是十分明显的。在 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 说：
v2ray/v2ray-core#2636
XTLS/Go#12 (comment)
问：新流控这么好，你们推荐所有人都使用它翻墙吗
答：正如其它开发者所言，对于当前的审查者，把所有鸡蛋都放在一个篮子里是十分危险的。所以我们鼓励大家善用每个工具的特性，分散特征。
问：对于未来你推荐国密比如 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
青山不改 绿水长流 愿你归来仍是少年
Beta Was this translation helpful? Give feedback.
All reactions