70、网络安全中的 IPsec 与传输层安全详解

time3

于 2025-10-27 13:14:02 发布

阅读量25

点赞数

CC 4.0 BY-SA版权

分类专栏：互联网协议深度解析文章标签： IPsec TLS 网络安全

本文链接：https://blog.youkuaiyun.com/time3/article/details/154228033

互联网协议深度解析专栏收录该内容

75 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

网络安全中的 IPsec 与传输层安全详解

在当今数字化的时代，网络安全至关重要。无论是商业交易中信用卡信息的交换，还是日常网络通信，都需要确保数据的安全性和完整性。本文将详细介绍网络层的 IPsec 以及传输层的安全协议，帮助大家更好地理解和应用这些安全技术。

1. IPsec 概述

IPsec（IP 安全）定义了一种标准方式，用于在两个节点之间交换 IP 数据报时进行认证或加密。其安全架构在 RFC 2401 中描述，RFC 3457 解释了一些常见的使用场景。协议扩展在 RFC 2402（认证）和 RFC 2406（加密）中定义。

安全的 IPsec 数据包交换发生在建立安全关联（SA）的一对协作节点之间。SA 本质上定义了安全类型（认证和/或加密）、算法以及应用于节点之间交换的所有 IP 数据包的密钥。需要注意的是，SA 实际上是单向的，但通常会在两个方向上实例化，可能除了密钥之外，其他特征相同。

IPsec 可以在主机计算机之间端到端部署，也可以通过代理安全服务器代表主机在网络中部署。也就是说，SA 可以从数据源扩展到数据汇，也可以只覆盖两个端点之间路径的一部分。

2. 端到端安全与代理安全的选择

端到端安全 ：安全关联从源端延伸到目的端，数据包在整个路径上都被完全加密或认证，这是最安全的解决方案。适用于单个远程节点连接到网络的情况，例如通过公共网络拨号接入。
代理安全 ：数据路径中间的节点（代理）负责对 IP 数据包应用 IPsec，并将其传输到另一个代理，该代理在将数据包传递到最终目的地之前进行验证或解密。虽然数据包在部分路径上会暴露，但代理安全有很多优点，使其有用且受欢迎：
- 降低端点的实现复杂度，一个代理可以服务多个端点，安全代码可以集中在代理上。
- 允许单个 SA 承载属于多个数据流的流量。
- 在 IPsec 中，当数据包穿越核心网络时，隐藏源和目的 IP 信息，增加安全性。适用于使用公共网络连接同一公司的网络以形成虚拟专用网络（VPN）的情况。

3. IPsec 认证

认证是通过使用密钥处理消息来实现的。在 IPsec 中，IP 头、数据有效负载和密钥通过认证算法处理，生成认证数据。这些认证数据被放置在插入 IP 头和有效负载之间的认证头中。

认证过程如下：
1. 在源端，对整个要传输的 IP 数据包（IP 头和数据）执行哈希算法，生成的值放入认证头的认证数据字段并发送到目的地。
2. 在目的地，使用相同的密钥再次对 IP 头和数据（不包括认证头）执行算法，将结果与传输的认证数据进行比较，以验证数据包是否未被修改。

IPsec 要求实现至少支持消息摘要五（MD5）算法。同时，发送方和接收方都需要知道使用的认证算法和密钥的值。

为避免 IP 头中某些值在数据包穿越网络时合法修改导致认证过程失效的问题，哈希算法在某些关键字段（TTL、ToS、校验和和标志）设置为零的 IP 数据包上应用。此外，插入认证头后，下一个协议字段会修改为 51（0x33）以指示认证头的存在。

认证头包含安全参数索引（SPI），用于识别管理此数据包的安全关联。SPI 应随机生成，以减少可预测性。序列号用于帮助防止拒绝服务攻击，目的地节点可以根据序列号判断接收到的数据包是否重复或无序，并丢弃它们。

认证可以在端到端模型或使用代理的情况下应用，消息格式相同。

4. IPsec 认证与加密

当使用 IPsec 加密时，根据部署模式的不同，处理方式有所不同：
- 端到端模式 ：源 IP 数据包的数据部分被加密，并与原始 IP 头一起传输。加密数据称为封装安全有效负载（ESP），放置在 ESP 头和尾部之间。
- 代理模式 ：整个源 IP 数据包（头和数据）被加密，构建一个新的数据包，带有新的 IP 头，用于在代理之间的隧道中传输。

IPsec 要求实现至少支持数据加密标准（DES）算法。ESP 数据包格式在 RFC 2406 中描述，从后往前理解其结构更容易：
1. 认证数据（可选） ：如果除了加密还使用了认证，会在数据包末尾附加一块认证数据。
2. 下一个协议字段 ：标识加密有效负载的协议。
3. 填充字节 ：填充有几个目的，包括确保下一个协议字段在 4 字节边界结束、满足某些加密算法对数据字节数的要求以及隐藏操作信息。
4. 加密数据 ：即要在网络中传输的 IP 头和数据。
5. 可选的初始化向量 ：特定于加密算法，包含解密算法在操作前所需的信息。

5. 传输层安全

传输层安全由 RFC 2246 中定义的传输层安全协议（TLS）提供。TLS 实际上是两个小协议，设计为在 TCP 上运行，通常通过安全套接字层（SSL）插入到应用程序和传输协议之间。

TLS 握手协议 ：用于协商和交换 TCP 连接上使用的加密和认证操作，可能还包括数据压缩。握手消息在 TLS 记录协议交换中传输，记录类型为 23（握手）。基本的消息交换由客户端发送 Client Hello 开始，服务器响应一系列消息定义其安全参数，客户端再发送一系列消息传递其认证信息。最后，双方通过发送 Change Cipher Spec 消息和 Finished 消息启用加密。
TLS 记录协议 ：提供握手消息交换的机制，负责 TCP 连接上交换数据的认证和加密。它使用标准算法对通过安全套接字 API 传递的数据进行哈希或编码。由于大多数加密算法对记录长度有要求，TLS 记录协议需要缓冲数据以构建完整的记录，同时将大的数据块分割成不超过 214 字节的记录。

TLS 记录的内容类型及其含义如下表所示：
| 内容类型 | 值 | 含义 |
| — | — | — |
| Change of cipher specification | 20 | 密码规范更改 |
| TLS alert | 21 | TLS 警报 |
| Handshake message | 22 | 握手消息 |
| Data | 23 | 数据 |

下面是 TLS 握手消息交换的 mermaid 流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([客户端]):::startend -->|Client Hello| B([服务器]):::startend
    B -->|Server Hello| A
    B -->|Certificate Request| A
    B -->|Server Key Exchange| A
    B -->|Certificate| A
    B -->|Server Hello Done| A
    A -->|Certificate| B
    A -->|Certificate Verify| B
    A -->|Client Key Exchange| B
    A -->|Change Cipher Specification| B
    A -->|Finished| B
    B -->|Change Cipher Specification| A
    B -->|Finished| A

6. TLS 握手协议详细流程

TLS 握手协议的详细流程如下：
1. 客户端发起 ：客户端发送 Client Hello 消息，表明希望在 TCP 连接上建立安全会话，定义会话 ID，并列出支持和愿意使用的安全和压缩算法。
2. 服务器响应 ：
- Server Hello 消息确认 Client Hello，并将安全和压缩算法列表缩小到各一个。
- 可选的 Certificate 和 Server Key Exchange 消息用于传达服务器的安全信息。
- 可选的 Certificate Request 消息，要求客户端以安全方式识别自己。
- Server Hello Done 消息表示服务器完成此序列消息。
3. 客户端响应 ：
- Certificate 消息响应 Certificate Request，识别客户端。
- Client Key Exchange 消息报告客户端的安全参数。
- Certificate Verify 消息确认服务器发送的证书（如果有）可接受。
- Change Cipher Specification 消息触发加密启用。
- Finished 消息完成客户端的消息序列。
4. 服务器完成 ：服务器发送 Change Cipher Spec 消息和 Finished 消息，启用自己在连接上发送消息的加密。

在安全的 TCP 连接生命周期内，也可以重新发起握手消息序列以重新协商安全参数。例如，当连接上的交易需要额外安全保护，或者连接已打开一段时间，客户端或服务器认为需要更改密钥时。

Finished 消息通过对已交换的一些消息和安全信息组合成的字节流执行认证哈希算法，验证接收到的消息与发送的消息是否相同。12 字节的认证数据是 RFC 2246 中定义的伪随机函数（PRF）的输出，其输入包括主密钥和“client finished”或“server finished”的文本标签。

综上所述，IPsec 和 TLS 为网络通信提供了强大的安全保障。通过合理选择端到端安全或代理安全，以及正确应用认证和加密技术，可以有效保护数据的安全性和完整性。同时，TLS 握手协议确保了传输层的安全连接建立和参数协商。在实际应用中，我们需要根据具体的网络环境和安全需求，灵活运用这些技术，构建更加安全可靠的网络系统。

网络安全中的 IPsec 与传输层安全详解

7. TLS 握手协议消息格式

TLS 握手协议消息在 RFC 2246 中使用类似“C”的符号指定，可转换为字节格式。每个消息有共同的格式，给出消息类型和长度，然后是特定于消息的字段。以下是常见消息及其格式说明：
| 消息类型 | 消息长度 | 具体字段 |
| — | — | — |
| Hello Request | 4 | - |
| Client Hello | 可变 | 客户端主版本号、次版本号、时间戳、随机数、会话标识符、密码套件 ID、压缩方法 |
| Server Hello | 75 | 客户端主版本号、次版本号、时间戳、随机数、会话标识符、密码套件 ID、压缩方法 |
| Certificate | 可变 | 发送者的 X.509v3 证书（可选）、后续 X.509v3 证书（可选） |
| Key Exchange | 可变 | 密钥交换算法、密钥参数 |
| Certificate Req | 可变 | 第一个证书类型、其他证书类型、第一个 X.509 认证机构名称、后续 X.509 认证机构名称 |
| Server Hello Done | 4 | - |
| Certificate Verify | 可变 | 签名类型、签名 |
| Finished | 16 | Hello 交换验证数据 |

8. IPsec 与 TLS 的对比

9. 实际应用中的考虑因素

在实际应用中，选择使用 IPsec 还是 TLS 需要考虑多个因素：
- 网络架构 ：如果网络中有多个子网需要连接，IPsec 的代理模式可以集中管理安全策略，适合构建 VPN。而对于单个应用程序的安全通信，TLS 更为合适。
- 性能要求 ：IPsec 加密和解密操作在网络层进行，可能会对网络性能产生一定影响。TLS 在传输层处理，对应用程序的性能影响相对较小。
- 安全需求 ：如果需要保护整个 IP 数据包，防止网络层的攻击，IPsec 是更好的选择。如果只需要保护应用层数据，TLS 可以满足需求。

以下是根据不同场景选择安全协议的决策流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([选择安全协议]):::startend --> B{网络架构}:::process
    B -->|多个子网连接| C(IPsec):::process
    B -->|单个应用通信| D{性能要求}:::process
    D -->|高| E(TLS):::process
    D -->|低| F{安全需求}:::process
    F -->|保护整个 IP 包| C
    F -->|保护应用层数据| E