在互联网上保护隐私的最新发展包括加密TLS服务器名称指示(ESNI)和加密 DNS 以DNS over HTTPS (DoH)的形式，这两种形式都被考虑 极具争议 数据收集者.

下面我们来快速了解一下它们存在的原因, 关于它们是什么的细节, 以及它们工作原理背后的技术.

DNS需要发挥作用 Correctly

Split-tunnel VPN (virtual private network)连接，web代理 auto-discovery (WPAD) protocol, 零配置 组播DNS (mDNS); real-time blacklists (RBL), 当DNS不能正常运行时，许多其他广泛部署的技术就会失效.

打破互联网的利润和名声

早在2003年, 互联网用户了解到DNS在全球范围内的重要性 .com 顶级域名(TLD)选择停止发行 NXDOMAIN responses. They instead impersonated 任何不存在的域名，试图提供更多的广告, 出售更多域名, 并最终产生更多的收入. 这一意想不到的连锁反应引发了一场公众辩论 ICANN安全与稳定咨询委员会(SSAC)的一份措辞严厉的报告. 这个项目确实被关闭了，但从技术角度来看，漏洞仍然存在.

Later in 2008, 当一些最大的互联网服务提供商最终引入各种跨站点脚本攻击时，另一种操纵DNS以获取利润的尝试被公开呼吁 any website. 由于漏洞的性质, 即使是托管在专用网络上且无法从Internet访问的网站也可以被利用.

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

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

尽管协议本身并不是问题的真正原因，这是事实, 这些协议并不能防止不良行为者滥用系统，这也是事实. 因此，从技术角度来看，漏洞仍然存在.

打破互联网的监视和审查

2016年，有人观察到伊朗的互联网服务提供商操纵DNS. 这一次，他们没有打广告，而是打了广告 阻止访问前10,000个域名中的139个电子邮件服务器 on the internet. 目前尚不清楚这是否是针对这些特定域的故意拒绝服务策略——类似于 世界闻名的中国审查制度-或者可能只是拦截DNS查询的系统的糟糕技术实现的一个例子.

不知道为什么DNS被拦截是很重要的:即使我们把关于全面监视和审查的道德和法律问题放在一边, 用于此操作的技术本质上是不符合标准的，并且很可能会干扰您的正常工作, everyday, reasonable, 以及合法使用互联网.

然而，从技术角度来看，漏洞依然存在.

为了邪恶的目的破坏互联网

Of course, 不仅仅是商业实体和政府为了自己的目的而试图拦截互联网流量. 有很多犯罪分子企图劫持关系的例子, 通常是为了窃取用户数据或欺骗用户泄露重要的访问凭据. Most prominently, DNS缓存中毒 被用来引导用户进入钓鱼网站， deploy ransomware, deploy botnets, 拒绝对特定网站的服务, and much more.

TLS泄露谁连接到谁

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

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

当客户端使用此密钥发送消息时, 只有拥有关联私钥的服务器才能读取消息. As a result, 任何拦截或监听连接的人都将被锁定，无法读取内容.

However, 最初的交换仍然是在没有加密的情况下进行的, 这意味着观察者将始终知道服务器的身份.

Domain Fronting

A few 反审查类工具 在一段时间内，使用了一种称为 domain fronting. 这利用了一旦建立HTTPS连接的事实, 大多数大型主机提供商不检查每个主机名是否显示 HTTP request 与TLS握手中使用的匹配. 在隐私工具方面, 这被认为是一个有用的功能，允许与隐藏的站点进行秘密通信. 用于托管提供商和数据收集器, 这被看作是对规范实现方式的滥用.

这本身就是一个弱点, 并且已经被几个主要的主机提供商修复了, including AWS.

通过改变标准解决问题:加密SNI (ESNI)

ESNI背后的思想是通过加密来防止TLS泄露任何数据 all 的信息，包括最初的 Client Hello message. 这使得任何观察者完全不知道服务器提供的是什么服务器证书.

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

然而，具体细节仍不确定，因为 the specification 还没有定稿吗. Despite this, an implementation of ESNI has already been put into production by Mozilla Firefox and Cloudflare.

保护和加密DNS

用于发送ESNI密钥而不被拦截, 防止DNS篡改是很重要的.

早在1993年，互联网社区就一直在努力确保DNS的安全. IETF指出，早期的问题解决会议讨论了:

1. 防止向未授权方泄露DNS数据
2. 确保数据完整性
3. 数据源认证

这些会议的结果是 域名系统安全扩展(DNSSEC) standard in 1997. 该标准选择解决三个问题中的两个, 由于设计团队做出了明确的决定，将所有数据泄露的威胁明确排除在范围之外.

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

Unfortunately, 因为它完全向后兼容“不安全的DNS”，并且很难正确实现, DNSSEC的采用率非常低. 许多域名所有者在尝试配置它的过程中中途放弃了, 正如在野外看到的许多无效和半设置配置所证明的那样.

DNS over HTTPS (DoH)

对于ESNI密钥的交付，没有观察者知道用户试图访问哪个站点, 防范DNS窃听很重要. 因此，这样说是合乎逻辑的，也是可以理解的 encrypted DNS (比如DoH)是一件好事. 然而，就目前而言，DNS并没有加密.

有很多动作 Mozilla, Google, APNIC, Cloudflare, Microsoft, and others to change this.

理想的加密用户体验

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

• 被迫使用特定的DNS服务提供商(无论它有多好)，或者选择不可见或难以找到
• 设备上的每个应用程序处理DNS的方式不同.g., Firefox 能找到一些 Safari cannot)
• 设备上的所有应用程序都必须 创建自己的安全DNS实现 within itself
• Having to 手动配置DNS multiple times
• 必须选择隐私和 security
• 未经用户同意，应用退回到不安全的运行状态

注重隐私的用户会希望:

• 不受任何人非法监视的隐私
• 防止他们不同意的定向广告
• 保护自己发表的内容(例如.g.(在个人网站上)防止在传递给其他观众的过程中被更改或操纵
• 确保自己发布的内容的观众不会因为访问它而陷入麻烦
• 继续拥有在自己的网络上控制DNS的选项(因为有时， split-horizon DNS 有利于将内部资源限定在内部用户范围内)
• The ability to opt into, or at least opt out of，在DNS级别进行过滤(例如.g., Quad9, CleanBrowsing, and 打开家庭盾牌)
• 简单，无麻烦的配置(i.e., DHCP)
• 请求同意不加加密地使用DNS
• 不仅保护浏览器流量，还保护所有类型的流量.g.，电子邮件，Slack, VoIP, SSH, VPN等.

当前的加密工作

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

Mozilla的解决方案是一个开始，但远非理想. 他们只是在确保 Firefox; the default is to override your OS settings in favor of their choice of provider (Cloudflare)不用这么说, 并且它会悄悄地退回到不安全的状态(在加密DNS被阻止的情况下), etc.)

谷歌的解决方案是一种更好的方法. They are securing Android 9+-适用于 all apps. 我不确定他们的计划是什么 Chrome OS但我怀疑它正在筹备中.)他们也在确保安全 Chrome on all platforms, 但是，只有当主机平台配置为使用支持安全性的提供程序时，它才会触发安全性. 这在用户选择方面是好的，但不是理想的，因为它会悄悄地退回到不安全的状态.

所有其他主流浏览器也是如此 实施支持.

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

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

在操作系统级别实现DNS加密, 我们可以继续遵循我们目前为DNS解析器所采用的相同的分布式模型. 在自己的网络上运行自己的DNS服务器, 并且能够使解析器安全, 继续做一个选择是有意义的, 使用集中式提供者也是如此.

Linux和BSD已经有了这个功能，并提供了各种可用的选项. 不幸的是，据我所知，没有发行版默认启用这些功能. Check out nss-tls 如果你想要插入glibc.

Google在Android 9+中的DNS-over-TLS实现也已经做到了这一点. 它的功能是测试DNS服务器是否支持加密. 如果它有，它就会使用它. 如果没有，那么就像chrome一样，它会以一种不安全的方式继续运行，而不会提示用户同意.

值得注意的是，大多数网络被配置为使用不支持加密的DNS服务器, 所以Android内置的解决方案对大多数用户来说还没有任何改变. 也许在去中心化不支持加密的情况下，提供回退到集中式加密DNS会更好.

适用于苹果和微软的设备, 在撰写本文时，对加密DNS的支持尚未正式到来. With 微软在2019年11月宣布了他们支持加密DNS的意图希望苹果也能尽快跟进.

加密DNS解决方案

有一些可以在本地运行的代理形式的解决方法. With these, 用户的计算机对自己使用未加密的DNS, 然后将加密的DNS发送给它配置使用的任何提供商. 这不是一个理想的解决方案，但作为变通方法，它是不错的.

写这篇文章的灵感来自于 DNSCrypt proxy它非常稳定，有很多铃铛和口哨，而且是 cross-platform. 它支持老年人 DNSCrypt protocol，以及较新的 DNS over TLS (DoT) and DNS over HTTPS (DoH) protocols.

对于Windows用户来说，有一个 安装程序和GUI称为简单的DNSCrypt，功能齐全，非常易于使用.

I recommend it, 但要知道，这个世界可能还没有为你做好准备, 您可能需要不时地禁用它.g.(当您必须在您最喜欢的咖啡馆或局域网聚会上使用专用门户时)。.

Other Options

此外，还有 DNS服务器, which 支持加密DNS它是跨平台的(Windows、MacOS、ARM/Raspberry Pi上的Linux)，并具有流畅的web界面. 它在“其他”下，因为它更像是一个全面的工具，而不是针对这个问题的解决方案. (如果你想在家里运行你的树莓派DNS服务器，这可能是一个很好的选择. 我很有兴趣在下面的评论中听到尝试它的人的反馈.)

For your Android or iOS (iPhone, iPad等.) 设备方面，也有 1.1.1.1 应用程序，它将强制您的所有DNS查询 Cloudflare 加密DNS服务. 我听说还有更灵活的应用程序，比如 Intra，但我还没有花时间去测试它们.

当然，您也可以在两者中启用加密DNS Firefox and Chrome -只要记住上面讨论的所有警告.

DNS可靠性:首要任务

关于网络隐私技术有很多争议. However, 在实施安全和隐私措施方面, 所讨论的技术主要不是为了保密. 这是关于确保可靠性和保证技术继续正确运行，不管其他人的行为. Yet, 我们需要注意这一点, 就像没有隐私保护的技术不好一样, 落实不力的保障措施只会使情况变得更糟.