保持加密，保持安全：使用 ESNI、DoH 和 DoT

保护互联网隐私的最新进展包括加密的 TLS 服务器名称指示 (ESNI) 和 DNS over HTTPS (DoH) 形式的加密 DNS，这两者都被数据收集者认为是极具争议的。

因此，这里快速浏览一下它们存在的原因、它们的详细信息以及它们工作方式背后的技术。

DNS 需要正常运行

拆分隧道虚拟专用网络 (VPN) 连接、Web 代理自动发现 (WPAD) 协议、零配置多播 DNS (mDNS)、实时黑名单 (RBL) 以及许多其他广泛部署的技术在 DNS 不中断时会中断” t 正确操作。

为了利益和名誉而破坏互联网

早在 2003 年，互联网用户就了解到 DNS 在全球范围内的重要性，当时运营.com顶级域 (TLD) 的公司选择停止发布NXDOMAIN响应。 相反，他们冒充任何不存在的域，试图提供更多广告、销售更多域并最终产生更多收入。 意料之外的连锁反应引发了一场公开辩论，并引发了 ICANN 安全与稳定咨询委员会 (SSAC) 的一份谴责报告。 该项目确实已关闭，但从技术角度来看，该漏洞仍然存在。

2008 年晚些时候，当一些最大的 ISP 最终引入了针对几乎任何网站的跨站点脚本攻击的各种途径时，再次公开呼吁操纵 DNS 以获取利润的尝试。 由于漏洞的性质，即使是托管在专用网络上且无法从 Internet 访问的网站也可以被利用。

发现的问题不在于核心互联网协议，而是由于某些 DNS 功能的不当货币化而加剧的问题。

Paul Vixie，互联网系统联盟 (ISC)

虽然协议本身确实不是问题的真正原因，但这些协议也确实不能防止不良行为者滥用系统。 因此，从技术角度来看，该漏洞仍然存在。

打破互联网进行监视和审查

2016 年，观察到伊朗的 ISP 正在操纵 DNS。 这一次，他们没有注入广告，而是阻止了对 Internet 上前 10,000 个域中的 139 个的电子邮件服务器的访问。 目前尚不清楚这是否是针对这些特定域的故意拒绝服务政策——类似于世界知名的中国审查制度——或者可能只是拦截 DNS 查询的任何系统的技术实施不当的一个例子。

不知道 DNS 被拦截的原因很重要：即使我们抛开关于全面监视和审查的道德和法律问题，用于执行此操作的技术本质上是不符合标准的，很可能会干扰您对互联网的正常、日常、合理和合法使用。

然而，从技术角度来看，该漏洞仍然存在。

出于邪恶目的破坏互联网

当然，不只是商业实体和政府试图以自己的方式拦截互联网流量。 有很多犯罪分子试图劫持连接的例子，通常是为了窃取用户数据或诱骗用户泄露重要的访问凭据。 最突出的是，DNS 缓存中毒已被用于将用户引导至网络钓鱼站点、部署勒索软件、部署僵尸网络、拒绝向特定网站提供服务等等。

TLS 泄漏谁连接到谁

传输层安全 (TLS) 是 HTTPS 背后的技术，HTTPS 是我们每天都依赖的安全版本的 HTTP。 建立 TLS 连接需要多个步骤，在此期间服务器通过出示证书证明其身份，并交换新的加密密钥。

让服务器使用证书来证明其身份是非常重要的一步，因为证书的一部分是非对称公共加密密钥。

当客户端使用此密钥发送消息时，只有拥有相关私钥的服务器才能读取该消息。 结果，任何拦截或监听连接的人都被锁定并且无法阅读内容。

但是，初始交换仍然是在没有加密的情况下以明文方式进行的，这意味着观察者将始终知道服务器的身份。

领域前沿

一些反审查类型的工具使用称为域前端的技术在一段时间内解决了 TLS 中的这种泄漏问题。 这利用了这样一个事实，即一旦建立了 HTTPS 连接，大多数大型托管服务提供商不会检查每个 HTTP 请求中显示的主机名是否与 TLS 握手中使用的主机名匹配。 在隐私工具方面，这被视为一个有用的功能，允许与隐藏站点进行秘密通信。 对于托管服务提供商和数据收集者来说，这被视为对规范实施方式的滥用。

这本身就是一个漏洞，因此已由包括 AWS 在内的几家主要托管服务提供商修复。

通过更改标准解决问题：加密 SNI (ESNI)

ESNI 背后的想法是通过加密所有消息（包括初始Client Hello消息）来防止 TLS 泄漏任何数据。 这让任何观察者都完全不知道服务器提供的是什么服务器证书。

为此，客户端在建立连接之前需要一个加密密钥。 因此，ESNI 要求将一组特定的 ESNI 加密密钥放在 DNS 的 SRV 记录中。

然而，这方面的确切细节仍在不断变化，因为规范尚未最终确定。 尽管如此，Mozilla Firefox 和 Cloudflare 已经将 ESNI 的实现投入生产。

保护和加密 DNS

为了使 ESNI 密钥在不被拦截的情况下交付，重要的是要防止 DNS 篡改。

早在 1993 年，互联网社区就一直在努力保护 DNS。 IETF 指出，早期的问题解决会议讨论了：

1. 防止将 DNS 数据泄露给未经授权的各方
2. 确保数据完整性
3. 数据源认证

这些会议促成了 1997 年的域名系统安全扩展 (DNSSEC) 标准。该标准选择解决其中三个问题中的两个，因为设计团队明确决定将所有数据泄露威胁明确排除在范围之外。

因此，DNSSEC 意味着用户可以相信他们的 DNS 查询的答案是域所有者想要的。 在 ESNI 的上下文中，这意味着我们知道我们收到的密钥没有被篡改，幸运的是，当使用 DNSSEC 时，上面提到的许多漏洞都会消失。 但是，它不能确保隐私，因此仍然容易受到监视和审查系统引入的问题的影响。

不幸的是，由于它与“不安全的 DNS”完全向后兼容并且很难正确实施，因此 DNSSEC 的采用率非常低。 许多域所有者在尝试配置它的过程中放弃了，这在野外看到的许多无效和半设置配置证明了这一点。

HTTPS 上的 DNS (DoH)

为了在观察者不知道用户试图访问哪个站点的情况下交付 ESNI 密钥，防止 DNS 窃听非常重要。 因此，说加密的 DNS （例如使用 DoH）是一件好事是非常合乎逻辑和可以理解的。 然而，就目前而言，DNS 并未加密。

Mozilla、谷歌、APNIC、Cloudflare、微软和其他公司正在采取行动来改变这一点。

理想的加密用户体验

当涉及到使用加密的实际 UX 细节时，想要利用上述技术的用户可能有相当长的要求列表。 很可能，他们希望避免以下情况：

• 被迫使用特定的 DNS 服务提供商（无论它有多好）或选择不可见或难以找到
• 设备上的每个应用程序处理 DNS 的方式不同（例如，Firefox 可以找到 Safari 无法找到的东西）
• 设备上的所有应用程序都必须在自身内部创建自己的安全 DNS 实现
• 必须多次手动配置 DNS
• 不得不选择隐私和安全
• 应用程序在未经用户同意的情况下退回到不安全的操作

有隐私意识的用户会想要：

• 不受任何人无端监视的隐私
• 防止他们未同意的定向广告
• 保护他们自己发布的内容（例如，在个人网站上）在传递给其他查看者的途中不被更改或操纵
• 确保他们自己发布的内容的查看者不会仅仅因为访问它而陷入麻烦
• 继续拥有在他们自己的网络上控制 DNS 的选项（因为有时，水平分割 DNS 有利于将内部资源限制在内部用户范围内）
• 在 DNS 级别选择加入或至少退出过滤的能力（例如，Quad9、CleanBrowsing 和 OpenDNS Family Shield）
• 简单、无忧的配置（即 DHCP）
• 被要求同意使用不加密的 DNS
• 不仅保护浏览器流量，还保护所有类型的流量，例如电子邮件、Slack、VoIP、SSH、VPN 等。

当前的加密努力

具有上述目标的用户有哪些选择？

Mozilla 的解决方案是一个开始，但远非理想。 他们只是保护 Firefox； 默认设置是覆盖您的操作系统设置以支持他们选择的提供商（Cloudflare）而不这么说，它会默默地退回到不安全的状态（在加密 DNS 被阻止等情况下）

谷歌的解决方案是一种更好的方法。 他们正在保护适用于所有应用的 Android 9+。 （我不确定他们的 Chrome OS 计划，但我怀疑它正在开发中。）他们还在所有平台上保护 Chrome，但它仅在主机平台配置为使用支持安全性的提供程序时才会触发安全性。 这在用户选择方面很好，但并不理想，因为它会默默地退回到不安全的状态。

所有其他主要浏览器也在实施支持。

在用户的理想情况下，更广泛的软件和操作系统开发人员社区将：

1. 停止在应用程序级别实施新的 DNS 安全功能
2. 开始在操作系统级别实现它们
3. 尊重操作系统级别的配置，或征得用户同意

在操作系统级别实施加密 DNS，我们可以继续遵循我们目前用于 DNS 解析器的相同分布式模型。 在自己的网络上运行自己的 DNS 服务器，并能够使解析器安全，继续作为一种选择是有意义的，就像使用集中式提供商一样。

Linux 和 BSD 已经具有此功能，并有多种可用选项。 不幸的是，据我所知，没有发行版默认启用它们中的任何一个。 如果您想要插入 glibc 的东西，请查看 nss-tls。

Google 在 Android 9+ 中的 DNS-over-TLS 实施也已经这样做了。 它通过测试 DNS 服务器的加密支持来发挥作用。 如果它有它，那么它将使用它。 如果没有，那么与 Chrome 一样，它会以不安全的方式继续运行，无需提示同意。

值得注意的是，大多数网络都配置为使用不支持加密的 DNS 服务器，因此 Android 内置的解决方案对大多数用户来说并没有改变任何东西。 在去中心化不支持加密的情况下，提供回退到集中式加密 DNS 可能会更好。

对于 Apple 和 Microsoft 风格的设备，在撰写本文时，对加密 DNS 的支持尚未正式到来。 随着微软在 2019 年 11 月宣布他们打算支持加密 DNS，希望苹果很快就会跟进。

加密 DNS 解决方法

有一些可以在本地运行的代理形式的解决方法。 有了这些，用户的计算机会向自己发送非加密的 DNS，然后它会向配置为使用的任何提供商发送加密的 DNS。 这不是一个理想的解决方案，但随着变通方法的发展，它是不错的。

写这篇文章的灵感来自 DNSCrypt 代理，它非常稳定，有很多花里胡哨，而且是跨平台的。 它支持较旧的 DNSCrypt 协议，以及较新的 DNS over TLS (DoT) 和 DNS over HTTPS (DoH) 协议。

对于 Windows 用户，有一个名为 Simple DNSCrypt 的安装程序和 GUI，它功能齐全且非常易于使用。

我推荐它，但请注意，世界可能还没有为您准备好，您可能需要不时禁用它（例如，当您必须在您最喜欢的咖啡馆或 LAN 中使用强制门户时派对）。

其他选项

此外，还有支持加密 DNS 的 Technitium DNS 服务器，它是跨平台的（Windows、MacOS、ARM/Raspberry Pi 上的 Linux），并具有流畅的 Web 界面。 它在“其他”之下，因为它更像是一个全方位的工具，而不是针对这个问题的解决方案。 （如果您想在家中运行 Raspberry Pi DNS 服务器，这可能是一个不错的选择。我很想在下面的评论中听到尝试它的人的反馈。）

对于您的 Android 或 iOS（iPhone、iPad 等）设备，还有 1.1.1.1 应用程序，它将强制您通过 Cloudflare 加密 DNS 服务进行所有 DNS 查询。 我听说还有更灵活的应用程序，例如 Intra，但我还没有花时间测试它们。

当然，您也可以在 Firefox 和 Chrome 中启用加密 DNS - 请记住上面讨论的所有注意事项。

DNS 可靠性：第一号工作

互联网隐私技术存在很多争议。 但是，在实施安全和隐私措施时，所讨论的技术主要不是保密。 这是关于确保可靠性并保证技术继续正常运行，尽管其他人的行为。 然而，我们需要注意，就像没有隐私保护的技术是不好的一样，实施不善的保护只会使情况变得更糟。