来源: https://habr.com/ru/articles/1019200/
“
Telegram 绕过了 Roskomnadzor 的代理封锁 ” 、“该即时通讯团队修复了 ClientHello 中的一个漏洞 ” 、“数字抵抗回来了——开发者发布了修复程序！”
剧透：Telegram 官方团队对此完全无动于衷 ，直到热心人士向他们提供了一套完整的解决方案，详细到每一个字节。事情经过是这样的。
三个月的沉默
关于TSPU将接管Telegram代理的传闻早在2026年初就已开始流传。官方团队至少有三个月的时间来审核他们的MTProxy实现。而代码mtproto_tls_socket.cpp 自2025年11月以来就一直处于未更改的状态。
Telegram 团队一直在等待，4 月 1 日，TSPU 终止了服务。内置的 FakeTLS 伪装功能对俄罗斯的大多数用户都失效了。代理服务器崩溃，连接超时。
Telegram 的回应？沉默。
实际接手这份工作的人是谁？
在媒体等待“官方更新”之际， Telemt 代理社区的成员们决定自行采取行动，戴上手套，开始分析泄露的文件。
诊断算法极其简单：
我们拦截了真实 Chrome 浏览器的 TLS 握手包，TSPU 允许其通过。我们也拦截了 Telegram 的握手包，但该握手包被拦截了。我们逐个 修改数据包字段，并在实际网络上进行测试。当 Telegram 数据包不再被拦截而浏览器数据包开始被丢弃时，该字段就包含了签名。
一天后，事情真相大白。我们找到了特定的字节，fork 了桌面客户端，并在两个网络服务提供商上与整个社区进行了测试——结果成功了。我故意不透露测试细节——我不想让那些配置过滤器的人更容易下手。
令人尴尬的“伪装”
FakeTLS 试图伪装成普通的 HTTPS 流量。这样，深度包检测 (DPI) 就会检查数据包，然后判断“哦，只是 Vasyan 在访问网站——我们放行吧”。
Telegram 发送了什么？
错误 1 - 扩展标识符不存在：
- S("\xfe\x02"_q);
+ S("\xfe\x0d"_q);
0xFE02 — 是过时的草稿垃圾，2026 年任何真正的浏览器中都不会出现。—0xFE0D 是 IANA 加密客户端 Hello (ECH) 的标准代码点，现在已被 Cloudflare 等公司广泛使用。多年来，Telegram 一直在发送带有幽灵标识符的扩展程序，并称之为“伪装成浏览器”。
错误 2 - 数学上不正确的软件包：
- S("\x00\x20"_q); //声明 32 字节
- R(20); //生成了20 ，不匹配
+ R(32) //现在匹配了
这个字段是 X25519 公钥，根据规范，它始终占用 32 字节（256 位）。但代码生成的却是 20 字节而不是 32 字节。对于深度包检测 (DPI) 来说，这只是一个微不足道的异常：真正的客户端绝不会发送长度错误的 X25519 密钥——这在物理上是不可能的。Telegram 发送了一个数学上无效的数据包，却称之为伪装。
窃取荣誉
社区在 Pull Request #30513中记录了他们的发现，详细说明了需要更改的内容、原因以及在俄罗斯实际网络上的测试结果。该 PR 在官方团队查看之前已在社区内部进行了审查。这个问题曾在 tdlib 聊天中多次被提出，但 TG 开发人员对此置之不理。
Telegram Desktop 的回应是：维护者提交了一个代码，407bf19 并附言*“修复客户端 Hello 生成的部分问题。灵感来自广泛的网络讨论和 #30513* ”。他们从 PR 中选取了最少的更改进行合并，第二天，各大媒体纷纷报道 Telegram 战胜了审查制度。新闻稿中只字未提社区。
今日讽刺：john-preston tdesktop 的维护者本人在 PR 讨论串中确认，tdlib 的 ClientHello 中存在同样的 bug 。没错0xFE02 ，就是同样的 bug，只是大小从 32 字节变成了 20 字节。这意味着 iOS 客户端、Android 客户端以及所有使用 tdlib 编写的库的检测方式仍然完全相同。桌面版已经收到补丁，其他版本还在等待。
随后，杜罗夫本人也发了一篇帖子。帖子内容涉及约6500万俄罗斯用户，探讨了因网络封锁导致的银行系统崩溃，以及“数字抵抗”——总而言之，这是一篇精彩的文章。结尾的关键语句是：“我们将继续调整策略，让Telegram的流量更难被检测和封锁 。 ”
“站在我们这边。”我们会适应……我们！！
兄弟，你们这边 一直什么都没做，直到社区给你们送来一份现成的 PR，里面有字节流、测试用例和简洁明了的解释。“我们这边”指的是聊天室里那些匿名分析十六进制转储文件的家伙们，而你们却沉默了三个月。不过说实话，你们从 2018 年就一直保持沉默！
市场营销十分，工程技术零分。
这只是个权宜之计，并非根本解决方案。
目前只修改了最基本的部分，仅此而已。FakeTLS 实现中检测到的签名图谱远比修改后的两行代码要长得多：
| 问题 | 严肃 |
|---|---|
| 填充目标 = 正好 513 字节 → 整个 ClientHello 的固定长度 |  关键 |
| 在整个应用生命周期内长度固定的 ECH 有效载荷（单例） | 关键 |
使用旧版代码点的 ALPS 扩展（0x44CD 截至0x4469 Chrome 115 版本） |
 高 |
Darwin 分支（#if TD_DARWIN ）包含 TLS 1.2 时代的密码套件，这些套件已于 2021 年被 Apple 移除。 |
高 |
| 无抖动的均匀数据包间时间间隔在统计上是异常的。 | 高 |
| 固定TLS记录大小（1380/4096/16384）- 机械式 |  平均值 |
握手完成后，ALPN 声明h2/http/1.1 ，但原始 MTProto 却显示为 |
关键（单独音轨） |
最后一点则完全是另一回事。Telegram 在握手过程中声明“我使用 HTTP/2”，但随后在 TLS 隧道内运行的是裸露的 MTProto 协议，没有任何 HTTP 帧封装。对于高级 L7 分析而言，这是一个独特的行为特征，任何 JA3/JA4 整形都无法掩盖。
现代TLS系统不仅仅依赖于静态字节模式，还依赖于机器学习（ML）分类：数据包之间的时间间隔、记录大小分布、流行为和连接集中度。该系统的预算超过840亿卢布 。静态TLS握手显然无法满足这种需求。
接下来是什么？
当媒体还在欢呼雀跃时， Telemt 社区已经在着手设计一个基础解决方案——面向 tdlib，这意味着它能同时支持所有平台。该方案将具备动态浏览器配置文件（Chrome、Firefox、Safari、Edge）、连接熵、时间整形和路由感知策略等特性。此外，它还将针对真实的 pcap 数据包进行全面测试，并在三个不同的运营商网络（而不仅仅是两条线路）上进行验证。
真正的“数字抵抗”并非帕维尔在 Telegram 频道上的那些高调言论，而是那些在夜间暗中破坏 DPI 规则，并为那些因此获得报酬和晋升的人编写补丁的匿名工程师。
然而，一位社区成员的说法比任何新闻稿都更准确：
“社区并非在反抗审查，而是为了继续使用这款便捷的通讯工具。数百万普通用户通过它发送小猫和鲜花的照片，在聊天室里讨论谁破坏了电梯，以及解决工作上的问题。我们的父母、祖父母在聊天室里发送明信片，他们并非挥舞着数字抵抗旗帜的反对派。他们只是普通人。而且，他们占Telegram用户的99.9%。”
根本没有什么“抵抗万岁”。人们只是想用Messenger而已。而其他人已经帮他们解决了这个问题——与此同时，公司却忙着写漂亮的广告文案。
更新：今天，社区将尝试提供一个 iOS 补丁。 补丁已经准备就绪：TLS Fingerprint generation fixes in MTProtoKit ClientHello by magical-Magic-me · Pull Request #2089 · TelegramMessenger/Telegram-iOS · GitHub
更新于2026年4月5日莫斯科时间17:16。开发人员整理了一张表格，显示了与EE（FakeTLS）相关的首批公开修复程序的实施状态：
| 平台 | 地位 | 版本 | 发布日期 | 拉取请求 |
|---|---|---|---|---|
| windows | 已修复 |
6.7.2 | 2026年4月3日 | #30513 |
| MacOS（桌面版） | 已修复 |
6.7.2 | 2026年4月3日 | #30513 |
| MacOS（原生） | ？ | ？ | ？ | ？ |
| Linux | 已修复 |
6.7.2 | 2026年4月3日 | #30513 |
| Android（直接发布+ Google Play 发布） | 已修复 |
12.6.4 | 2026年4月7日 | #1949（提交） |
| iOS | 已修复 |
12.6.2 (32737) 查看版本：在 Telegram 设置中点击齿轮图标 10 次，然后向下滚动。 | 2026年4月8日 | #2089 |
PS：如果您从事底层 C++ 开发、网络安全方面的工作，或者只是想贡献一些真正有用的东西，不妨看看 Telemt 社区。那里有一些值得您参与的任务。