一些实锤证据，GFW会如何中间人攻击悄悄解密你的流量 #5
Description
有位ytber近期在分析积至泄密的相关文件和代码。
天狗安全网关（TSG），是方滨兴的积至公司把GFW成果商用转化并对外输出的主打产品。
本文内容来自：
知识噪音 | GFW中间人窃听 —— 从HTTPS知识和天狗前端引擎代码，谈GFW的中间人窃听
声明：
本视频内容不代表社区、任何开发者或本人的任何立场。本次讨论与该 YouTuber 的其他视频及其观点无关，内容仅供参考，不构成建议或结论，请自行判断。
视频大致内容总结：
天狗（TSG）如何进行中间人攻击
1. 流量分析 → 判断是否可解密
从现有的代码来看， 天狗预载了tls-ca-bundle.pem中的公钥用于判断当前流量是否可以进行解密。 其判断的逻辑在TFW的ssl-policy文件夹中。 从文件的第282行开始决定了当前SSL流量是否要被解密。 判断的主逻辑则出现在325行。 这个判断是按照优先级依次进行的。 如果命中任何一个，那么天狗都将放弃解密当前流量。 如果全部通过则会开始证书替换解密流量。
天狗会根据规则判断某条 TLS 流量是否可被 MITM，代码在这
依据包括：
- 1.是否存在 证书锁定（Pinning）
- 2.是否使用 客户端证书（双向 TLS）
- 3.是否为 EV 证书
- 4.是否启用 CT（证书透明度）
- 5.协议是否异常
- 全部为否则可进行解密
在默认配置下：
- Pinning / client-auth → 放弃解密
- CT / EV 存在 → 仍尝试解密
2. 伪造证书链（中间人阶段）
概念上流程如下：
-
浏览器发起 TLS 握手
-
天狗拦截并判断可否 MITM
-
若可 MITM：
- 生成与原站域名一致的“伪造证书”（使用自身掌握私钥的根或中间证书）
- 将其发给客户端
-
客户端因信任链成立（系统信任的根证书）而不告警
-
天狗与服务器建立真实 TLS 会话
-
天狗位于两端之间实现：
- 解密流量
- 检查内容
- 再加密发出
其根本依赖：
- 被系统信任的不可信机构控制的根证书
- 泄密文件提到的"互通互认证书"（相关机构企业上交）
- 伪造证书的动态生成
- 浏览器将系统证书视为可信，不强制 SCT 检查
3. 绕过证书透明度（CT）的方法
根据描述，天狗可能利用以下情况：
- 系统层预装的证书不被 Chrome Root Store 的 SCT 强制要求影响
- 老旧根证书（2018年前）可做证书回溯，不要求 SCT
- 动态 MITM 不会在公网 CT 日志中留下记录
因此，在部分场景中：
- 没有 Pinning
- 系统中存在被信任的旧根证书
- 绕过CT
→ MITM 能够无告警完成。
积至测试人员进行了详尽的测试，在什么条件下不会触发告警。
Xray用户如何避免MITM
1. 传输方式使用REALITY的情况
-
REALITY 公钥自动锁定（Pinning），不接受任何中间人生成的伪造证书。
-
无需依赖公共 CA
REALITY 的验证不依赖系统的 Root CA，所以不存在 CA 被利用的风险。
2. 传输层安全使用TLS的情况
二选一
-
1.证书 Pinning，文档在这
Pinning 让客户端校验证书sha256，明确“只接受某个特定公钥/证书”。 -
2.开启ECH，echForceQuery选full
目前仅Cloudflare支持。
3. 过CDN或传输层安全无法保证的情况下
4. 清除系统中不可信的CA
- 还记得当年的RevokeChinaCerts吗。
彩蛋：shadowsocks流量解析还原模块调研报告 来自"中国科学院信息工程研究所"
可能是小学二年级暑假作业吧
一些吐槽：
1.不妨想想，积至是GFW外围吧，真正的国家队会没有这些么？
功能都开发完了，上线了，还有理由认为不会用吗？还是说已经在用了
2.本来在net4那边讨论的挺好，结果被几个小号搅浑水给搞乱了
同个话题再发，怕是被认为是捣乱不给面子，所以还是发这里吧。