8. 安全考虑 (Security Considerations)
本文档描述的 DNS RRtype 的安全性依赖 DNSSEC 的安全性, 以验证 TLSA record 未被篡改. 如果恶意 DNS administrator 修改某个 domain name 的 A, AAAA 和/或 TLSA records, 除非 client 执行 PKIX certification path validation 并拒绝该 certificate, 否则 client 可能被引向一个看起来已获授权的未授权 server. 不过, 该 administrator 很可能原本也能从某个 CA 获得 certificate, 因此这不是额外威胁.
如果在 zone 中添加或修改 TLSA data 的认证机制弱于修改 A 和/或 AAAA records 的认证机制, 则能够把流量重定向到自己站点的 man-in-the-middle 可能利用较弱的认证机制, 在 TLS 中冒充被攻击的 host. 更好的 DNS 认证设计是对某个 domain name 的所有 DNS 添加和修改使用同等级别的认证.
Secure Socket Layer (SSL) proxies 有时会作为 TLS clients 的 man-in-the-middle. 在这些场景中, client 会新增一个 trust anchor, 其 private key 保存在 SSL proxy 上. proxy 拦截 TLS requests, 与目标 host 建立新的 TLS session, 并使用一个链到 proxy 安装在 client 中的 trust anchor 的 certificate 与 client 建立 TLS session. 在这类环境中, 使用 TLSA records 会阻止 SSL proxy 按预期工作, 因为 TLS client 从 DNS 得到的 certificate association 不会匹配 SSL proxy 与 client 使用的 certificate.
如果 server certificate 被吊销, 或者 server 与 trust anchor 之间链上的 intermediate CA certificate 被吊销, 匹配该被吊销 certificate 的 certificate usage 2 TLSA record 实质上会覆盖吊销结果, 因为 client 会把该被吊销 certificate 当作 trust anchor, 从而不检查其吊销状态. 因此, domain administrators 必须确保 certificate usage 2 的 TLSA records 中使用的 keys 或 certificates 确实可作为可靠的 trust anchors.
如果 administrator 想停止使用某个 TLSA record, 可以直接从 DNS 中删除它. 普通 clients 会在 TTL 过期后停止使用该 TLSA record. 在已删除 TLSA record 的 RRsig 到期后, 针对该 TLSA record 的 replay attacks 不再可能.
8.1. DANE 与公共 CA 的比较 (Comparing DANE to Public CAs)
DANE TLSA 与公共 CA 模型的安全属性既有相似处, 也有差异. DNSSEC 通过把 DNSKEY, DS 或 DLV resource record 与关联的 RRSIG record 组合起来形成 certificate, 并从 client 的 trust anchors 到目标 RR 建立 signing chain. TLSA RRtype 允许 DNSSEC PKI hierarchy 中的 keys 对特定 host name, protocol 和 port 的 PKIX certificates 中封装的 keys 进行认证.
DNSKEY 能签署的内容天然受限. 例如, "example.com" 的 DNSKEY 被攻破并不会提供攻击 "example.org" 的路径. 相比之下, public CAs 通常不限制可签署的名称, 因此任一 CA 被攻破都可能让 attacker 为 DNS 中的任何名称生成 certificate. 由于 TLSA certificate association 被限制到其关联的 name, protocol 和 port, 即使签署 certificate 的 public CAs 没有这种限制, 该 PKIX certificate 也受到同样约束.
8.2. DNS 缓存 (DNS Caching)
本协议的实现严重依赖 DNS, 因而容易受到基于 TLSA records 与 DNS names 被故意错误关联的安全攻击. 实现需要谨慎判断 TLSA record 与 DNS name 之间关联的持续有效性. 特别是, 实现应该依赖其 DNS resolver 来确认 TLSA record 与 DNS name 之间的关联, 而不是缓存此前 domain name lookup 的结果.
如果实现为了提升性能而缓存 domain name lookup 的结果, 则必须遵守 DNS 报告的 TTL information. 未遵守此规则的实现可能在此前访问过的 server 的 TLSA record 变化时被 spoof, 或被拒绝访问, 例如 certificate rollover 期间.
8.3. 外部 DNSSEC 验证器 (External DNSSEC Validators)
由于目前最常部署的 stub resolvers 缺少 DNSSEC 支持, 一些 ISPs 开始在其提供给客户的 recursive resolvers 中检查 DNSSEC, 并在适当时设置 Authentic Data (AD) flag. 支持 DNSSEC 的 clients 可能使用这些数据, 而忽略 DNSSEC data 是在外部完成验证的事实.
由于 client 与 recursive resolver 之间通常没有对 recursive resolver 的认证, 也没有对数据和 AD flag 的完整性保护, attacker 可以轻易 spoof 这些信息. 即使 host 与外部 validating resolver 之间存在安全通信, 外部 validator 仍有被攻破的风险. 因此, 即便存在通往外部 validator 的安全路径, DNSSEC validation 也最好在 host 本机执行.