扫描HTTPS加密流量会导致证书透明度（CT）机制失效

huangzihang

目前市面上绑定HTTPS扫描功能的反病毒软件（AV）和企业级防火墙（NG{过}F{滤}W），底层用的都是同一套技术——中间人解密。具体流程首先是连接劫持。当浏览器向目标服务器（比如google.com）发起TLS握手时，网络驱动层会拦截这个请求。接着进入上游代{过}{滤}理阶段：AV引擎以代{过}{滤}理身份，替浏览器去跟目标服务器完成握手，拿到服务器的原始证书。然后是动态重签：AV引擎验证原始证书没问题后，用自己预装在系统受信任根证书库里的私钥，现场签发一张新证书，域名照抄目标站点。最后是下游交付：把这张"替身证书"发给浏览器。

因为操作系统已经信任了AV的根证书，浏览器自然会接受这张证书，TLS连接顺利建立。到这一步，AV就拿到了明文数据流，可以做特征码扫描了。问题在于，这套流程一旦介入，浏览器其实只跟AV引擎建立了连接，压根没有直接验证过目标服务器。这种架构会强行绕过浏览器内置的多项高级安全机制。

第一个被绕过的是证书透明度（CT）验证。 Chrome、Edge、Firefox这些主流浏览器都强制要求服务器证书必须附带SCT（签名证书时间戳），用来证明这张证书已经被记录进公开的Merkle Tree日志。这是防止CA机构偷偷签发违规证书的核心手段。但AV一旦重签证书，证书指纹就变了，原始证书上的SCT签名立刻作废，跟新证书对不上。而浏览器对"用户手动安装的本地根证书"签发的证书有豁免策略，不强制做CT验证。AV正是钻了这个空子，导致浏览器直接跳过CT检查。换句话说，开启HTTPS扫描后，用户实际上丧失了识别违规签发证书的能力——哪怕攻击者手里有一张受信任CA违规签出的假证书，浏览器也不会报警。

第二个被绕过的是公钥固定（Pinning）机制。 像Google、GitHub这类高价值站点，会在代码或预置列表里硬编码自己的合法公钥指纹。正常情况下，如果收到的公钥跟预期不符，连接会直接中断。但AV介入后，浏览器收到的是AV的公钥，Pinning校验必然失败。为了兼容性，浏览器检测到失败原因是本地根证书时，往往会选择放行。于是，这个本来专门用来防中间人攻击的机制，反而被AV给废掉了。

第三个问题出在AV厂商自身的实现上。 做HTTPS扫描的AV厂商，其SSL验证模块的严谨程度普遍不如浏览器开发商。目前主流消费级杀软（Bitdefender、Kaspersky、ESET等），在重签证书前很少会完整查询和验证CT日志。浏览器的证书吊销列表和OneCRL更新非常频繁，但AV引擎对已吊销证书的响应往往存在延迟。另外，部分老旧的AV引擎不支持TLS 1.3的新特性（比如ECH），为了能解密流量，可能会把连接强制降级到安全性更低的协议版本。

chx818

卡巴引入的SuperMITM应该能解决这个问题？

Picca

感谢楼主科普

作为小白的我有个问题。上面楼主提出的三个问题，似乎有一个很危险的前提，攻击者必须在某种意义上可以让访问或者控制（包含社会工程学）用户的电脑。因为据我所知，根证书是系统极为敏感的部分，杀毒软件和系统一般来说都会严加防范。如果攻击者可以做到上面提到的危险前提，是否意味着Windows已经被控制或者不安全了。

这个时候再去讨论浏览器的安全，是否有点本末倒置了？

huangzihang

Picca 发表于 2026-1-24 17:32
感谢楼主科普

作为小白的我有个问题。上面楼主提出的三个问题，似乎有一个很危险的前提，攻击者必须在某 ...

杀软扫描tls，是杀软会安装根证书，会降低tls安全性（chrome原生的安全性更好）

Balaor

这种劫持加密（扫描流量）的安全软件，会导致网络有一定延迟吧？

PS：火绒目前还不能扫描https。

huangzihang

Balaor 发表于 2026-1-24 20:59
这种劫持加密（扫描流量）的安全软件，会导致网络有一定延迟吧？

PS：火绒目前还不能扫描https。

会的

Balaor

huangzihang 发表于 2026-1-24 22:16
会的

嗯。偶然间关闭火绒的加密链接扫描后，发现打开网页明显快了很多；之后就一直没开启过了。。

Zeusx

BD好像只是替换一部分的证书，比如卡饭的，大部分还是原本的证书

Picca

huangzihang 发表于 2026-1-24 18:01
杀软扫描tls，是杀软会安装根证书，会降低tls安全性（chrome原生的安全性更好）

感谢回复，又认真看了几遍。确实这些攻击都发生在网络层，跟本地计算机是否被控制关系不大

metaverse

这是说最好关闭杀软的https加密扫描吗？