第 28 讲：TLS、IPsec、防火墙与 DDoS 防御

一、安全放在哪一层

同一套密码学原语，可以部署在协议栈的任何一层。选择哪一层，决定了保护什么、不保护什么。

层	代表	保护范围	特点
应用层	PGP、Signal	⭐ 端到端，连服务器都看不到	最强，但每个应用要自己实现
⭐ 传输层	TLS	进程到进程的数据	⭐ 最成功，应用改动小
网络层	IPsec	⭐ 所有 IP 流量（含 UDP、ICMP）	对应用完全透明，配置复杂
链路层	WPA2/3、MACsec	⭐ 仅一跳	只保护本地无线/有线段

⭐ 关键判断：

层次越高 → 保护范围越"端到端"，但需要每个应用配合
层次越低 → 对应用越透明，但保护范围越有限

⭐ TLS 处在最佳平衡点：它保护完整的端到端应用数据，
   同时应用只需换一个 socket 库

⚠️ 一个重要区分：

HTTPS（TLS）：  保护你与【服务器】之间的通道
              ⭐ 服务器本身能看到全部明文

Signal（应用层端到端加密）： 连服务器都看不到内容
              ⭐ 这是两个完全不同的威胁模型

二、TLS

2.1 位置

   ┌────────────────┐
   │   应用（HTTP）   │
   ├────────────────┤
   │   ⭐ TLS        │   ← 位于应用层与传输层之间
   ├────────────────┤
   │      TCP       │
   └────────────────┘

TLS 向上提供的接口几乎与 socket 相同，这是它能被广泛采用的关键——应用几乎不用改。

2.2 TLS 1.2 握手（4 次往返中的 2 个 RTT）

客户端                                          服务器
   │                                              │
   │─① ClientHello ──────────────────────────────▶│
   │    支持的 TLS 版本、密码套件列表、⭐ 客户端随机数  │
   │                                              │
   │◀─② ServerHello ──────────────────────────────│
   │    选定的版本与密码套件、⭐ 服务器随机数          │
   │◀─③ Certificate（服务器证书链）─────────────────│
   │◀─④ ServerKeyExchange（DH 参数，用于前向保密）───│
   │◀─⑤ ServerHelloDone ──────────────────────────│
   │                                              │
   │  ⭐ 验证证书（见 2.5 节）                       │
   │                                              │
   │─⑥ ClientKeyExchange ────────────────────────▶│
   │─⑦ ChangeCipherSpec ─────────────────────────▶│
   │─⑧ Finished（⭐ 前面所有握手消息的 MAC）─────────▶│
   │                                              │
   │◀─⑨ ChangeCipherSpec ─────────────────────────│
   │◀─⑩ Finished ─────────────────────────────────│
   │                                              │
   │◀══════ 加密的应用数据 ═══════════════════════▶│

⭐ Finished 消息的作用（重要考点）：它包含此前所有握手消息的 MAC。

若中间人篡改了任何一条握手消息（例如把密码套件列表改成只有弱算法）
→ 双方计算出的 Finished 值不一致
→ ⭐ 握手失败
→ 这就是【降级攻击】的防御

2.3 密钥派生

客户端随机数 + 服务器随机数 + 预主密钥
        ↓ ⭐ 密钥派生函数（KDF）
主密钥（Master Secret）
        ↓
四个密钥：
   ⭐ 客户端→服务器 的【加密】密钥
   ⭐ 客户端→服务器 的【MAC】密钥
   ⭐ 服务器→客户端 的【加密】密钥
   ⭐ 服务器→客户端 的【MAC】密钥

为什么要四个不同的密钥？

① 两个方向用不同密钥 → ⭐ 防止把 A→B 的报文【反射】回 A 冒充 B→A
② 加密和 MAC 用不同密钥 → ⭐ 密码学原则：【一个密钥只用于一个目的】

📌 随机数的作用：让每次会话的密钥都不同 → 防重放（第 27 讲的 nonce 思想）。

2.4 TLS 1.3 的三项关键改进 ⭐

TLS 1.2 握手:  ⭐ 2 个 RTT
TLS 1.3 握手:  ⭐ 1 个 RTT（会话恢复时 0 RTT）

改进 1：把密钥交换提前

客户端在 ⭐ 第一条消息 里就【猜测】服务器会选哪个密钥交换算法，
直接把自己的 DH 公开值一起发过去

→ 服务器第一次回复就能完成密钥协商
→ ⭐ 省掉一个完整的 RTT

改进 2：大幅删减密码套件 ⭐

TLS 1.3 移除了：

❌ RSA 密钥交换（⭐ 因为它没有前向保密）
❌ 静态 Diffie-Hellman
❌ CBC 模式（⭐ 一系列填充攻击的来源：BEAST、Lucky13、POODLE）
❌ RC4、3DES、MD5、SHA-1
❌ 压缩（⭐ CRIME 攻击的来源）
❌ 重协商

⭐ 只保留 AEAD（AES-GCM、ChaCha20-Poly1305）
⭐ 密钥交换只保留【临时】DH（ECDHE）

🎯 TLS 1.3 的设计哲学：不是"增加更多选项"，而是"删掉所有不安全的选项"。 历史上大量 TLS 漏洞的根源，是协议提供了太多可选项，而实现和配置总会选错。减少选择本身就是一种安全机制。

改进 3：加密更多握手内容

TLS 1.3 从 ServerHello 之后就开始加密，证书本身也被加密——中间设备无法看到你在访问哪个站点的证书。

⚠️ 例外：SNI（Server Name Indication）在标准 TLS 1.3 中仍是明文（因为服务器需要它来选择证书）。ECH（Encrypted Client Hello） 正在解决这个最后的泄露点。

2.5 ⭐ 前向保密（Forward Secrecy）

问题：

若用【RSA 密钥交换】：
   客户端用服务器的 RSA 公钥加密预主密钥并发送
   
⚠️ 攻击者可以【今天录下全部加密流量】，
   ⭐ 若干年后拿到服务器的私钥（入侵、法律强制、算法被破）
   → 解密预主密钥 → ⭐ 解密【历史上所有】的会话

解法：临时 Diffie-Hellman（ECDHE）

⭐ 每次会话生成【全新的、临时的】DH 密钥对
⭐ 会话结束后【立即销毁】私钥值

→ 服务器的长期私钥只用于【签名】（证明身份），不用于加密密钥
→ ⭐ 即使长期私钥泄露，也无法解密任何历史会话

⭐ 前向保密的精确含义：长期密钥的泄露，不会危及此前已完成的会话。

📌 TLS 1.3 强制要求前向保密——这正是它删除 RSA 密钥交换的原因。

2.6 证书验证的六个步骤 ⭐

客户端收到服务器证书后必须依次检查：

① ⭐ 签名验证：用颁发者的公钥验证证书上的签名
② ⭐ 信任链：沿链一直验证到一个【预置在系统中的根 CA】
③ ⭐ 有效期：当前时间在 notBefore 与 notAfter 之间
④ ⭐ 域名匹配：证书的 SAN（主体备用名）中包含你要访问的域名
⑤ ⭐ 吊销状态：通过 CRL 或 OCSP 检查证书是否已被吊销
⑥ ⭐ 用途与约束：扩展字段允许该证书用于服务器认证

⚠️ 常见的实现错误：

只验证了①②而忘了④ → ⭐ 攻击者用自己合法域名的有效证书就能冒充你的银行
   （这是移动 App 中最常见的 TLS 实现漏洞）

跳过⑤（因为 OCSP 查询慢） → ⭐ 已吊销的证书仍被接受
   缓解方案：OCSP Stapling（服务器主动附上 CA 签名的状态凭据）

📌 证书吊销是 PKI 至今没有完美解决的问题：CRL 太大，OCSP 增加时延且泄露隐私（CA 知道你访问了哪个网站），OCSP Stapling 依赖服务器配合。实践中的妥协是签发短有效期证书（Let’s Encrypt 的 90 天），用"很快过期"代替"及时吊销"。

2.7 会话恢复与 0-RTT

完整握手代价高（公钥运算 + RTT）
⭐ 会话恢复：用上次协商出的密钥材料（PSK），跳过公钥运算

TLS 1.3 的 0-RTT：⭐ 客户端在【第一个】分组里就带上应用数据

⚠️ 0-RTT 的安全代价：

⭐ 0-RTT 数据【没有重放保护】
攻击者可以录下并重放它

→ 因此【只能用于幂等请求】（第 5 讲的幂等性在这里成为安全约束）
→ 绝不能用于"转账"、"下单"这类操作

📌 这是一个漂亮的呼应：第 5 讲讲 HTTP 方法的幂等性时，它只是一个"能否安全重试"的工程属性；到了这里，它变成了一条硬性的安全边界。

三、IPsec 与 VPN

3.1 两个协议

	AH（认证首部）	⭐ ESP（封装安全载荷）
认证与完整性	✅	✅
机密性（加密）	❌	⭐ ✅
实际使用	极少	⭐ 几乎全部

⚠️ AH 还有一个致命问题：它对 IP 头部的部分字段做认证，因此无法穿越 NAT（NAT 会改写这些字段，第 18 讲的分层污染）。这是它被淘汰的主要原因。

3.2 两种模式 ⭐

传输模式（Transport Mode）：

┌────────┬─────────┬──────┬──────┐
│ 原IP头  │ ESP 头  │ 载荷  │ ESP尾│
└────────┴─────────┴──────┴──────┘
             ⭐ 只加密载荷，原 IP 头暴露

用于：主机到主机的直接安全通信

隧道模式（Tunnel Mode） ⭐：

┌────────┬─────────┬──────────────────┬──────┐
│ 新IP头  │ ESP 头  │ ⭐ 整个原始 IP 数据报│ ESP尾│
└────────┴─────────┴──────────────────┴──────┘
                    ⭐ 连原 IP 头一起加密

用于：⭐ 网关到网关的 VPN（这是 VPN 的实现方式）

⭐ 隧道模式的关键价值：它隐藏了真实的源和目的地址，观察者只能看到两个 VPN 网关在通信，看不到内部的通信关系。

3.3 VPN 的工作方式

分支机构                    公网                     总部
   │                                                  │
[主机]──▶[VPN 网关]═══⭐加密隧道═══▶[VPN 网关]──▶[服务器]
         用新 IP 头封装                 解封装还原

IKE（Internet Key Exchange） 负责自动协商密钥与安全关联（SA）——相当于 IPsec 的"握手"。

3.4 IPsec vs TLS

	IPsec	TLS
层次	网络层	传输层之上
保护范围	⭐ 所有 IP 流量（含 UDP、ICMP）	仅该条 TCP 连接
对应用透明	⭐ 完全透明	需要应用使用 TLS 库
部署	⭐ 需要修改操作系统/网关配置	应用自己就能启用
典型用途	站点到站点 VPN、远程接入	HTTPS、几乎所有互联网应用

📌 为什么 TLS 赢得了互联网：**因为它不需要网络管理员配合。**一个网站开发者今天就能给自己的站点加上 HTTPS，而部署 IPsec 需要两端的网络管理员协调。这又是"可部署性压倒理论优势"的一个例子。

四、防火墙

防火墙：隔离内部网络与公网，选择性地放行分组。

4.1 三类防火墙

1️⃣ 无状态分组过滤器（Stateless Packet Filter）

逐个分组独立判断，依据：
   源/目的 IP、协议号、源/目的端口、TCP 标志位

例：拒绝所有目的端口 23（Telnet）的入站分组

⚠️ 致命局限：它不记得任何上下文。

要允许内部主机访问外部 Web，必须放行【所有】源端口 80 的入站分组
→ ⭐ 攻击者只要把源端口设成 80，就能扫描内网

2️⃣ 有状态分组过滤器（Stateful） ⭐

⭐ 维护一张【连接跟踪表】，记录每条 TCP 连接的状态

规则变成：「只允许属于【内部发起的、已建立的】连接的入站分组」

→ 攻击者伪造的源端口 80 的分组，因为找不到对应的连接表项，被丢弃 ✅

📌 今天所有实用的防火墙都是有状态的。（NAT 天然具有类似的效果，这是第 18 讲说的"副作用式安全"。）

3️⃣ 应用网关（Application Gateway / 代理）

在【应用层】做决策，能理解协议语义

例：只允许特定用户使用 Telnet；扫描 HTTP 请求中的 SQL 注入

✅ 能力最强（能看懂内容）
❌ ⭐ 每个应用要一个网关；性能开销大；⭐ 对加密流量无能为力（除非做 TLS 中间人解密）

4.2 防火墙的局限 ⭐

① ⭐ IP 欺骗：无法确认分组真的来自它声称的地址
② ⭐ 加密流量：HTTPS 内部的内容对防火墙不可见
③ ⭐ 内部威胁：对已经在内网里的攻击者无效
④ 隧道绕过：把任意流量封装进 HTTPS 或 DNS 就能穿过
⑤ 权衡：规则越严格，误伤合法业务越多

📌 ⭐ 一个重要的现代认识：“内网可信、外网不可信"的边界模型已经不成立了（云、移动办公、供应链攻击）。取而代之的是零信任（Zero Trust）：不因为一个请求来自内网就信任它，每一次访问都要认证和授权。

五、入侵检测系统（IDS/IPS）

IDS：检测到异常 → ⭐ 【告警】
IPS：检测到异常 → ⭐ 【阻断】

两条技术路线

	基于特征（Signature-based）	基于异常（Anomaly-based）
原理	匹配已知攻击的特征库	学习正常流量基线，检测偏离
优点	⭐ 误报率低，可解释	⭐ 可能发现未知攻击（0-day）
缺点	⭐ 对未知攻击完全无效；特征库要不断更新	⭐ 误报率高；“正常"难以定义

⚠️ 基于异常的方法在实践中的困难：网络流量本身高度不规则（新应用上线、业务高峰、软件更新），区分"异常"与"新的正常"极其困难。误报过多会导致运维人员忽略告警——这本身就成了一个安全问题（告警疲劳）。

六、DDoS 防御

6.1 攻击规模的现实

现代 DDoS 攻击流量可达 数 Tbps（利用僵尸网络与反射放大，第 4、7 讲）。

⚠️ 一个诚实的结论：**没有任何单一组织能靠自己的接入带宽扛住这种规模的攻击。**如果攻击流量超过你的接入链路容量，你在自己机房里做什么都没用——链路已经被填满了。

6.2 防御手段

手段	说明
⭐ 上游清洗（Scrubbing）	把流量牵引到有巨大容量的清洗中心，过滤后回注干净流量
⭐ Anycast 分散	用任播（第 19 讲）把攻击流量分散到全球多个节点，各自消化
速率限制	对单 IP、单连接的请求速率设限
SYN Cookie	抵抗 SYN 洪泛（第 14 讲）
⭐ BCP 38 入口过滤	从源头阻止 IP 欺骗——最根本，但需要全球 ISP 协同
CDN 吸收	内容分发网络天然具有巨大的分布式容量（第 6 讲）

📌 ⭐ 注意 BCP 38 的性质：它是最有效的根本解法，但部署它的 ISP 自己不直接受益（受益的是别人），这是典型的激励错配——与 IPv6、BGPsec 是同一类问题（第 19、21 讲）。

🎯 本课程反复出现的一个主题：互联网上最重要的一些安全改进，技术上早已就绪，卡住它们的是协同与激励问题，不是技术问题。

七、例题（Worked Example）

题目：某公司要保护分支机构与总部之间的全部通信，同时也要保护员工用浏览器访问总部 Web 应用。

(a) 这两个需求分别更适合用 IPsec 还是 TLS？为什么？ (b) 若使用 IPsec，应该用传输模式还是隧道模式？ (c) 公司的 Web 应用配置了 TLS 1.2 并使用 TLS_RSA_WITH_AES_128_CBC_SHA 密码套件。指出三个问题。 (d) 安全团队要求防火墙检查所有出站 HTTPS 流量中是否包含敏感数据外泄。这在技术上如何实现？有什么代价？

解答：

(a)

⭐ 分支到总部的【全部通信】 → IPsec
   理由：需要保护【所有 IP 流量】，包括那些不使用 TLS 的老旧内部协议、
        文件共享、数据库连接、打印服务、ICMP 等。
        IPsec 在网络层工作，⭐ 对所有应用完全透明，无需逐个改造。

⭐ 员工浏览器访问 Web 应用 → TLS
   理由：浏览器原生支持，无需在员工设备上安装和配置 VPN 客户端；
        保护范围恰好是需要保护的那条 HTTP 会话；
        ⭐ 部署成本极低（配一张证书即可）。

(b) ⭐ 隧道模式。

因为这是网关到网关的场景：两端各有一个 VPN 网关，中间是公网。

隧道模式把【整个原始 IP 数据报】封装并加密，加上新的外层 IP 头（网关地址）
⭐ 收益：① 内部主机无需任何配置或改造
        ② ⭐ 隐藏了内部网络的真实拓扑与地址
           （观察者只看到两个网关在通信）

传输模式只加密载荷、保留原 IP 头，适用于两台主机直接通信，不适合网关场景（原 IP 头是内网私有地址，无法在公网路由）。

(c) 三个问题：

① ⭐ RSA 密钥交换 → 【没有前向保密】
   一旦服务器私钥泄露，攻击者可以解密所有被录下的历史流量。
   应改为 ECDHE（TLS_ECDHE_RSA_WITH_...）。

② ⭐ CBC 模式 + SHA（MAC-then-Encrypt）
   这是 BEAST、Lucky13、POODLE 等一系列填充预言攻击的来源。
   应改为 AEAD 模式（AES-GCM 或 ChaCha20-Poly1305）。

③ ⭐ SHA-1 作为 MAC 算法，且整体停留在 TLS 1.2
   SHA-1 已被证明可构造碰撞。应升级到 ⭐ TLS 1.3，
   它只保留 AEAD + ECDHE，从协议层面消除了以上全部问题。

📌 推荐配置：TLS 1.3，或至少 TLS 1.2 + TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。

(d) 技术实现：TLS 中间人解密（TLS Interception / SSL Inspection）

① 在所有员工设备上安装公司自己的【根 CA 证书】
② 防火墙作为中间人：
   - 对外：以员工的身份与真实网站建立 TLS 连接
   - 对内：⭐ 用公司根 CA 【现场签发】一张该网站的证书，与员工浏览器建立连接
③ 防火墙因而能看到明文，执行 DLP（数据防泄漏）检查

代价（每一条都很严重）：

代价	说明
⭐ 它就是一次合法化的中间人攻击	公司现在能看到员工的所有 HTTPS 内容，包括个人银行、医疗、私人邮件
⭐ 削弱了安全性	防火墙的 TLS 实现往往弱于浏览器（不做完整的证书校验、支持过时套件），⭐ 反而扩大了攻击面
⭐ 单点风险	该根 CA 私钥一旦泄露，攻击者可冒充任何网站欺骗全公司设备
技术上被主动对抗	证书固定（certificate pinning）的应用会直接拒绝连接；QUIC/HTTP3 更难拦截
⭐ 法律与伦理问题	多数司法辖区要求明确告知并取得同意；部分类别的通信（医疗、法律）可能禁止拦截

📌 一个应当给出的专业建议：在解密全部流量之前，先考虑侵入性更低的替代方案——基于端点的 DLP（在设备上检查，不破坏传输安全）、只对特定高风险类别做拦截并明确豁免银行/医疗类站点、以及基于元数据（域名、流量模式）的检测。“技术上做得到"不等于"应当这么做”（第 17 讲讨论网络中立性时也是同一个判断）。

八、随堂自测

在应用层、传输层、网络层、链路层实现安全，各自保护什么范围？
HTTPS 和 Signal 的端到端加密有什么本质区别？
TLS 的 Finished 消息防的是什么攻击？原理是什么？
为什么 TLS 要派生四个密钥？
⭐ TLS 1.3 相比 1.2 的三项关键改进是什么？它的设计哲学是什么？
⭐ 什么是前向保密？为什么 RSA 密钥交换没有前向保密？
证书验证的六个步骤是什么？哪一步最常被实现者遗漏？
0-RTT 数据为什么只能用于幂等请求？
AH 为什么被淘汰？隧道模式相比传输模式的关键价值是什么？
无状态与有状态防火墙的关键区别是什么？举一个无状态防火墙失效的例子。
为什么说 BCP 38 是 DDoS 的根本解法却难以部署？

九、本讲要点回顾

安全层次的取舍：层越高越端到端但要应用配合；层越低越透明但保护范围越窄。TLS 在平衡点上。
TLS 1.2 需 2 RTT，TLS 1.3 只需 1 RTT（恢复时 0 RTT）。
⭐ Finished 消息覆盖所有握手消息的 MAC → 防降级攻击。
⭐ TLS 1.3 的哲学是"删掉所有不安全的选项”：只留 AEAD 与 ECDHE。
⭐ 前向保密 = 长期私钥泄露也无法解密历史会话，靠临时 DH 实现。
证书验证六步，⭐ 最常被遗漏的是"域名匹配”。
⭐ 0-RTT 无重放保护 → 只能用于幂等请求（幂等性从工程属性变成安全边界）。
IPsec：ESP 常用，AH 因无法穿 NAT 被淘汰；⭐ 隧道模式隐藏内部地址，是 VPN 的实现方式。
防火墙：无状态 → 有状态 → 应用网关；⭐ 都无法应对加密流量、IP 欺骗与内部威胁 → 零信任。
IDS：特征法误报少但看不见 0-day；异常法可能发现 0-day 但误报高。
⭐ DDoS 的根本解法（BCP 38）卡在激励错配而非技术——与 IPv6、BGPsec 同类。

十、自测答案

1. 应用层（PGP、Signal）：保护应用数据本身，端到端，连服务器都无法读取，但每个应用必须自己实现。传输层（TLS）：保护一条传输连接上的全部数据，端到端覆盖应用负载，但服务器能看到明文；应用只需换用 TLS 库。网络层（IPsec）：保护所有 IP 流量（包括 UDP、ICMP 和不支持加密的老协议），对应用完全透明，但需要修改操作系统或网关配置。链路层（WPA、MACsec）：只保护一跳，出了本地网段就是明文。

2. HTTPS 保护的是"你到服务器"的通道，服务器本身能看到全部明文——它防的是路径上的窃听者，不防服务器运营方。Signal 式的端到端加密在应用层加密，连服务器都只能看到密文，它防的威胁包括服务器本身被入侵、被强制交出数据或作恶。两者是不同的威胁模型，不能互相替代（Signal 也同时使用 TLS 传输）。

3. 防的是⭐ 降级攻击。Finished 消息包含此前所有握手消息的 MAC（用刚协商出的密钥计算）。如果中间人篡改了任何一条握手消息——例如把 ClientHello 中的密码套件列表删减为只剩弱算法——那么客户端和服务器各自看到的握手记录不同，计算出的 Finished 值就不一致，握手立即失败。

4. 四个密钥是：两个方向各自的加密密钥与 MAC 密钥。① 两个方向用不同密钥，防止攻击者把 A→B 方向的报文反射回 A 冒充 B→A 的合法报文；② 加密与 MAC 用不同密钥，遵循密码学基本原则「一个密钥只用于一个目的」——不同算法共用密钥可能产生难以预料的交叉攻击。

5. ① 握手压缩到 1 RTT（客户端在第一条消息中就猜测并附上 DH 公开值），会话恢复时可 0-RTT。② ⭐ 大幅删减密码套件：移除 RSA 密钥交换（无前向保密）、CBC 模式（填充攻击）、RC4/3DES/MD5/SHA-1、压缩（CRIME）、重协商，只保留 AEAD 与临时 DH。③ 加密更多握手内容（包括证书）。设计哲学是⭐ “不是增加更多选项，而是删掉所有不安全的选项”——因为历史上大量 TLS 漏洞的根源正是"协议提供了太多可选项，而实现和配置总会选错"，减少选择本身就是一种安全机制。

6. 前向保密指：长期密钥（服务器私钥）的泄露，不会危及此前已经完成的会话。RSA 密钥交换没有前向保密，是因为客户端用服务器的长期 RSA 公钥加密预主密钥并发送——攻击者只要今天录下全部流量，将来某天取得服务器私钥（入侵、法律强制、算法被破），就能解密预主密钥，进而解密全部历史会话。临时 DH（ECDHE）为每次会话生成全新的密钥对并在会话结束后销毁，长期私钥仅用于签名（证明身份）而不参与密钥加密，因而历史会话无法被回溯解密。

7. ① 用颁发者公钥验证签名；② 沿信任链追溯到预置的根 CA；③ 检查有效期；④ ⭐ 检查域名匹配（SAN 包含目标域名）；⑤ 检查吊销状态（CRL/OCSP）；⑥ 检查用途与约束扩展。⭐ 最常被遗漏的是第 ④ 步域名匹配——这是移动 App 中最常见的 TLS 实现漏洞：只验证了"这是一张由可信 CA 签发的有效证书"，却没验证"这张证书是签给我要访问的那个域名的"，于是攻击者用自己任意域名的合法证书就能冒充银行。

8. 因为 ⭐ 0-RTT 数据没有重放保护。它在完整握手完成之前就被发出，服务器此时还无法确认这是一次新鲜的、非重放的请求。攻击者可以录下这个分组并任意重放，服务器会重复处理它。对于幂等请求（GET 一个页面），重复执行不改变状态，无害；对于非幂等请求（转账、下单），重放意味着重复扣款。第 5 讲讲 HTTP 幂等性时它只是"能否安全自动重试"的工程属性，在这里它成为一条硬性的安全边界。

9. AH 被淘汰有两个原因：① 它不提供加密（只有认证与完整性），而实际需求几乎总是包含机密性；② ⭐ 它对 IP 头部的部分字段做认证，因此无法穿越 NAT（NAT 改写这些字段会导致认证失败）——在 NAT 无处不在的现实中这是致命的。隧道模式的关键价值是它把整个原始 IP 数据报（连同其头部）一起加密并封装进新的外层 IP 头，因此 ⭐ 隐藏了通信双方的真实内部地址与网络拓扑，观察者只能看到两个 VPN 网关在通信；同时内部主机无需任何改造。

10. 无状态过滤器逐个分组独立判断，不记录任何上下文；有状态过滤器⭐ 维护连接跟踪表，能判断一个入站分组是否属于"内部主动发起的、已建立的连接"。失效例子：为了让内部主机能访问外部网站，无状态防火墙必须放行所有源端口为 80 的入站 TCP 分组；攻击者只要把自己扫描分组的源端口设为 80，就能穿过防火墙探测内网。有状态防火墙会发现该分组不属于任何已建立的连接，直接丢弃。

11. BCP 38（入口过滤）要求每个 ISP 丢弃源地址不属于自己客户地址块的出站分组，从源头消除 IP 欺骗——而 IP 欺骗是反射放大攻击（DNS/NTP 放大）的必要前提。它之所以是根本解法，是因为它切断的是攻击能力本身而非攻击后果。难以部署的原因是⭐ 激励错配：部署过滤的 ISP 需要承担配置与维护成本，但受益的是被攻击的第三方，而不是自己——自己的网络并不因此更安全。这与 IPv6 部署（第 19 讲）、BGPsec 部署（第 21 讲）是完全相同的结构性问题：技术早已就绪，卡住的是协同与激励。

一、安全放在哪一层#

二、TLS#

2.1 位置#

2.2 TLS 1.2 握手（4 次往返中的 2 个 RTT）#

2.3 密钥派生#

2.4 TLS 1.3 的三项关键改进 ⭐#

2.5 ⭐ 前向保密（Forward Secrecy）#

2.6 证书验证的六个步骤 ⭐#

2.7 会话恢复与 0-RTT#

三、IPsec 与 VPN#

3.1 两个协议#

3.2 两种模式 ⭐#

3.3 VPN 的工作方式#

3.4 IPsec vs TLS#

四、防火墙#

4.1 三类防火墙#

4.2 防火墙的局限 ⭐#

五、入侵检测系统（IDS/IPS）#

两条技术路线#

六、DDoS 防御#

6.1 攻击规模的现实#

6.2 防御手段#

七、例题（Worked Example）#

八、随堂自测#

九、本讲要点回顾#

十、自测答案#