Transport Layer Security

Transport Layer Security (TLS and DTLS)

Transport Layer Security (TLS) 是一个 cryptographic protocol，设计用于在计算机网络上提供通讯安全。该协议被广泛的用于应用，例如 email, instant message, 和 voice over IP，但是它在安全 HTTPS 中使用最广为人知。

TLS 协议的主要目标是在两个或多个通讯额计算机应用间提供安全性，包括保密性，完整性，和真实性，通过应用密码学，例如证书。它运行于 presentation layer，且它本身由两层组成：TLS record 和 TLS handshake protocols。

密切相关的 Datagram Transport Layer Security (DTLS) 是一个向基于 datagram 的应用提供 security 的通讯协议。

Description

Client-server 应用使用 TLS 协议跨网络进行通讯，以避免偷听和篡改。

因为应用能使用 TLS 进行通讯，也能不使用 TLS，客户端是否请求服务器建立 TLS 连接十分必要。实现此目标的一种主要方法是为 TSL 连接使用不同的端口号。例如不加密的 HTTP 流量使用端口 80，加密的 HTTPS 流量使用端口 443。 另一种机制是向服务器发送协议指定的 STARTTLS 请求，将连接转换为 TLS 连接，例如在使用 news 或 mail 协议时。

一旦服务器和客户端对使用 TLS 达成一致，它们通过握手步骤协商一个 stateful 的连接。协议使用 asymmetric cipher 握手，不仅建立了密码设置，还建立了会话指定的共享密钥，随后的通讯使用 symmetric cipher 和该共享密钥进行加密。在握手期间，客户端和服务器对用于建立连接的安全性的不同参数达成一致：

• 客户端连接启用 TLS 的服务器并请求安全连接时，握手开始，客户端展现支持的 cipher suites (ciphers 和 hash function) 的列表。
• 服务器从列表中选择一个他也支持的 cipher 和 hash function，并通知客户端它的决定。
• 服务器通常随后会以 digital certificate 的形式提供一个身份标识。证书包含 server name，受信的 certificate authority (CA)，CA 能证明证书的真实性，和服务器的公共加密密钥。
• 在进行执行前，客户端先验证证书的合法性。
• 为了生成用于安全连接的 session key，客户端：
  • 使用服务器的公钥加密一个随机数 (PreMasterSecret)，并将结果发送给服务器 (仅能由服务器使用私钥进行解密)；双方随后使用该随机数生成唯一的 session key，供随后的会话期间对数据进行加密和解密，或
  • 使用 Diffie-Hellman key exchange (或它的变体 elliptic-curve DH) 安全地生成一个随机且唯一的 session key 用于加密和解密，该 session key 具有 forward secrecy 的属性：如果服务的私钥未来暴露了，它不能被用于解密当前的会话，即使会话被第三方截获和记录。

握手结束，安全连接开始，使用 session key 进行加密和解密直到连接关闭。如果上述任何一步失败，TLS 握手失败且连接不会被创建。

TLS 和 SSL 并不完全适合 OSI 模型或 TCP/IP 模型。TLS 运行在可靠传输协议之上 (e.g. TCP)，这暗示它在 transport layer 之上。它提供对更高层的加密服务，这通常是表示层的功能。然而，应用通常使用 TLS，好像它在传输层一样，即使使用 TLS 的应用必须主动控制 TLS 握手的初始化以及处理身份认证证书的交换。

当被 TLS 保护时，客户端和服务器之间的连接将有下列属性：

• 连接是保密的，因为传输的数据使用 symmetric-key algorithm 进行加密。对称加密的密钥每个连接都是唯一的，它基于会话开始时协商的 shared secret 生成。服务器和客户端在传输数据之前，协商使用何种加密算法和密钥。shared secret 的协商是安全 (协商的 secret 对窃听者来说是不可用的，且不能被获得，即使攻击者在连接之间) 和可靠的 (任何攻击者都不能在协商期间做到修改通讯且不被检测到)。
• 使用 public-key cryptography 能对通讯方的身份进行验证。这种身份验证对服务器来说是需要的，对客户端来说是可选的。
• 连接是可靠的 (或者说具有完整性) 因为每条传输的消息都使用 message authentication code 进行完整性检查，以避免传输中未检测到的数据丢失或数据修改。

TLS 支持很多不同的交换密钥，加密数据，和验证消息完整性的方法。结果，TLS 的安全配置涉及很多配置参数，并不是所有选项都提供上面列表中描述的所有与隐私相关的属性。

Datagram Transport Layer Security

Datagram Transport Layer Security (DTLS)，是一种相关的通讯协议，为基于 datagram 的应用提供安全性，通过允许它们以设计用于避免窃听，篡改或消息伪造的方式进行通讯。DTLS 协议基于面向流的 Transport Layer Security (TLS) 协议，倾向于提供类似的安全保证。然而，不像 TLS，它能被用于大部分面向 datagram 的协议，包括 User Datagram Protocol (UDP)，Datagram Congestion Conrtrol Protocol (DCCP)，Control And Provisioning of Wireless Access Points (CAPWAP), Stream Control Transmission Protocol (SCTP) 封装, and Secure Real-time Transport Protocol (SRTP)。

因为 DTLS 协议保留底层传输的语义 – 应用不会遭受与流协议相关的延迟，然而应用必须处理 packet reordering，datagram 丢失，和大于 datagram network packet 的大小的数据。因为 DTLS 使用 UDP 或 SCTP 而不是 TCP，它避免了在被用于创建一个 VPN 隧道时的 “TCP 崩溃问题”。

Digital certificates

数字证书通过证书的命名主体证明证书的所有权，并指示密钥期望的用法。这允许其他人 (依赖方) 依赖签名或依赖对应于证书公钥的私钥所做的断言。密钥存储库和信任存储库可以有多种格式，如。pem、。crt、。pfx和。jks。

Certicate authorities

TLS 通常依赖一系列受信的第三方证书授权机构，来建立对证书的认证。信任通常锚定在用户代理软件发布的证书列表中，依赖方可以修改。

Algorithms

Key exchange or key agreement

在客户端和服务器在 TLS 的保护下开始交换信息前，它们必须安全地交换或同意在加密数据时使用地加密密钥和密码算法。

Cipher

Data integrity

message authentication code (MAC) 被用于数据完整性。

Protocol details

TLS 1.3 handshake

Session IDs

在普通地 full 握手中，服务器发送一个 session id，作为 ServerHello 消息地一部分。客户端关联该 session id 到服务器地 IP 地址和 TCP 端口上，所以当客户端再次连接服务器时，它能使用该 session id 快捷握手。在服务器中，session id 映射到早先协商地加密参数上，特别是 “master secret”。两边必须有相同的 “master secret”，不然恢复握手将失败 (这避免了偷听者使用 session id)。

Session tickets

RFC 5077 使用 session tickets 对 TLS 进行拓展，而非 session IDs。它定义了一种恢复 TLS 会话的方法，不需要将特定的会话指定的状态存储在 TLS 服务器上。

当使用 session tickets 时，TLS 服务器将它的会话指定的状态存储到一个 session ticket 中，并将它发送给 TLS 客户端存储。客户端通过向服务器发送 session ticket 来恢复 TLS 会话，服务器根据 ticket 中会话指定的状态来恢复 TLS 会话。session ticket 通过服务器进行加密和身份验证，在使用它的内容前，服务器负责验证它的合法性。