TechTok #7：跳入隐私与安全池的深渊

在本期 TechTok 专栏中，我们将解析量子抗性协议对电池续航的影响、剖析 DoH 与 DoQ 的差异，并探讨 SSL 证书的本质及其与 AdGuard 等工具的交互原理。系好安全带，我们即将启程。

Big Mekk 提问：

我在贵司新闻通讯中注意到 AdGuard VPN 将支持 Kyber/量子计算协议。启用该功能是否会增加电池消耗？我主要关心移动设备上的运算处理。

为尚未了解此事的读者说明：AdGuard VPN 已在桌面端和移动端应用中部署 Kyber 算法支持，该算法专为抵御后量子计算机威胁而设计。关于对于电池的影响，让我们深入技术细节：我们在移动端和桌面端均采用混合方案，同时使用经典 X25519 椭圆曲线算法与基于 Kyber768 的 ML-KEM768 算法。

当移动设备与 AdGuard VPN 建立连接时，两种算法会并行运作。用户的设备会发送两个公钥（分别对应 X25519 和 Kyber768），服务器同样会回复双重密钥。双方通过算法生成共享密钥并安全融合为最终 VPN 会话的加密密钥。这种双重交换机制确实比传统握手消耗更多数据，常规握手双向各需约 32 字节，而混合握手需要约 1.2KB。

就电池影响而言，额外计算确实会略微增加 CPU 负载。在老旧设备上，启用 Kyber 算法会使连接建立时间延长最多 0.1 秒，仅在初始连接阶段会产生可忽略的额外耗电（其影响远低于日常操作如亮屏或启动应用）。VPN 连接建立后，会话将采用传统对称加密，电池消耗与常规模式完全相同。

简言之：除非 VPN 会话频繁中断需要反复重连，否则启用 Kyber 算法不会对电池续航产生实质影响。

DoH 和 DoQ 哪种 DNS 协议更私密？

这是个精妙的问题，感谢 Álvaro 的提问！首先需要明确 DoH（DNS over HTTPS）和 DoQ（DNS over QUIC）的本质区别，二者的核心差异在于数据传输方式。这需要从 DNS（域名系统）原理说起。

当浏览器访问网站时，需要通过 DNS 服务器将人类可读的域名转换为计算机可识别的 IP 地址。早期 DNS 查询完全以明文传输，不仅让 ISP 能窥探访问记录，更易遭受窃听、篡改和欺骗攻击。

最初，在遥远的过去，DNS 查询过程完全以明文形式进行，没有任何加密保护。这意味着您的 DNS 查询记录，包括访问的所有网站，都会被 ISP 一览无余。这种未加密的传输方式使 DNS 流量极易遭受窃听、篡改和欺骗攻击。这就是在 DoT（DNS over TLS）和 DoH（DNS over HTTPS）等加密协议出现前，DNS 长期存在的安全状态。DoT 作为加密 DNS 流量的首个重要解决方案，通过 TLS 协议封装 DNS 数据，并专门使用 853 端口传输加密流量。专用端口虽然便于网络管理，但也使得 DoT 流量更容易被识别，在某些情况下更易遭到防火墙或审查系统的拦截。

与 DoT 不同，DoH（DNS over HTTPS）通过 443 端口传输查询，这与普通 HTTPS 网站流量使用相同端口。这种设计是一把双刃剑：一方面使得 DoH 流量更难被检测和拦截，提升隐私性；另一方面由于 DoH 常与网页浏览共用 HTTPS 连接（尤其在浏览器中），可能意外暴露 DNS 查询与特定网站访问之间的关联模式。必须强调的是：HTTP/HTTPS 本质上并非传输层协议。

那么 DoH 如何传输数据？它在应用层使用 HTTP/2 或 HTTP/3 协议，底层则依托 TCP（HTTP/2）或 QUIC（HTTP/3）等加密传输协议。HTTP/2 的多路复用特性允许在单一连接上并行发送多个 DNS 查询，不同请求/响应可共享连接而无需相互等待。但由于 HTTP/2 基于单一 TCP 连接，所有数据包共享同一传输层，这就产生了“队首阻塞”问题，只要有一个数据包丢失或延迟，即使其他数据包属于不同查询且已准备就绪，也必须等待该数据包重传成功。这个问题并非 DoH 独有，所有基于 TCP 的协议都会受此影响。

而 DoQ 为每个 DNS 查询/响应建立独立流，彻底解决上述队首阻塞问题。

现在，让我们回到正题上来：这一切对您的隐私意味着什么？

当 DNS 查询通过单一共享流发送时（如 HTTP/2 下的 DoH），其传输时序会产生关联性。某个查询的延迟可能影响其他查询的响应时间，从而在流量中形成可辨识的模式。尽管内容本身经过加密，但网络管理员、ISP 或审查者仍可通过分析这些时序模式，推测用户访问的网站、访问时间及频率。

DoQ 在隐私保护方面的另一优势在于其流量处理机制。基于 UDP 和 QUIC 协议构建的 DoQ，与混入常规网页流量的 DoH 不同，它能像 DoT 那样保持 DNS 流量独立，同时规避队头阻塞问题。这种隔离性意味着 DNS 活动不会与其他 HTTPS 内容混杂，即使外部观察者更容易识别此类流量，也难以将其与具体浏览行为关联。

不过您可能会问，那最新的 HTTP/3 协议呢？它同样采用 QUIC 作为传输层。这个问题很有价值。事实上，包括 Chrome、Firefox 和 Safari 在内的主流浏览器对 HTTP/3 的支持率已超过95%。但关键在于：虽然 HTTP/3 底层使用 QUIC 协议，HTTP 本身并非传输层协议。若将其作为传输协议的替代方案，将会引发诸多不必要的风险。特别是在隐私方面，基于 HTTP 的流量通常包含 Cookie、认证头、User-Agent 字符串等元数据，这些都可能被用于用户追踪、指纹识别甚至画像分析，而这些恰恰是敏感的 DNS 流量最需要规避的。

综上所述，虽然 DoH 通过混入常规流量增强隐蔽性，但 DoQ 既能避免队首阻塞，又可隔离 DNS 流量并降低信息泄露风险，因此实为更优的隐私选择。

最后回应匿名用户的提问：

公钥证书已成为现代网络基石。AdGuard 在本地设备部署证书如何保护数据？安装证书是利大于弊还是相反？

在深入探讨之前，我们首先要明确数字证书的本质。不妨将其想象成网站、网络服务和 API 必须出示的“数字身份证”，用于证明其真实身份。任何通过互联网远程交互的在线服务（我们称之为“面向网络”的服务）都需要证书来验证其真实性。虽然 HTTPS 能加密传输数据，但若没有数字证书，用户将无法判断连接的是真实网站还是伪装成该网站以窃取信息的钓鱼站点。

您可能会问：既然骗子能伪造网站，难道不能伪造证书吗？幸运的是，这绝非易事。当浏览器连接网站时，对方会发送其证书及中间证书，形成一条直达浏览器已信任根证书颁发机构（CA）的信任链。浏览器通过公钥加密技术验证证书链上每个数字签名，全部验证通过才会建立连接。这意味着，除非攻破或冒用 CA，否则几乎不可能伪造有效证书。虽然并非绝对不可能，但概率极低，最近一次 CA 被入侵的重大事件还要追溯到 2017 年。主流浏览器和操作系统都内置了受信任根证书列表，并会定期更新，移除问题CA并新增可信机构。用户也可手动添加CA，但必须慎之又慎。

回到 AdGuard 的工作原理：当用户在 Windows/Mac/Android 设备上安装 AdGuard 后（浏览器扩展和 iOS 应用机制不同），浏览器访问网站时，流量会先经过 AdGuard。就像直接访问网站时需要信任服务器证书一样，此时浏览器也需要信任 AdGuard，否则 AdGuard 将无法解密 HTTPS 流量。为此，AdGuard 在安装时会生成专属根证书并植入系统信任库。

我们始终强调用户不应随意添加自定义证书，这绝非危言耸听。若错误信任了不可靠的证书颁发机构，后果可能非常严重。但您尽可放心，AdGuard 对安全有着极致追求：在公钥加密体系中，私钥的安全性至关重要。AdGuard 的私钥直接在您设备本地生成，经过加密后永久存储在设备中。这把密钥从未也不会与任何人共享，包括我们开发团队在内都无从知晓。

更重要的是，AdGuard 会全程保障个人数据安全：解密 HTTPS 流量完成广告拦截后，所有内容都会重新加密。与常规浏览器相同，我们会严格验证目标网站的证书真实性。我们还实施多项增强安全措施，具体可参阅知识库文章。

简而言之，AdGuard 虽不会额外提升连接安全性，但绝不会引入任何风险。安装 AdGuard 后，用户既能享受无广告无追踪的清爽网络，又能确保数据传输安全无虞。