Chapter 8-2：从密码学工具到网络纵深防御

传统 TCP/IP 协议栈主要解决数据如何传输、丢失后如何恢复、分组如何寻找路径以及多台设备如何共享网络等问题。然而，数据能够正确到达，并不意味着通信过程是安全的。攻击者仍然可能窃听内容、篡改数据、冒充通信对象，或者利用合法开放的网络接口发动攻击。

网络安全因此不能依赖某一种密码算法，而必须把不同安全机制部署在不同层次：安全电子邮件保护一条消息，TLS 保护一条连接，IPsec 保护网络层数据报，防火墙控制流量能否进入网络，IDS 则负责发现已经出现的异常行为。

  flowchart TD
    A[密码学基本工具] --> B[安全电子邮件]
    A --> C[TLS]
    A --> D[IPsec]
    B --> E[保护消息]
    C --> F[保护连接]
    D --> G[保护IP数据报]
    G --> H[防火墙控制访问]
    H --> I[IDS检测攻击]
  

这套体系体现了网络安全的基本思想：密码算法提供基础能力，安全协议负责组合这些能力，防火墙和检测系统则将安全策略落实到实际网络运行中。

❗ 本节核心结论： 网络安全不是单一算法能够解决的问题，而是一套覆盖消息、连接、数据报和网络边界的分层防御体系。

1. 网络通信需要解决哪些安全问题

一套完整的安全通信机制通常需要考虑以下目标：

• 保密性：未经授权的第三方不能读取通信内容。
• 完整性：数据在传输过程中被修改后能够被发现。
• 身份认证：通信双方能够确认对方的真实身份。
• 访问控制：只有符合安全策略的流量才能进入网络或访问服务。
• 攻击检测：系统能够识别扫描、入侵、恶意载荷和异常流量模式。
• 抗重放能力：攻击者不能通过重复发送旧的合法数据来欺骗系统。

这些目标不能全部由同一种技术实现。例如，加密可以隐藏内容，却不一定证明发送者身份；数字签名可以证明消息来源，却不一定隐藏消息；防火墙可以阻挡不符合规则的流量，却不能保证被允许访问的应用程序不存在漏洞。

因此，真正的网络安全必须把多种机制组合起来。

❗ 本节核心结论： 保密性、完整性、身份认证、访问控制和攻击检测是不同目标，必须由不同机制分工完成。

2. 公钥密码与数字签名

2.1 公钥密码的基本结构

公钥密码系统为每个实体准备一对相互关联的密钥：

• 公钥 (K^+)：可以公开。
• 私钥 (K^-)：必须由持有者秘密保存。

当 Alice 希望向 Bob 发送机密信息时，可以使用 Bob 的公钥加密：

[
C=K_B^+(m)
]

Bob 收到密文后，再使用自己的私钥解密：

[
m=K_B^-(C)
]

这里的关键并不是“公钥加密后绝对不能处理”，而是只有掌握对应私钥的人才能完成正确解密。由于 Bob 的私钥不应被其他人获得，消息便只能由 Bob 读取。

公钥密码解决了传统对称加密中的密钥分发困难。对称加密要求双方事先拥有同一把秘密密钥，但在双方还没有安全信道时，这把密钥本身也无法直接安全传递。公钥机制允许发送者使用接收者公开的公钥保护一个新生成的秘密，从而建立后续通信所需的共享密钥。

2.2 数字签名的作用

数字签名的目标不是隐藏消息，而是证明消息的来源并检测内容是否被修改。

设 Bob 要签署消息 (m)，首先计算消息摘要：

[
h=H(m)
]

随后使用自己的私钥对摘要进行签名：

[
s=K_B^-(h)
]

Bob 发送的内容为：

[
(m,s)
]

Alice 收到后执行以下步骤：

1. 对收到的消息重新计算 (H(m))。
2. 使用 Bob 的公钥验证签名。
3. 比较签名对应的摘要与自己计算出的摘要。
4. 若二者一致，则消息在签名后没有发生变化，并且签名由掌握 Bob 私钥的人生成。

数字签名通常只处理消息摘要，而不直接处理整个消息。原因在于公钥运算的成本较高，而哈希函数可以快速把任意长度的数据压缩为固定长度的摘要。可以将这一过程理解为：哈希函数先为消息生成指纹，发送者再使用私钥在指纹上盖章。

2.3 公钥加密与数字签名的区别

可以概括为：

• 想让谁读取，就使用谁的公钥加密。
• 想证明是谁发送，就使用谁的私钥签名。

数字签名本身不提供保密性。消息可以继续以明文形式传输，只是在旁边附加签名。旁观者仍然可能看到消息，但不能在不破坏签名验证结果的情况下修改内容。

❗ 本节核心结论： 公钥加密以接收者为中心，解决“谁能读取”；数字签名以发送者为中心，解决“谁发送、是否被修改”。

3. 安全电子邮件：混合加密与签名的组合

电子邮件可能在服务器中长期保存，也可能经过多个中间系统转发，因此需要同时考虑保密性、完整性和发送者身份。

3.1 只实现邮件保密性

假设 Alice 向 Bob 发送邮件 (m)。Alice 不直接使用 Bob 的公钥加密整封邮件，而是：

1. 随机生成对称会话密钥 (K_S)。
2. 使用 (K_S) 加密邮件正文：

[
C=E_{K_S}(m)
]

3. 使用 Bob 的公钥加密会话密钥：

[
E=K_B^+(K_S)
]

4. 将 (C) 和 (E) 一起发送给 Bob。

Bob 收到后：

1. 使用自己的私钥恢复 (K_S)。
2. 使用 (K_S) 解密邮件正文。

这种方式称为混合加密。它让两种密码算法分别承担自己擅长的任务：

• 对称加密速度快，适合处理大量正文。
• 公钥加密适合解决会话密钥的安全传递问题。

3.2 实现完整性和身份认证

Alice 对邮件进行签名时，先计算：

[
h=H(m)
]

再使用自己的私钥生成签名：

[
s=K_A^-(h)
]

Bob 使用 Alice 的公钥验证签名。若验证成功，说明邮件内容未被修改，并且签名由 Alice 的私钥生成。

然而，这种方式并不隐藏邮件正文。任何能够截获邮件的人仍可能读取内容。

3.3 同时实现三种安全目标

为了同时获得保密性、完整性和身份认证，需要先签名，再加密。

  sequenceDiagram
    participant A as Alice
    participant N as 不可信网络
    participant B as Bob

    A->>A: 计算H(m)
    A->>A: 使用Alice私钥签名
    A->>A: 生成会话密钥KS
    A->>A: 使用KS加密消息和签名
    A->>A: 使用Bob公钥加密KS
    A->>N: 发送密文和加密后的KS
    N->>B: 转交数据
    B->>B: 使用Bob私钥恢复KS
    B->>B: 解密消息和签名
    B->>B: 使用Alice公钥验证签名
  

Alice 在这一过程中使用了三种密钥：

Bob 则按照相反顺序处理：

1. 使用自己的私钥恢复会话密钥。
2. 使用会话密钥解密邮件与签名。
3. 使用 Alice 的公钥验证签名。
4. 重新计算邮件摘要并进行比较。

3.4 公钥真实性问题

上述方案仍依赖一个重要前提：Alice 必须确定自己获得的公钥确实属于 Bob。

攻击者如果能够把自己的公钥伪装成 Bob 的公钥，就可能让 Alice 把会话密钥加密给攻击者。这说明公钥本身并不天然可信，还需要数字证书、证书颁发机构和公钥基础设施建立身份与公钥之间的可信绑定。

❗ 本节核心结论： 安全电子邮件通过“发送者私钥签名、对称密钥加密正文、接收者公钥加密会话密钥”同时实现保密性、完整性和身份认证。

4. TLS：保护一条应用通信连接

4.1 TLS 与 TCP 的分工

TLS 广泛应用于 HTTPS，其经典协议结构为：

1
2
3
4
5
6
7

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

TCP 负责：

• 可靠传输；
• 按序交付；
• 丢失重传；
• 流量控制；
• 拥塞控制。

TLS 负责：

• 数据加密；
• 完整性验证；
• 对端身份认证；
• 安全密钥建立。

TCP 所说的“可靠”，只意味着字节能够按序、完整地到达，并不意味着这些字节没有被攻击者读取或恶意修改。因此，TCP 的可靠性不能代替 TLS 的安全性。

4.2 TLS 握手

TLS 在传输应用数据前，需要通过握手建立安全参数。一个简化流程包括：

1. 客户端建立底层连接。
2. 客户端发送 Client Hello。
3. 服务器返回 Server Hello。
4. 服务器发送数字证书。
5. 客户端验证服务器身份。
6. 双方完成密钥交换。
7. 双方通过 KDF 派生会话密钥。
8. 双方验证握手内容未被篡改。
9. 开始传输加密的应用数据。

Client Hello

Client Hello 主要描述客户端的能力和初始参数，例如：

• 支持的 TLS 版本；
• 支持的密码算法；
• 客户端随机数；
• 扩展字段；
• 密钥交换所需的参数。

客户端并不是直接决定最终算法，而是列出自己能够接受的选择范围。

Server Hello

服务器从双方共同支持的范围中选择最终参数：

[
\text{最终选择}
\in
\text{客户端支持集合}
\cap
\text{服务器支持集合}
]

如果服务器选择了客户端完全不支持的算法，双方就无法继续通信。

4.3 数字证书与服务器身份

服务器证书将以下内容绑定在一起：

• 服务器域名或身份；
• 服务器公钥；
• 证书有效期；
• 密钥用途；
• CA 的数字签名。

客户端通常需要检查：

1. 证书是否由可信 CA 签发。
2. CA 的签名是否正确。
3. 证书中的域名是否与目标域名匹配。
4. 证书是否仍在有效期内。
5. 证书用途是否允许服务器认证。

验证成功后，客户端才能较为可信地确认当前公钥属于目标服务器，而不是由中间人临时替换。

需要注意的是，普通 HTTPS 通常主要认证服务器。用户身份往往由密码、Cookie、Token 或多因素认证完成。TLS 也支持客户端证书，但并非所有场景都会使用双向证书认证。

4.4 密钥派生与用途隔离

握手完成后，双方不会简单地把同一把密钥用于所有方向和所有算法，而是通过密钥派生函数从共享秘密和随机数中生成多组密钥。

教学模型通常将其区分为：

• 客户端到服务器的加密密钥；
• 客户端到服务器的完整性密钥；
• 服务器到客户端的加密密钥；
• 服务器到客户端的完整性密钥。

这种设计体现两种隔离：

• 方向隔离：两个传输方向不共用同一密钥。
• 用途隔离：加密和完整性验证不共用同一密钥。

现代 TLS 通常采用 AEAD 算法，将加密与完整性保护结合起来，但密钥用途隔离的设计原则仍然成立。

4.5 TLS 记录与安全关闭

TLS 不会一次性加密整条长连接，而是把应用字节流划分为多条记录。每条记录都会进行加密和完整性保护，接收端验证成功后才将明文交给应用程序。

TLS 还需要自己的关闭通知。普通 TCP FIN 只表示 TCP 字节流结束，并不能证明应用层数据是按预期完整结束的。TLS 的关闭机制可以帮助发现攻击者提前截断加密连接的情况。

4.6 TLS 不能解决的安全问题

TLS 只能保护通信过程，不能自动消除所有系统风险。

• CA 错误签发：如果可信 CA 错误地向攻击者签发证书，客户端仍可能受骗。
• 弱算法：使用已经不安全的旧算法或过短密钥会削弱整个连接。
• 降级攻击：攻击者可能试图迫使双方选择旧版本或弱算法。
• HTTPS 剥离：攻击者可能诱导用户直接使用 HTTP，使 TLS 根本没有被启用。
• 软件实现漏洞：即使密码协议正确，内存越界等代码缺陷仍可能泄露秘密数据。
• 终端失陷：如果客户端或服务器本身已被控制，加密信道也无法保护终端内部的明文。

这说明协议安全、算法安全和实现安全属于不同层次，任何一个环节出现问题都可能导致整体失效。

4.7 TLS、QUIC 与 HTTP/3

传统 HTTPS 的结构通常是：

1
2
3
4
5
6
7

HTTP/1.1或HTTP/2
       ↓
      TLS
       ↓
      TCP
       ↓
       IP

HTTP/3 则运行在 QUIC 之上：

1
2
3
4
5
6
7
8

HTTP/3
   ↓
 QUIC
可靠传输与TLS
   ↓
  UDP
   ↓
   IP

QUIC 将可靠传输、拥塞控制和 TLS 1.3 握手更紧密地结合，减少传统 TCP 建连后再进行 TLS 握手所产生的额外延迟。

❗ 本节核心结论： TLS 在 TCP 的可靠字节流上增加加密、完整性验证和身份认证，但它只能保护连接过程，不能替代应用安全、代码安全和终端安全。

5. IPsec：在网络层保护 IP 数据报

5.1 IPsec 的作用

TLS 通常由具体应用调用，而 IPsec 工作在网络层，能够统一保护 IP 数据报。它可以用于：

• 企业站点到站点 VPN；
• 远程用户接入内部网络；
• 主机到主机安全通信；
• 保护 TCP、UDP、DNS、BGP 等多种上层流量。

由于 IPsec 位于网络层，上层应用通常不需要知道加密保护的存在。应用仍然发送普通数据，IP 层按照安全策略决定是否对数据报进行保护。

5.2 传输模式与隧道模式

传输模式

传输模式主要保护原 IP 数据报的有效载荷。

1

原IP头 | IPsec头 | 受保护的传输层数据

其特点包括：

• 原始 IP 头仍然暴露并参与路由；
• 常用于主机到主机通信；
• 封装开销相对较小；
• 外界仍可看到通信端点的 IP 地址。

“传输模式”是 IPsec 的一种网络层工作模式，并不表示它属于传输层。

隧道模式

隧道模式将整个原始 IP 数据报作为内部载荷，并添加新的外层 IP 头。

1

新IP头 | IPsec头 | 受保护的原始IP数据报

其特点包括：

• 原始 IP 头被封装在隧道内部；
• 外部网络主要看到安全网关地址；
• 常用于网关到网关或主机到网关；
• 适合企业 VPN 和分支机构互联。

隧道模式并不会隐藏所有通信信息。外界仍然可以观察外层源地址、目的地址、数据报长度、通信时间和流量模式。

5.3 AH 与 ESP

IPsec 包含两类主要安全协议。

AH

AH，即 Authentication Header，主要提供：

• 数据完整性；
• 数据源认证；
• 一定程度的抗重放保护。

AH 不提供保密性，因此数据内容仍可能被观察。

ESP

ESP，即 Encapsulating Security Payload，可以提供：

• 保密性；
• 完整性；
• 数据源认证；
• 抗重放保护。

由于 ESP 同时支持加密和认证，其实际应用通常比 AH 更广泛。

5.4 安全关联 SA

IP 本身是一种无连接协议，但 IPsec 必须维护通信所需的安全状态。这些状态被组织为安全关联 SA。

一个 SA 通常记录：

• 使用 AH 还是 ESP；
• 加密算法；
• 完整性算法；
• 加密和认证密钥；
• 对端地址；
• 序号状态；
• SPI；
• 抗重放窗口。

SA 是单向的。一个 SA 只描述某个发送方向：

1
2

A → B：一个SA
B → A：另一个SA

因此，双向 IPsec 通信通常至少需要两个 SA。两个方向可以使用不同的密钥、序号和安全参数。

5.5 SPI 与抗重放

SPI 是 Security Parameter Index，即安全参数索引。它不是密钥，而是接收方查找对应 SA 的索引。

接收方看到 SPI 后，可以确定：

• 使用哪一组密钥；
• 使用哪种算法；
• 对应哪个通信实体；
• 当前抗重放窗口处于什么状态。

ESP 头部还包含 Sequence Number。每发送一个数据报，序号便向前推进。接收方记录已经处理的序号范围，从而识别攻击者重复发送的旧数据报。

攻击者即使不能解密数据，也可能重放一条已经合法认证的指令。例如，某条受保护消息表示执行一次支付或启动某项操作，重复发送仍可能造成危害。序号和抗重放窗口就是为了阻止这种攻击。

5.6 IPsec 数据处理流程

发送方的处理过程通常为：

1. 根据安全策略判断数据报是否需要保护。
2. 查找对应 SA。
3. 根据 SA 获得算法和密钥。
4. 添加 SPI 和序号。
5. 对载荷执行加密和完整性保护。
6. 根据模式保留原 IP 头或添加新 IP 头。
7. 发送 IPsec 数据报。

接收方则：

1. 根据目的地址、协议和 SPI 查找 SA。
2. 检查序号和抗重放窗口。
3. 验证数据完整性。
4. 解密受保护内容。
5. 去除 IPsec 封装。
6. 将恢复的数据报继续交给上层。

5.7 IPsec 的局限

IPsec 功能强大，但部署和维护成本较高。

• 配置复杂：两端需要正确匹配模式、算法、密钥和安全策略。
• NAT 穿透困难：原生 ESP 缺少普通 TCP/UDP 端口信息，而 NAT 常依赖端口区分连接。
• 额外封装开销：隧道模式需要添加新 IP 头和 ESP 字段。
• 计算开销：大量数据报需要逐包加密、验证和解密。
• 故障排查困难：安全策略、路由、NAT 和密钥协商问题可能相互影响。

常见的 NAT-T 方案会把 ESP 再封装到 UDP 中，通常使用 UDP 4500，从而让 IPsec 流量更容易穿过 NAT 设备。

❗ 本节核心结论： IPsec 将安全保护下沉到网络层，通过 SA、SPI、序号和 ESP 等机制统一保护 IP 数据报，特别适合企业 VPN，但配置和兼容性成本较高。

6. 防火墙：把安全策略转化为流量控制

6.1 防火墙的基本模型

防火墙通常位于组织内部网络与公共互联网之间，也可以部署在内部不同安全区域的边界。

其逻辑可以概括为：

[
\text{匹配条件}+\text{执行动作}
]

匹配条件可以包括：

• 源 IP；
• 目的 IP；
• 网络层协议；
• TCP 或 UDP 端口；
• ICMP 类型；
• TCP 标志位；
• 连接状态；
• 应用层协议内容。

执行动作通常包括：

• 允许；
• 丢弃；
• 拒绝；
• 记录；
• 限速；
• 转发到代理或检测系统。

防火墙可以阻止未授权访问、限制内部用户行为，并缓解部分拒绝服务攻击。但如果攻击流量已经占满防火墙之前的链路，边界防火墙本身也无法恢复被耗尽的带宽。

6.2 无状态数据包过滤

无状态防火墙把每个数据包视为独立对象，只根据当前包头决定是否放行。

例如，它可以：

• 阻止所有协议字段为 17 的 UDP 数据报；
• 阻止 TCP 23 端口的 Telnet 流量；
• 阻止特定源地址访问内部网络；
• 阻止入站 ACK=0 的 TCP 报文段。

阻止入站 ACK=0 可以粗略地阻止外部主机主动建立 TCP 连接，因为初始 SYN 通常不设置 ACK 位，而内部主机主动建立连接后收到的返回流量通常设置 ACK 位。

但 ACK=1 并不证明数据包真的属于一条合法连接。攻击者也可以伪造一个 ACK=1 的报文。因此，无状态过滤只能根据包头外观进行判断，不能确认通信历史。

6.3 ACL 与规则顺序

ACL 是有序的访问控制规则列表。防火墙通常从上到下检查规则，一旦匹配便执行相应动作。

1
2
3
4

allow 内部网络访问外部TCP 80和443
allow 合法响应流量返回
allow DNS查询
deny all

规则顺序非常重要。过于宽泛的允许规则如果出现在前面，后续的拒绝规则可能永远不会生效。

常见的策略是明确放行必要流量，最后设置：

1

deny all

这种设计体现了默认拒绝原则：没有被明确允许的流量均不得通过。

6.4 有状态数据包过滤

有状态防火墙会维护连接状态表，记录：

• 源和目的 IP；
• 源和目的端口；
• 当前 TCP 状态；
• 是否见过 SYN；
• 是否完成握手；
• 是否已经关闭；
• 最后活动时间；
• 超时信息。

当外部数据包试图进入内部网络时，有状态防火墙不仅检查 ACK 位，还会查询连接表，确认：

1. 内部主机是否曾经建立对应连接；
2. 当前报文是否属于该连接；
3. 标志位和连接状态是否合理；
4. 连接是否已经超时或关闭。

有状态过滤更加准确，但也引入了状态存储、连接超时、同步和抗状态耗尽等问题。

6.5 应用层网关

应用层网关不仅查看 IP 和 TCP/UDP 头部，还能够理解具体应用协议。

一个 Telnet 应用层网关可能建立两条独立连接：

1
2

内部主机 —— 连接1 —— 应用层网关
应用层网关 —— 连接2 —— 外部服务器

网关可以：

• 验证用户身份；
• 检查应用层命令；
• 限制可以访问的目标；
• 记录用户行为；
• 阻止内部主机绕过代理直接连接外部服务。

应用层网关的控制粒度较高，但每种应用协议通常需要专门实现，处理成本也高于普通包过滤。

6.6 防火墙的边界

防火墙无法自动解决所有安全问题：

• 源 IP 地址可能被伪造；
• 加密流量中的内容通常不可直接检查；
• 合法开放的服务器仍可能存在漏洞；
• 内部攻击可能不经过边界设备；
• UDP 缺乏明确连接状态；
• 过严规则会影响可用性；
• 过宽规则则会扩大攻击面。

因此，防火墙只是安全策略的执行点，而不是整个安全体系的终点。

❗ 本节核心结论： 防火墙通过 ACL、连接状态和应用协议规则控制流量，但它只能降低暴露面，不能替代服务器加固、身份管理和攻击检测。

7. IDS：发现已经发生或正在发生的攻击

IDS 是 Intrusion Detection System，即入侵检测系统。它的重点不是决定单个数据包是否立即放行，而是分析流量是否表现出攻击特征，并在发现异常时记录或告警。

7.1 深度数据包检测

普通数据包过滤主要检查包头，而 IDS 还可以分析载荷内容，例如：

• 已知病毒或恶意代码特征；
• 漏洞利用字符串；
• 异常应用协议格式；
• 可疑命令；
• 与已知攻击签名相匹配的数据模式。

这种检查称为 Deep Packet Inspection，即深度数据包检测。

7.2 跨数据包行为分析

很多攻击无法从一个数据包中判断，而需要关联多个时间点和多条连接。

例如：

• 同一主机短时间访问大量端口，可能构成端口扫描。
• 同一主机不断探测不同内部地址，可能是在进行网络映射。
• 大量连接持续访问同一目标，可能构成拒绝服务攻击。
• 某台内部主机突然与大量陌生地址通信，可能已被恶意软件控制。

IDS 因此需要维护一定的历史信息，把不同数据包和连接组合起来分析。

7.3 防火墙与 IDS 的协作

  flowchart LR
    A[互联网流量] --> B[边界防火墙]
    B -->|拒绝| C[丢弃或记录]
    B -->|允许| D[DMZ或内部网络]
    D --> E[IDS检查内容与行为]
    E -->|正常| F[继续通信]
    E -->|异常| G[告警与事件响应]
  

防火墙关注的问题是：

这条流量是否符合访问规则？

IDS 关注的问题是：

即使这条流量被允许，它是否表现出攻击行为？

二者的判断并不矛盾。一个数据包可能完全符合 ACL，例如发往 Web 服务器的 TCP 443 流量，但加密连接建立后仍可能承载针对应用漏洞的攻击。

7.4 为什么需要多个 IDS

一个组织可能在不同位置部署多个 IDS：

• 防火墙外侧；
• 防火墙内侧；
• DMZ 服务器区；
• 核心内部网络；
• 重要数据库或业务系统附近。

这样可以比较攻击流量在不同位置的表现：

• 攻击是否到达边界；
• 防火墙是否成功阻止；
• DMZ 服务器是否遭到入侵；
• 攻击者是否进一步进入内部网络；
• 内部主机是否正在向外发动异常通信。

IDS 通常只负责检测和告警。能够主动阻断攻击的系统通常称为 IPS，即 Intrusion Prevention System。

❗ 本节核心结论： 防火墙负责执行预先定义的访问规则，IDS 负责从载荷和行为中发现规则无法直接描述的攻击，两者共同构成纵深防御。

8. 不同安全机制的层次与边界

安全电子邮件、TLS 和 IPsec 都会使用密码学技术，但它们保护的对象和持续时间不同。

安全电子邮件保护的是消息本身，因此邮件被保存或转发后，签名和密文仍然存在。TLS 主要保护消息从一个端点传输到另一个端点时的连接过程。消息一旦被服务器解密并保存，TLS 就不能继续保护服务器内部的副本。IPsec 则进一步下沉到网络层，可以统一保护多种上层协议。

防火墙和 IDS 与前三者的职责也不同：

❗ 本节核心结论： 不同安全机制不是相互替代关系，而是分别保护消息、连接、数据报和网络边界，应根据保护对象组合使用。

9. 常见概念辨析

9.1 哈希不是加密

哈希函数把任意长度输入映射为固定长度摘要，通常没有对应的“解密”过程。加密则要求合法接收者能够使用密钥恢复原文。

因此：

[
H(m)
]

表示消息摘要，而不是可直接解密的密文。

9.2 本章的 MAC 不是 MAC 地址

密码学中的 MAC 表示 Message Authentication Code，即消息认证码，用共享秘密密钥验证消息完整性和来源。

链路层中的 MAC Address 则表示媒体访问控制地址。二者只是缩写相同，没有直接关系。

9.3 SA 不是物理线路

IPsec 的安全关联是一组逻辑安全状态，包括算法、密钥、SPI、序号和对端信息。它不是电缆，也不是专用物理信道。

9.4 应用层网关不是默认网关

默认网关是主机向其他子网发送数据时使用的下一跳路由器。应用层网关则是能够代理并检查特定应用协议的安全设备或软件。

9.5 代理工具不等于 IPsec VPN

两者都可能表现为建立“隧道”，但工作层次、信任关系和设计目标并不相同。

❗ 本节核心结论： 判断安全技术时不能只看表面现象，而应区分它所在的协议层、保护对象、密钥关系和安全目标。

10. 复习要点

完成本章学习后，应能够解释：

• 为什么数字签名通常只签名消息摘要。
• 公钥加密与数字签名的密钥使用方向有何不同。
• 安全电子邮件为何需要混合加密。
• Alice 在完整安全邮件方案中使用哪三种密钥。
• TLS 与 TCP 分别解决什么问题。
• Client Hello 和 Server Hello 如何完成参数协商。
• 数字证书如何把服务器身份与公钥绑定。
• TLS 为什么需要密钥派生和方向隔离。
• TLS 为什么不能解决服务器软件漏洞。
• IPsec 传输模式和隧道模式分别保护哪些内容。
• AH 与 ESP 的安全属性有何不同。
• SA 为什么是单向的。
• SPI 与 Sequence Number 分别起什么作用。
• IPsec 为什么可能难以穿过 NAT。
• 无状态与有状态防火墙的判断依据有何不同。
• ACL 规则顺序为何重要。
• 应用层网关为什么需要建立两条连接。
• IDS 为什么需要进行深度检测和跨数据包关联。
• 防火墙允许一条流量而 IDS 将其判定为攻击，为什么并不矛盾。

结论

网络安全的核心并不是简单地“把数据加密”。加密只能解决部分保密问题，而现实通信还需要验证身份、检测篡改、防止重放、限制访问并发现异常行为。

安全电子邮件把签名、公钥加密和对称加密组合起来，使消息在离线保存和转发后仍可保持安全属性；TLS 通过握手、证书认证和会话密钥保护一条应用连接；IPsec 通过 SA、SPI、序号和 ESP 在网络层统一保护数据报；防火墙将组织的访问策略转化为可执行规则；IDS 则从载荷和行为中发现已经突破静态规则的攻击。

网络安全真正依赖的是纵深防御：即使某一层失效，其他层仍能继续限制攻击范围、发现异常并保护关键资产。