Telegram正在测试阻止绕过的新版本-在普通TLS（https）下屏蔽流量。
背景：阻止电报的尝试发生在不同的国家，第一个阻止选项很简单-阻止电报服务器的IP地址。
Telegram成功地抵御了这种攻击，定期更改了其可用的IP，但这会导致很长的初始连接...
袜子代理服务器在稍后出现，但是协议并不意味着加密，因此可以简单地在袜子隧道内部“看”，确定Telegram在其中，从而阻止了代理服务器。
下一轮发布是使用其MTProto协议的电报代理服务器MTProto Proxy，但它也存在一些问题-数据包大小非常有特色且特定，并且许多DPI在第一个数据包后开始确定电报-阻止访问。
对此问题的答案是引入了新版本的MTProto协议-长度随机，现在更难确定Telegram隧道在我们面前，DPI的一部分开始将流量分类为“另一”部分，但仍学会了识别特征模式，并且有一定的可能性（不是100％）确定流量与电报有关
现在，我们进入下一个阶段（似乎是最终阶段或预决赛）-
隐写术 。
隐写术 （源自希腊语。“隐藏” +γράφω“我写”；字母：“秘密写”）-考虑到此类转移（存储）事实的机密性，一种传输或存储信息的方法。
换句话说，Telegram现在将假装为常规TLS（https）流量。
为什么要假装？
答案在于表面-当前，大多数流量是TLS（https），使用此协议时，这是您的提供商或DPI将看到的内容：
- 您的IP
- IP服务器
- 连接域（URL不会显示）
此外，为了将其删除，正在进行最后一项的工作，除了两个IP外，还有一条加密的隧道，内容未知。
在这种情况下，所有非标准协议都开始引起更多关注，并且解决此问题的方法是一回事-如果您看起来像TLS（https），那么问题就更少了。
技术实施
使用新协议时，MTProto流被包装在标准HTTPS（第一条隧道协商消息）中，在该HTTPS中传输域（伪造）。 协商MTProto协议后，不使用Fake-TLS，然后流量开始使用具有随机长度（dd键）的常规MTProto协议。
供参考：Telegram为MTProto代理使用3种密钥：
- 常规密钥（由DPI轻松确定）
- 前两个字母-dd-随机消息长度（DPI只能通过第一个连接协商数据包来确定协议-看起来像普通的https / TLS）
- 前两个字母-ee-伪TLS +随机消息长度（DPI无法确定协议，第一个消息以及所有后续消息看起来像HTTPS / TLS）
在哪里尝试？
已经有两个支持新标准的
代理服务器（尽管很早以前就添加了对dd键的支持，但仍然没有正式的代理服务器）支持假TLS代理模式：
- Python github.com/alexbers/mtprotoproxy
- Erlang github.com/seriyps/mtproto_proxy/tree/fake-tls
请注意：在撰写本文时，虚假的tls功能是实验性的，因此您需要使用软件的Beta版或Alpha版（代理和客户端）哪些客户端支持新模式？
Beta版的Telegram桌面版，Telegram iOS以及Android上的稳定版。
怎么尝试？
- 例如，我们将在Python中使用代理：
- 安装代理：
git clone https://github.com/alexbers/mtprotoproxy.git; cd mtprotoproxy
- :
python3 mtprotoproxy.py
- (experimental) — :
tg: tg://proxy?server=8.8.8.8&port=443&secret=7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t (experimental)
- — , Fake TLS.
?
Google.com , DPI HTTPS Google.com IP — , , .
! (IP) Google.com
Fake TLS — ?
— HTTPS DPI :
- IP
( eSNI).Fake TLS , , , Google - Google — , , - - Google HTTPS/TLS .
?
, — — ( ). , HTTPS . ? — , .
— + () — , — MTProto.
eSNI ( ) — .
?
, Telegram , https/TLS WebSocket — .
MTProto — , Telegram — .
, — () , .
— 443 ( HTTPS) ( dd ee), ee dd , .
— , eSNI — .