传输层安全：握手， 数据传输

在上一节中，我们讨论了应用程序如何使用加密原语构建安全功能。通过 TCP/IP 协议发送的数据并不安全，因此每个应用程序都必须自己处理安全问题。理想情况下，如果传输层可以提供机密性、完整性和身份验证机制，则可以减轻应用程序层的安全负担，转而使用传输层服务。这还将提供跨平台/供应商的兼容性。这些功能由应用程序层和传输层之间的垫片层提供，称为安全套接字层 (SSL)。类似于套接字 API 的标准应用程序编程接口 (API) 允许应用程序引导安全连接并安全地发送/接收数据。IETF 开始开发传输层安全性 (TLS)，其大部分想法都借鉴了 SSL 3.0 协议。最著名的网络浏览器已开始支持 2018 年标准化的最新 TLS 1.3。在本节中，我们将讨论安全功能的简化版本，以便了解 TLS 协议的基础知识。数百页的 RFC 描述了协议的确切语法和语义以及一组丰富的配置。现在我们将 Alice（服务器）和 Bob（客户端）重新加入行动。Alice 已配置她的公钥/私钥对，如 17.3.1 中所述。值得强调的是，其中一些基本技术也用于其他层的安全协议，我们将在本章中讨论。TLS协议有 3 个阶段：握手、密钥派生和数据传输，如图 17.2 所示。

1 、握手

1. 首先 Bob 和 Alice 交换三方 TCP SYN、SYNACK 和 ACK 消息。需要注意的是，此步骤不是 TLS/SSL 的一部分。

2. 然后，Bob 向 Alice 发送一个 ClientHello 消息，以及密码套件（密码和它支持的哈希函数）和一个随机数（nonce），该随机数是一个专门为本次协议运行而选择的大型随机数。

3. Alice 用 ServerHello 消息进行响应，同时附上她选择的密码套件（例如，AES 用于保密性、RSA 用于公钥、SHA2 用于消息认证码 (MAC)）、包含她的公钥和随机数的证书。此外，她还可以请求客户端的证书和其他 TLS 扩展的参数。

4. Bob 检查证书的有效性，并确认证书属于 Alice。他发起 ClientKeyExchange 消息。这可以使用一系列密钥交换方法，例如 RSA 或 Diffie-Hellman（及其变体）来为后续会话建立对称密钥。例如，当使用 RSA 时，Bob 可以生成一个 48 位预主密钥 (PMS)，并使用 Alice 使用上述步骤获得的公钥对其进行加密，然后将其发送给 Alice。

5. Bob 发送一个 ClientCipherSpec 和一个 Finished Message 消息，表明密钥生成和认证已完成。

6. 此时 Alice 也拥有了共享密钥。她向 Bob 回复了 ChangeCipherSpec 和 Finished Message。

7. Bob 使用协商好的对称密钥解密消息并执行消息完整性检查。成功完成上述步骤后，安全隧道就建立好了，现在可以发送加密的应用程序数据了，如图 17.2 底部所示。协议交换和消息处理的详细信息可以在中找到。

2 、密钥派生

客户端 nonce、服务器 nonce 和 PMS 输入伪随机函数来生成

主密钥。此连接的所有其他关键数据均来自此主密钥

与其他参数结合使用。派生出以下四个常用密钥

两端：

1. Bob 向 Alice 发送数据的会话加密密钥（客户端加密密钥）。

2. Alice 向 Bob 发送数据的会话加密密钥（服务器加密密钥）。

3. Bob 向 Alice 发送数据的会话 MAC 密钥（客户端 MAC 密钥）。

4. Alice 向 Bob 发送数据的会话 MAC 密钥（服务器 MAC 密钥）。

为了增强安全性，Bob 和 Alice 在每个方向上都派生出单独的加密和完整性密钥。生成这些临时密钥可以实现完美的前向保密性，因为这些密钥不能在未来的会话中重复使用。例如，Eve 可以捕获 Alice 和 Bob 之间的每一次通信。她可以假装是 Bob，并在当天晚些时候重复 Bob 发送的命令序列。这种攻击称为连接重放攻击。TLS 和大多数其他协议使用会话特定的随机数（随机数）来避免这种攻击。PMS 生成算法在混合中使用了随机数。连接重放攻击将失败，因为由于这个新的随机数，Alice 在新会话中将拥有与 Eve 不同的一组密钥。

3 、数据传输

TCP 是一种面向字节的传输协议，其中应用层数据以字节流的形式发送。完整性检查算法需要固定长度的数据来计算 MAC。如果应用程序必须收集固定长度的数据并将其传递给这些算法，则会导致进一步的延迟。因此，TLS 定义了一种记录格式，如图 17.3 所示，其中可以指示每个记录中发送的数据的长度以及记录的类型（数据或控制）。每个记录的末尾还附加了一个 MAC。例如，如果数据从 Bob 发送到 Alice，则使用从 Bob 发送到 Alice 的数据的会话 MAC 密钥来生成此 MAC。此外，使用从 Bob 发送到 Alice 的数据的会话加密密钥对数据和 MAC 进行加密。

由于 TCP 序列号未加密，可能的 MITM 攻击可以简单地捕获 TCP 段并在这些段之间交换 TLS 记录。接收方无法检测到此攻击，因为 TLS 记录的完整性保持不变。TLS 提供了一种单独的机制，发送方和接收方可以跟踪记录序列号而无需明确交换它。但是，两端的 MAC 计算都会在混合中使用这个序列号。任何 MITM 记录重新排列都将无法通过完整性检查。

讨论了 TLS 的技术细节后，我们现在来考虑它在面临某些攻击时的表现。在密码嗅探攻击中，Eve 捕获一些数据包并想要获取 HTTPS 或其他应用程序流量中的密码。由于用户数据已加密，因此无法嗅探密码。在 IP 欺骗攻击中，Mallory 使用伪造的 IP 地址欺骗 Bob 接受虚假数据。Mallory 必须拥有密钥以及伪造的 IP 地址才能成功。使用公钥证书对通信方进行身份验证可以防止 MITM 攻击。

我们注意到，在一种称为 SYN Flooding DDoS 攻击的相关传输层攻击中，一组攻击机器不断发送 TCP SYN 消息以请求连接并让服务器分配资源。但是，这种类型的攻击可以由 TCP 处理，因此不会在 TLS 中重复。许多操作系统都实施了一种称为 SYN Cookies 的防御措施 [RFC4987]。服务器在收到 TCP 连接请求时不会立即半打开连接。它使用哈希函数对源和目标 IP 地址、SYN 段的端口号以及只有服务器知道的秘密号码进行选择初始序列号 (ISN)。然后，服务器在 SYNACK 消息中向客户端发送此 ISN（也称为 Cookie）。如果请求来自合法发送方，则服务器将收到一条 ACK 消息，其中包含一个新序列号，即 ISN 加 1。完成此验证后，服务器将打开 TCP 连接。DDoS 发送方要么不以 ACK 进行响应，要么在其响应中没有正确的 ISN。因此，没有浪费任何 TCP 资源。

当前版本的 SSL（和 TLS）经历了早期版本中发现的几次攻击和漏洞，并不断发展。SSL Stripping 攻击通过修改请求使用 TLS 的未加密协议，完全消除了 SSL/TLS 的使用。BEAST 攻击利用了由于使用密码块链接 (CBC) 而导致的 TLS 1.0 实现的可预测初始化向量。这允许攻击者解密数据包的某些部分，例如 HTTP cookie。RFC 7457 中讨论了大量已知攻击和缓解措施。其中许多漏洞也归因于实施不当或对协议套件的理解不足，而不是缺乏适当的规范。例如，TLS 设计问题（在加密之前计算 MAC）导致了一种称为 Lucky Thirteen 攻击的定时侧信道攻击，该攻击允许攻击者解密任意密文。针对此攻击的对策包括使用 AES-GCM 加密，或使用先加密然后计算 MAC 的方法 [RFC7366]。

4 、快速UDP互联网连接（QUIC）

QUIC 是 Google 设计的一种新传输协议，用于使用 UDP 而不是 HTTP over TCP 实现更快的网页浏览。该协议目前使用专有加密和身份验证。防火墙和 IDS 系统通常会检测 HTTP流量，并执行深度数据包检查、病毒扫描和其他安全措施。尽管 QUIC 使用标准 HTTP 端口，但安全设备目前不会跟踪此应用层协议。它被视为常规 UDP 流量。由于标准化工作已经在进行中，因此很可能使用 TLS1.3 进行安全传输。

在本节中，我们研究了通过传输协议保护端到端通信通道的各种机制。但是，如果传输的内容可供通信通道外的攻击者访问，他们就可以比较加密材料的容量并进行推断。因此，这可能会危及消息的机密性。