5.2 TLS与DNS安全

5.2 TLS 与 DNS 安全

本节摘要：TLS 把第 4 章的密码学原语装配成传输加密标准——握手用非对称与证书定身份、会话用对称密钥跑数据；DNS 则是把域名翻译成地址的寻址系统，它长期明文且无校验，DNSSEC 给应答加签名、加密 DNS 给查询加保密。本节拆解 TLS 握手时序、DNS 的攻防对照，以及两者的部署要点。承接 5.1 节的分层骨架，本节聚焦传输层与应用层的两个标准件，通往 5.3 节的零信任。

互联网的信任由谁来装配

第 4 章的零件是散的：对称加密、非对称加密、哈希、签名、证书。散件装不成通信安全——两台从未谋面的机器要建立一条加密信道，谁先出招、身份怎么验、密钥怎么换、算法怎么商量，每一步都得有公认流程。TLS（传输层安全协议，SSL 的继任者）就是这套流程。与此同时，另一件基础设施被大多数人无视：DNS。你访问的每个域名都先经它翻译，而它几十年来默认明文、应答不验真伪——5.1 节说过低层失守顶托高层，DNS 正是那个被顶托得最惨的公共底座。本节把两件标准件并排鉴定。

验明正身：TLS 握手

以当前主流的 TLS 1.3 为例，握手的骨架是"证书定身份、非对称换密钥、对称跑数据"：

三个设计点值得咀嚼。其一，证书校验在密钥协商之前——先确认对面是谁，再商量秘密，顺序反了就是给中间人开门（4.4 节"内网关校验"的坑在这里闭环）。其二，TLS 1.3 砍掉了所有已知不安全的选项（旧版本允许降级到弱算法，2.2 节的降级攻击由此而来），"选择少"是安全性的来源。其三，握手完成后抓包只能看到密文与元数据（域名可能还在 SNI 里裸奔，加密 SNI 正在补这个洞）——这就是 3.2 节说"防火墙看不到加密内容"的技术根源。

部署侧用一条命令验自己的站点配置：

$ openssl s_client -connect api.example.cn:443 -tls1_3 </dev/null 2>/dev/null | grep -E "subject|Verify"
subject=CN = api.example.cn
Verify return code: 0 (ok)     # 证书链校验通过; 返回非 0 则逐级排查链缺失
​

常见部署缺陷清单：证书链没配全（自己测通过、部分老客户端失败）、混着启用弱协议版本（TLS 1.0/1.1 该关）、密码套件挑了 CBC 老模式（换 AEAD）、忘配 HSTS（用户首次访问前的窗口仍可被劫持）。

验明正身：DNS 的攻防对照

DNS 的原始设计有两个历史包袱：明文（查询内容沿途可见）与无认证（应答不验签）。由此衍生出两条攻击线与对应的补丁：

DNSSEC 的原理不是加密查询，而是给应答签名：域的持有者用私钥签应答记录，验证方沿 DNS 层级（根到顶级域到你的域）逐级验证签名链——本质是把 4.4 节的 PKI 思想复制进了寻址体系。它防篡改、不保密，恰好与加密 DNS 防窃听、不防篡改互补，所以两者是组合关系不是替代关系。

加密 DNS（DoH 走 HTTPS、DoT 走专用端口）把查询装进加密信道，围观者只能看到"你在跟某个解析服务说话"，看不到问了什么。它的副作用值得点名：员工可以用它绕过企业 DNS 策略（3.2 节的出口 DNS 拦截会漏），企业侧要么在出口识别并纳管 DoH，要么默认阻断未批准的加密解析——安全增强技术与管理策略的这种互相追逐，在安全工程里是常态而非例外。

工程实践要点

全员 TLS 是底线，不是加分项。 公网服务全站 HTTPS 加 HSTS，内部服务按 4.4 节的内部 PKI 路线保持校验常开。留任何一段明文通信，就给 2.2 节的中间人留了一块操场。

DNS 配置进资产清单。 大多数组织说不清自己的域名在哪家注册商、解析在哪个服务、有没有开 DNSSEC——而这三项决定了"域名被劫持要多久能发现"。把 DNS 三要素（注册商、解析服务、DNSSEC 状态）纳入 1.3 节的资产清单，是性价比最高的低垂果实。

⚠️ 常见坑：把开 DNSSEC 当成"DNS 安全做完"。DNSSEC 只保证应答真伪，防不了注册商账户被钓（攻击者直接改解析指向），后者要靠注册商锁、转移密码独立、账户双因素来防。签名保护的是记录，不是账户。

💡 关键直觉：TLS 回答"内容在途中没被看也没被改"，DNSSEC 回答"你到达的地址是真的"，加密 DNS 回答"你的访问行为没被围观"。三个问题各自独立，一个补丁只堵一个洞。

鉴定结论

• TLS 握手的顺序是安全性的全部：先验身份再换密钥，1.3 的"少选项"策略消灭了降级空间；
• DNS 的两个历史包袱对应两块补丁：DNSSEC 防伪造、加密 DNS 防窃听，组合使用各管一段；
• DNS 三要素进资产清单、注册商账户加锁，比任何解析层加固都更先救命；
• 标准件齐了。下一节看架构范式的更替：当"内网"消失在云里，VPN 的位置信任如何被零信任的逐次判定取代。

附卷：TLS 部署体检单与 DNS 三件套

TLS 配置对不对，不用猜，六项体检照着跑：

体检一 协议版本: 确认只开 TLS 1.2 与 1.3, 旧版本全部关闭
体检二 证书链:   用命令行走一遍链校验, 而不是只看浏览器能开
体检三 套件:     只留 AEAD 类套件, CBC 老模式与 RC4 清空
体检四 重定向:   确认 http 到 https 的跳转发生在同一域名内
体检五 HSTS:     加载后无 http 首跳窗口, max-age 合理
体检六 续期:     续期为自动化, 到期前三十天有告警
​

六项里有五项是"关掉旧东西"。TLS 的运维哲学与 5.2 节正文的握手设计一脉相承：安全来自更少的选择。保留旧版本与老套件的理由几乎总是"有的老客户要用"——更好的解法是给老客户单独的接入通道，而不是让全员陪着降级。

DNS 侧把正文的三要素展开成可执行的三件套：注册商锁定（开启转移锁，变更需人工二次确认，防止域名被整体劫走）、解析分离（权威解析与递归解析职责分清，对外只暴露权威服务的必需记录）、DNSSEC 加开启记录监控（签名开启后配置告警，签名过期导致的解析失败是 DNSSEC 最常见的自伤）。三件套的共同点是把"没人盯的底层配置"变成"有人认领的资产"——5.2 节说 DNS 三要素进资产清单，落地形态就是这三行。

最后补一个监控视角：把"关键域名的解析结果"纳入日常拨测（从多个网络位置查询并比对），DNS 劫持与投毒的发现时间能从"用户投诉"提前到"拨测告警"。花的是每小时一次查询的成本，买的是寻址层的眼线——这是本节所有措施里性价比最高的一件。