提高 App 和服务器的 DNS 安全性

Qiaoyu Deng: 大家好 欢迎收看讲座“提高 App 和 服务器的 DNS 安全性” 我叫 Qiaoyu Deng 在这段视频中 我们将讨论 为什么 DNS 通常会不安全 以及如何使用 DNSSEC 和带 DDR 的加密 DNS 对其进行保护 首先 我们来谈一下为什么 DNS 不安全

DNS 是互联网的电话簿 它将人类可读且容易记忆的 域名翻译成 IP 地址 而 IP 地址是为机器设计的 其他互联网协议 如 TCP TLS 和 QUIC 依赖于 IP 地址 所以一切都从 DNS 开始 目前 TLS 协议被广泛应用于 网络通信的安全保障 这很好 但是基础层 DNS 存在一些安全问题 历史上 DNS 是不安全的 它是在 1983 年设计的 几乎没有考虑安全问题 在那以后的几年里 已经发生了许多 DNS 攻击事件 一个例子是 DNS 缓存中毒 攻击者利用 DNS 解析器的缺陷 让它们缓存不正确的 IP 地址 导致客户端连接到恶意主机 这暴露了 DNS 的一个漏洞 没有经过身份验证 如今传统的 DNS 客户端 无法验证答案 因此很容易被欺骗 另一种常见的攻击是 DNS 嗅探 攻击者监视客户端和 DNS 服务器 之间的 DNS 流量 收集客户端的历史记录 这是一个严重的用户隐私问题 这种攻击可能的原因是 DNS 流量最初是未加密的 为了成为构建在它顶部的协议的 安全起点 DNS 需要经过身份验证和加密 当我们使用 DNSSEC 签署 DNS 响应时 它会提供身份验证 当我们使用 TLS 和 HTTPS 来加密 DNS 解析时 它保证了隐私 接下来 让我们谈谈 DNSSEC DNSSEC 是由 IETF 创建的 一套扩展规范 许多 DNS 服务提供商 已经可以支持它的使用 但另一方面 客户端支持仍在增加 iOS 16 和 macOS Ventura 现在支持客户端 DNSSEC 验证 DNSSEC 通过添加数字签名 来保证数据的身份验证 它能保护数据的完整性 当答案不存在时 它能验证其真实性 它还提供加密身份验证 DNSSEC 通过在响应中 附加签名来保护数据完整性 如果响应被攻击者更改 更改数据的签名将与原始数据不匹配 在这种情况下 客户端可以检测到 更改的响应并将其丢弃 DNSSEC 还通过 使用特殊类型的 DNS 记录 如 NSEC 记录 来明确判断区域中 记录的存在和不存在 NSEC 记录会按字母顺序安全地告诉你 下一个记录名称 它列出的是存在的名称 任何未列出的名称都不存在 例如 我们这里有三条 NSEC 记录 记录集显示 zone org 只有三个记录名称 A.org C.org 和 E.org 现在 如果有攻击者声称 A.org 不存在 那客户端可以检测到这种攻击 A.org 确实存在 因为它被列在第一个 NSEC 记录中 同样 如果攻击者说 D.org 存在 客户端也可以检测到 因为根据第二个 NSEC 记录 D.org 在 C.org 和 E.org 之间 这两个名字之间不应该有名字 DNSSEC 通过建立信任链来认证记录 这里有一个例子 设备希望在 启用 DNSSEC 验证的情况下 解析 www.example.org 它发送查询请求 IP 地址 签名和密钥 通过响应 可以从 IP 地址 到密钥 1 建立信任关系 然后客户端向父区域 org 发送查询 请求可以用来验证密钥 1 的记录 这样它就可以建立 从密钥 1 到密钥 2 的信任关系 因此设备递归地重复这个过程 直到它到达根节点 现在如果根密钥 (图中的密钥 3) 可以被信任 那么从 IP 地址 到密钥 3 的信任关系 就可以被验证 根密钥的哈希值总是安全地 存储在设备中 在 DNSSEC 中 它被称为根信任锚 如果 密钥 3 的哈希值 与预安装的锚匹配 则可以安全地建立信任链 有了信任链 www.example.org 的 IP 地址 现在得到了验证 如果你想在 App 中 要求 DNSSEC 验证 请执行以下操作 支持 IPv6 为你的域名 在纯 IPv6 环境中 纯 IPv4 地址 被转换为合成 IPv6 地址 如果域已签名 则合成地址无法通过 DNSSEC 验证 启用 DNSSEC 后 它们将无法访问 因此 请确保你的域支持 IPv6 确保你的 DNS 服务提供商 用 DNSSEC 为你的域签名 如果你在 App 中启用了 DNSSEC 而没有对你的域进行签名 你将不会获得任何好处 但你将获得额外的 DNS 流量 和延长的解析时间 来尝试对你未签名的域进行身份验证 一旦你获得了相应的基础架构支持 下面是为你的 App 采用 DNSSEC 所需的代码 如果你是 NSURLSession 客户端 则可以要求对 URL 请求 进行 DNSSEC 验证 这里是一个例子 你将首先创建默认会话配置 然后需要 DNSSEC 验证 接下来 你将使用修改后的配置 来创建会话 为此会话创建的所有 URL 请求启用 DNSSEC 如果不想在整个会话中启用 DNSSEC 也可以在请求级别执行此操作 首先 使用禁用 DNSSEC 验证的 默认配置创建会话 然后在请求中启用它 现在 只有在完成 DNSSEC 验证后 才会启动此会话任务 如果你是 Network.framework 客户端 你还可以要求 对你的连接进行 DNSSEC 验证 首先 当你创建一个参数对象时 需要 DNSSEC 验证 然后用参数对象创建 NWConnection 现在 当你启动连接时 只有在 DNSSEC 验证已完成 并且建立与已验证 IP 地址的 连接时 它才会进入就绪状态 启用 DNSSEC 后 只有经过验证的地址 才会用于建立连接 在 HTTPS 中 错误是通过 API 报告的 在 DNSSEC 验证失败不会返回错误 收到验证失败的响应 等于没有收到任何响应 如果有 DNS 提供商篡改响应 地址将无法通过身份验证检查 因此它们将被直接丢弃 当设备加入 DNS 提供商 未篡改响应的新网络时 验证将再次进行 解析将自动恢复正常

以下是一些可能导致 DNSSEC 故障的情况 更改原始 DNS 响应时 不匹配的签名 将无法通过 DNSSEC 检查 从而导致验证失败 当设备不能到达 任何预先安装的信任锚 并且不能从中建立信任链时 当网络不支持 DNSSEC 要求的必要协议时 如 TCP 上的 DNS 和 EDNS0 选项 会携带 DNSSEC 启用位 当签名域不支持 IPv6 时 由互联网服务提供商提供的 合成 IPv6 地址将无法通过验证 这就是如何使用 DNSSEC 对 DNS 响应进行身份验证 但如果它们仍然未加密 那网络上的任何人都可以看到它们 接下来 我们将谈一谈 如何用 DDR 自动启用 DNS 加密

在 iOS 14 和 macOS Big Sur 中 我们引入了加密 DNS 来帮助保护隐私 你可以使用 App 中的 NEDNSSettingsManager 或配置文件中的 DNSSettings 手动配置系统范围内的加密 DNS 你还可以使用 NWParameters 上的 PrivacyContext 为你的 App 选择加密 DNS 更多有关信息 请观看 “启用加密的 DNS” iOS 16 和 macOS Ventura 中 新增了可以自动使用的 加密 DNS 如果你的网络支持指定解析器的发现 也称为 DDR DNS 查询将自动使用 TLS 或 HTTPS 要使用加密 DNS 你的设备就需要知道 解析器支持 TLS 或 HTTPS 并且可能还需要 了解端口或 URL 路径 常见的机制 如 DHCP 或路由器广告 只提供普通的 IP 地址 DDR 是由 Apple 和其他行业合作伙伴 在 IETF 中开发的新协议 它为 DNS 客户端提供了一种 通过使用特殊的 DNS 查询 来了解这些必要信息的方法 当你的设备加入一个新的网络时 它会发出一个 _dns.resolver.arpa 的 服务绑定查询 如果 DNS 服务器支持 DDR 它将回复一个或多个配置 然后 设备使用此信息 建立到指定解析器的加密连接 它验证未加密解析程序的 IP 地址 是否包含在 指定解析程序的 TLS 证书中 这样做是为了确保未加密的解析器 和加密的解析器属于同一个实体 如果一切正常 设备现在默认使用加密 DNS

DDR 一次只适用于单个网络 只有在当前网络支持的情况下 你的设备才会自动使用加密 DNS 同样重要的是要注意 如果你的 DNS 服务器的 IP 地址 是私有 IP 地址 那么 DDR 将不起作用 这是因为 TLS 证书中 不允许此类 IP 地址 因为无法验证它们的所有权 在 iOS 16 和 macOS Ventura 中 我们还支持在使用 加密 DNS 进行配置设置时 使用 NEDNSSettingsManager 或 DNSSettings 配置文件 来指定客户端验证的能力

客户端身份验证允许在企业环境中 使用加密 DNS 服务器 在这种环境中 服务器需要在允许访问之前 验证客户端 现在你可以使用 NEDNSSettings 的 identityReference 属性 来配置客户端证书 这就像 VPN 的客户端证书一样 这些规定适用于 TLS 上的 DNS 和 HTTPS 上的 DNS 这是保护 DNS 的路径 使用 DNSSEC 对你的域进行签名 并要求在你的 App 中 进行 DNSSEC 验证 以验证你的 IP 地址 在网络上启用 DDR 以便客户端可以自动切换到 加密 DNS 以此更好地保护用户隐私 在需要更好地访问控制的企业中 采用客户端身份验证 我期待将来能有一个 由你帮忙建立的 更安全的 DNS 基础 感谢收看