srcmini本文概述
保护互联网隐私的最新进展包括加密的TLS服务器名称指示(ESNI)和形式为HTTPS上的DNS(DoH)形式的加密DNS, 这两种数据收集者都认为这是有争议的。
因此, 这里快速浏览了它们存在的原因, 它们是什么的详细信息以及它们工作原理的技术。
DNS需要正常运行
拆分隧道虚拟专用网(VPN)连接, Web代理自动发现(WPAD)协议, 零配置多播DNS(mDNS), 实时黑名单(RBL)和许多其他广泛部署的技术会在DNS不起作用时中断。 t正确操作。
打破互联网谋取名利
早在2003年, 互联网用户就了解了DNS在全球范围内的重要性, 当时该公司随后运行.com顶级域名(TLD), 该公司选择停止发布NXDOMAIN响应。相反, 他们冒充任何不存在的域, 以尝试投放更多广告, 出售更多域并最终产生更多收入。出乎意料的连锁效应导致了ICANN安全与稳定咨询委员会(SSAC)的公开辩论和报告。该项目确实已关闭, 但从技术角度来看, 该漏洞仍然存在。
在2008年晚些时候, 当一些最大的ISP最终引入了针对几乎所有网站的跨站点脚本攻击的各种途径时, 公开地操纵DNS牟利的另一种尝试。由于漏洞的性质, 甚至可以利用托管在专用网络上并且无法从Internet访问的网站。
发现的问题不在于核心互联网协议, 而是由于某些DNS功能的不当获利而加剧的问题。互联网系统协会(ISC)的Paul Vixie
尽管协议本身并不是问题的真正原因, 但这些协议也不能阻止不良行为者滥用系统。因此, 从技术角度来看, 该漏洞仍然存在。
中断互联网进行监视和检查
2016年, 据观察, 伊朗的ISP正在操纵DNS。这次, 他们没有注入广告, 而是阻止访问Internet上前10, 000个域中的139个电子邮件服务器。目前尚不清楚这是否是针对这些特定域的拒绝服务的有意政策(类似于中国享誉世界的审查制度), 或者仅仅是任何系统在拦截DNS查询方面的不良技术实施的一个例子。
也可以看看：
- 你的ISP是否正在劫持你的DNS流量？
- 我的ISP使用深度数据包检查；他们能观察到什么？
不知道为什么要截获DNS很重要：即使我们抛弃了有关全面监视和审查的道德和法律问题, 从本质上讲, 用于执行此操作的技术也不符合标准, 并且很可能会干扰你正常, 日常, 合理和合法地使用互联网。
但是从技术角度来看, 该漏洞仍然存在。
出于恶意目的破坏互联网
当然, 不仅仅是商业实体和政府都试图以自己的方式拦截互联网流量。有许多犯罪分子试图劫持连接的例子, 通常是为了窃取用户数据或诱使用户泄露重要的访问凭据。最显着的是, DNS缓存中毒已被用于将用户定向到网络钓鱼站点, 部署勒索软件, 部署僵尸网络, 拒绝对特定网站的服务等等。
TLS泄漏谁连接到谁
传输层安全性(TLS)是HTTPS背后的技术, HTTPS是我们所有人每天都依赖的HTTP安全版本。建立TLS连接需要许多步骤, 在此期间, 服务器将通过提供证书来证明其身份, 并交换新的加密密钥。
让服务器使用证书来证明其身份是非常重要的一步, 因为证书的一部分是不对称的公共加密密钥。
当客户端使用此密钥发送消息时, 只有拥有关联私钥的服务器才能读取该消息。结果, 任何拦截或监听连接的人都被锁定, 无法阅读内容。
但是, 初始交换仍然是在没有加密的情况下进行的, 这意味着观察者将始终知道服务器的身份。
域前沿
一些反检查类型的工具使用称为域前沿的技术来解决TLS中的此漏洞一段时间。这利用了以下事实：一旦建立了HTTPS连接, 大多数大型主机提供商就不会检查每个HTTP请求中显示的主机名是否与TLS握手中使用的主机名匹配。在隐私工具方面, 这被视为有用的功能, 允许与隐藏站点进行秘密通信。对于托管提供商和数据收集者, 这被视为滥用了实施规范的方式。
这本身就是一个漏洞, 因此已被包括AWS在内的一些主要托管提供商修复。
通过更改标准解决问题：加密的SNI(ESNI)
ESNI背后的想法是通过加密所有消息(包括初始的客户端Hello消息)来防止TLS泄漏任何数据。这使所有观察者完全看不到服务器要提供的服务器证书。
为此, 客户端在建立连接之前需要加密密钥。因此, ESNI需要将一组特定的ESNI加密密钥放置在DNS的SRV记录中。
但是, 由于规范尚未最终确定, 因此其确切的细节仍在不断变化。尽管如此, Mozilla Firefox和Cloudflare已将ESNI的实现投入生产。
保护和加密DNS
要使ESNI密钥不被拦截就可以交付, 请务必防止DNS篡改。
自1993年以来, 互联网社区就一直在尝试保护DNS。 IETF指出, 早期的解决问题会议讨论了：
- 防止DNS数据泄露给未授权方
- 确保数据完整性
- 数据来源认证
这些会议产生了1997年的域名系统安全扩展(DNSSEC)标准。由于设计团队做出了明确决定, 将所有数据公开威胁明确排除在范围之外, 因此该标准选择解决其中三个问题。
这样, DNSSEC意味着用户可以相信, 他们的DNS查询的答案就是域所有者希望的答案。在ESNI的背景下, 这意味着我们知道我们收到的密钥尚未被篡改, 并且值得庆幸的是, 在使用DNSSEC时, 上面提到的许多漏洞都消失了。但是, 它不能确保隐私, 因此仍然容易受到监视和检查系统引入的问题的影响。
不幸的是, 由于它与”不安全的DNS”完全向后兼容, 并且很难正确实施, 因此DNSSEC的采用率非常低。许多域所有者在尝试配置它的过程中都放弃了, 正如在野外看到的许多无效和半设置配置所证明的那样。
资料来源：Cloudflare
通过HTTPS的DNS(DoH)
要使ESNI密钥在观察者不知道用户试图访问哪个站点的情况下交付, 请务必防止DNS窃听。因此, 说加密的DNS(例如使用DoH)是一件好事, 这是很合逻辑且可以理解的。但是, 就目前而言, DNS尚未加密。
Mozilla, Google, APNIC, Cloudflare, Microsoft和其他公司采取了一些措施来更改此设置。
理想的加密用户体验
想要利用上述技术的用户在处理加密的实际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被阻止等情况下)。
Google的解决方案是一种更好的方法。他们正在保护适用于所有应用程序的Android 9+。 (我不确定他们对Chrome OS的计划, 但我怀疑它正在制定中。)他们还在所有平台上保护Chrome, 但是只有在将主机平台配置为使用支持安全性的提供程序时, 它才会触发安全性。就用户选择而言, 这很好, 但并不理想, 因为它默默地退回到不安全的状态。
所有其他主要浏览器也都在实施支持。
在用户的理想情况下, 更广泛的软件和OS开发人员社区将：
- 停止在应用程序级别实施新的DNS安全功能
- 在操作系统级别开始实施它们
- 遵守操作系统级别的配置, 或征得用户同意
在操作系统级别实施加密的DNS, 我们可以继续遵循与DNS解析器当前相同的分布式模型。在自己的网络上运行自己的DNS服务器, 并能够确保该解析器的安全, 继续使用该选项很有意义, 就像使用集中式提供程序一样。
Linux和BSD已经具有此功能, 并且具有多种可用选项。不幸的是, 据我所知, 没有发行版默认启用它们。如果你需要将某些东西插入glibc中, 请查看nss-tls。
Google在Android 9+中的DNS-over-TLS实施也已经做到了。它通过测试DNS服务器的加密支持来起作用。如果有, 它将使用它。如果不是这样, 则与Chrome一样, 它会以不安全的方式继续运行, 而无需征得你的同意。
值得注意的是, 大多数网络都配置为使用不支持加密的DNS服务器, 因此Android内置的解决方案对于大多数用户而言仍然没有任何改变。在分散式不支持加密的情况下, 最好还是使用集中式加密DNS。
对于Apple和Microsoft风味设备, 在撰写本文时, 尚未正式支持对加密DNS的支持。随着Microsoft在2019年11月宣布他们打算支持加密DNS的打算, 希望Apple会很快效仿。
加密的DNS解决方法
有一些可以在本地运行的代理形式的变通办法。有了这些, 用户的计算机就会对自己说出非加密的DNS, 然后, 它向与其配置为使用的任何提供商说出加密的DNS。这不是理想的解决方案, 但是随着变通办法的发展, 它是不错的选择。
撰写本文的灵感来自DNSCrypt代理, 该代理非常稳定, 风吹草动, 并且是跨平台的。它支持较旧的DNSCrypt协议, 以及较新的TLS上的DNS(DoT)和HTTPS上的DNS(DoH)协议。
对于Windows用户, 有一个名为Simple DNSCrypt的安装程序和GUI, 它功能齐全且易于使用。
我建议这样做, 但要注意, 世界可能还没有准备好, 因此你可能需要不时禁用它(例如, 当你必须在自己喜欢的咖啡馆或局域网中使用俘虏门户时)派对)。
其他选择
此外, 还有Technitium DNS服务器, 该服务器支持加密的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可靠性：工作第一
互联网隐私技术存在很多争议。但是, 在实施安全性和隐私权措施时, 所关注的技术主要不是保密。这是关于确保可靠性并确保该技术能够继续正常运行, 而不管其他行为如何。但是, 我们需要注意的是, 就像没有隐私保护措施的技术很糟糕一样, 执行不当的保护措施只会使情况变得更糟。
评论前必须登录！
注册