tg-ws-proxy-android 安全边界完整解析FakeTLS、密钥管理与代理隐私的取舍【免费下载链接】tg-ws-proxy-androidAndroid-форк популярного приложения Flowseal - tg-ws-proxy - локальный прокси-сервер MTProto с проксированием CF или без для частичного обхода проблем загрузки Telegram项目地址: https://gitcode.com/gh_mirrors/tg/tg-ws-proxy-androidtg-ws-proxy-android是一款运行在 Android 手机上的本地MTProto 代理即 tg-ws-proxy 的 Android 分支它在127.0.0.1:1443监听 Telegram 的连接再把流量通过 Cloudflare WebSocket 或直连 Telegram 数据中心转发出去。本文不追求全部讲完只聚焦三个新手最容易忽略的安全问题——FakeTLS 握手伪装、32 位密钥管理、以及代理隐私上的真实取舍帮你判断这个代理在你手上到底漏不漏水。一、先看全局安全边界到底在哪一层很多人以为开了代理 流量就安全了。实际上 tg-ws-proxy-android 的加密只覆盖两个特定区段其余环节各有关键词级的取舍。用一张表看清链路区段是否加密依赖什么说明Telegram 客户端 → 手机本地 1443 端口⚠️ 半加密MTProto 本地密钥只在本机回环上不经过 Wi-Fi 网络本地代理 → Cloudflare / Telegram DC✅ TLS WebSocketsrc/ws.rs 的原始 TLS 栈数据在公网上的运输段日志与调试输出✅ 脱敏域名掩码过滤器防止代理域名泄漏到截屏和 Issue 里关键源码位置供想深入的读者客户端接入与密钥校验src/proxy.rs上行/下行 WebSocket 连接src/ws.rsAES-256-CTR 流密码与 MTProto 分包src/crypto.rs 一句话结论它不是全程匿名代理而是一个把风险压缩到本机回环 公共 CDN的实用主义方案。下面逐层拆解。二、FakeTLS 工作原理第一个字节就定生死2.1 为什么需要假 TLS当代理流量要借道 Cloudflare 时网络侧只看得到某个域名 一次 TLS 握手。tg-ws-proxy-android 支持FakeTLS源码中的ee密钥模式代理在监听端口上假装自己是一台 TLS 服务器让流量伪装成对某个普通网站 HTTPS 访问的样子从而降低被按特征识别的概率。2.2 握手分叉点0x16 与 301 重定向接入逻辑非常直白见 src/proxy.rs代理开启 FakeTLS 域后会先只读客户端发来的第一个字节若首字节是0x16标准 TLS 握手记录头进入faketls::server_handshake按约定密钥完成伪 TLS 协商随后进入正常业务桥接若是任何其他字节比如有人在浏览器里访问了这个端口代理返回HTTP 301 Moved Permanently把访问者重定向到https://{伪装域名}/。第 3 步是个精妙的安全边界设计误连进来的普通用户看到的是你配置的那个域名而不是任何与代理相关的信息——端口暴露时不会自曝身份。三、密钥管理32 位十六进制密钥与 dd / ee 前缀3.1 默认密钥是最大的风险点本地 MTProto 接入靠一个32 位十六进制密钥做身份匹配它存储在运行期内存RwLock中不落盘密钥定义与校验src/config.rs、src/lib.rs⚠️注意默认值若从未设置过密钥初始值是0000000000000000000000000000000032 个 0。由于本地端口理论上只对本机应用可见风险有限但一旦你做过端口转发、或用同一台设备跑过多套实验环境全 0 密钥意味着任何同机进程都能借用你的代理。建议在应用内应用密钥流程中确认使用了自行生成的随机密钥。3.2 一个密钥两种方言dd 与 ee调用 GetSecretWithPrefix 可以看到同一个密钥会按模式生成两种接入串前缀模式格式dd普通直连模式dd 32 位密钥eeFakeTLS 模式ee 32 位密钥 伪装域名的逐字节十六进制ee后缀里多出的域名十六进制不是装饰——它把伪装域名作为协商参数绑进密钥串本身客户端与代理必须对同一域名达成一致才能建立会话。这也解释了改伪装域名后必须同步更新 Telegram 侧的接入密钥否则握手会直接失败。四、隐私取舍证书验证关闭、SNI 伪装与日志脱敏这是全文最重要的知情同意部分。tg-ws-proxy-android 为了可用性能穿过各种网络限制主动放弃了部分机密性与完整性三处取舍如下。4.1 关闭上游证书验证InsecureSkipVerifysrc/ws.rs 中注册了一个NoVerify证书校验器对任意证书直接返回验证通过并配套 100 个会话的 TLS 会话复用缓存。收益连接不受证书链异常影响配合伪装域名更稳代价理论上可被中间人替换证书而不被发现。由于 MTProto 自身还有一层会话密钥加密且流量经由 Cloudflare实际威胁窗口有限——但请理解这是有意识的设计取舍而不是疏漏。4.2 SNI 伪装Fronting连接池在直连失败时会自动尝试frontingTLS 握手中声明的 SNI 是一个无关域名常量FRONTING_SNI见 src/config.rs实际数据走另一个目的。尝试逻辑在 src/ws.rs。收益按 SNI 封锁的策略下更容易通过代价SNI 与真实目的地不一致流量分析者若拿到完整包可据此识别代理特征。隐蔽性换来了可发现性这是所有 fronting 方案的通病。4.3 日志域名脱敏一个容易被忽略的细节src/config.rs 实现了域名掩码过滤器日志与报错里的代理域名会被自动打码如xx***.com但telegram.org与.log结尾的 token 除外便于排障。这条机制直接服务代理隐私——项目鼓励用户把日志附在 Issue 里脱敏保证你的代理域名不会随截图、崩溃报告、工单外泄。对新手而言这比任何单点加密都更实际地保护了你用了什么代理这一元信息。五、给你的 3 条实操建议别用默认全 0 密钥启动代理后先确认应用生成的随机密钥已同步到 Telegram 客户端应用到 Telegram一键流程改伪装域名 必须换ee密钥串ee模式把域名编码进密钥两处不同步会表现为连不上/立刻断线日志可以大胆贴但先确认版本域名脱敏是内置的但若你手动导出过旧日志脱敏前的运行外发前请自查其中的域名。六、总结一张表看懂取舍关注点本项目做法隐私收益主要代价本机接入回环端口 32 位密钥不经过局域网密钥若为默认值则无鉴权强度上游传输TLS WebSocket验证关闭公网段仍被 CDN 加密证书可被中间人替换流量特征FakeTLS SNI fronting按 SNI 封锁时可用深度包分析下可被识别元信息日志域名自动脱敏防止域名随报告外泄需人工留意旧日志底线判断tg-ws-proxy-android 的安全模型是用工程手段把暴露面压到最小同时明确告诉你哪里没做。只要你不把它当成匿名工具它不隐藏你的 Telegram 身份并保持密钥非默认这套设计在让 Telegram 在受限网络里稳定工作这个目标上是相当克制且自洽的。【免费下载链接】tg-ws-proxy-androidAndroid-форк популярного приложения Flowseal - tg-ws-proxy - локальный прокси-сервер MTProto с проксированием CF или без для частичного обхода проблем загрузки Telegram项目地址: https://gitcode.com/gh_mirrors/tg/tg-ws-proxy-android创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考