DTLS 详细介绍

DTLS（Datagram Transport Layer Security）是一种基于UDP协议的安全传输协议，它提供了与TLS（Transport Layer Security）类似的安全性和数据完整性保护，同时也具有UDP协议的优点，如低延迟和支持多路复用等。

DTLS协议是建立在UDP协议之上的，因此它适用于对延迟敏感的应用程序，如VoIP（Voice over IP）和视频流媒体等。与TLS协议不同的是，DTLS协议在传输层对数据进行加密和认证，而TLS协议则是在传输层之上对数据进行加密和认证。因此，DTLS协议可以提供与TLS协议相同的安全性保护，同时也可以保持UDP协议的优点。

DTLS协议与TLS协议类似，通常包含以下步骤：

1. 握手阶段：客户端和服务器之间进行握手，协商加密算法和密钥等参数。

2. 数据传输阶段：客户端和服务器之间进行数据传输，DTLS协议对数据进行加密和认证。

3. 断开连接阶段：客户端和服务器之间断开连接，并清除相关的状态信息。

DTLS协议支持多种加密算法和密钥长度，并且可以通过使用签名证书和公钥证书来进行身份验证，以保证通信的安全性和完整性。因此，DTLS协议是一种适用于对延迟敏感的应用程序的安全传输协议。

安全联盟SA（Security Association）是通信对等体间对某些要素的协定，它描述了对等体间如何利用安全服务（例如加密）进行安全的通信。这些要素包括对等体间使用何种安全协议、需要保护的数据流特征、对等体间传输的数据的封装模式、协议采用的加密和验证算法，以及用于数据安全转换、传输的密钥和SA的生存周期等。

IPSec安全传输数据的前提是在IPSec对等体（即运行IPSec协议的两个端点）之间成功建立安全联盟。IPSec安全联盟简称IPSec SA，由一个三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它被封装在AH和ESP头中。

IPSec SA是单向的逻辑连接，通常成对建立（Inbound和Outbound）。因此两个IPSec对等体之间的双向通信，最少需要建立一对IPSec SA形成一个安全互通的IPSec隧道，分别对两个方向的数据流进行安全保护，如图21-12所示。

图21-12  IPSec安全联盟
 

另外，IPSec SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量，则对等体之间就有两个SA，每个方向上一个。如果对等体同时使用了AH和ESP，那么对等体之间就需要四个SA，每个方向上两个，分别对应AH和ESP。

建立IPSec SA有两种方式：手工方式和IKE方式。二者的主要差异如表21-5所示。

表21-5  手工和IKE方式的差异

对比项	手工方式建立IPSec SA	IKE方式自动建立IPSec SA
加密/验证密钥配置和刷新方式	手工配置、刷新，而且易出错 密钥管理成本很高	密钥通过DH算法生成、动态刷新 密钥管理成本低
SPI取值	手工配置	随机生成
生存周期	无生存周期限制，SA永久存在	由双方的生存周期参数控制，SA动态刷新
安全性	低	高
适用场景	小型网络	小型、中大型网络

安全协议

IPSec使用认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两种IP传输层协议来提供认证或加密等安全服务。

• AH协议

  AH仅支持认证功能，不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头，如封装模式所示。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。

• ESP协议

  ESP支持认证和加密功能。ESP在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Trailer和ESP Auth data），如封装模式所示。与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护，除非IP头被封装在ESP内部（采用隧道模式）。

AH和ESP协议的简单比较如表21-6所示。

表21-6  AH协议与ESP协议比较

安全特性	AH	ESP
协议号	51	50
数据完整性校验	支持（验证整个IP报文）	支持（传输模式：不验证IP头，隧道模式：验证整个IP报文）
数据源验证	支持	支持
数据加密	不支持	支持
防报文重放攻击	支持	支持
IPSec NAT-T（NAT穿越）	不支持	支持

从表中可以看出两个协议各有优缺点，在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。

报文头结构

AH报文头结构

AH报文头结构如图21-13所示；AH报文头字段含义如表21-7所示。

图21-13  AH报文头结构
 

表21-7  AH报文头字段含义

字段	长度	含义
下一头部	8比特	标识AH报文头后面的负载类型。传输模式下，是被保护的上层协议（TCP或UDP）或ESP协议的编号；隧道模式下，是IP协议或ESP协议的编号。 说明： 当AH与ESP协议同时使用时，AH报文头的下一头部为ESP报文头。
负载长度	8比特	表示以32比特为单位的AH报文头长度减2，缺省为4。
保留字段	16比特	保留将来使用，缺省为0。
SPI	32比特	IPSec安全参数索引，用于唯一标识IPSec安全联盟。
序列号	32比特	是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
认证数据	一个变长字段，长度为32比特的整数倍，通常为96比特。	该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2。 说明： MD5和SHA1验证算法存在安全隐患，建议优先使用SHA2算法。

ESP报文头结构

ESP报文头结构如图21-14所示；ESP报文头字段含义如表21-8所示。

图21-14  ESP报文头结构
 

表21-8  ESP报文头字段含义

字段	长度	含义
SPI	32比特	IPSec安全参数索引，用于唯一标识IPSec安全联盟。
序列号	32比特	是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
负载数据	—	包含原始IP报文中可变长度数据内容。ESP保护的内容类型由下一头部字段标识。
填充字段	—	用于增加ESP报文头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的长度不是加密算法所要求的块长度时，需要进行填充补齐。
填充长度	8比特	给出前面填充字段的长度，置0时表示没有填充。
下一头部	8比特	标识ESP报文头后面的下一个负载类型。传输模式下，是被保护的上层协议（TCP或UDP）的编号；隧道模式下，是IP协议的编号。
认证数据	一个变长字段，长度为32比特的整数倍，通常为96比特。	该字段包含数据完整性校验值ICV，用于接收方进行完整性校验。可选择的认证算法与AH的相同。 ESP的验证功能是可选的，如果启动了数据包验证，会在加密数据的尾部添加一个ICV数值。

封装模式

封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。

传输模式

在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。以TCP报文为例，原始报文经过传输模式封装后，报文格式如图21-15所示。

图21-15  传输模式下报文封装
 

传输模式下，与AH协议相比，ESP协议的完整性验证范围不包括IP头，无法保证IP头的安全。

隧道模式

在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。以TCP报文为例，原始报文经隧道模式封装后的报文结构如图21-16所示。

图21-16  隧道模式下报文封装
 

隧道模式下，与AH协议相比，ESP协议的完整性验证范围不包括新IP头，无法保证新IP头的安全。

传输模式和隧道模式比较

传输模式和隧道模式的区别在于：

• 从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据包进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。

• 从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。

• 从场景来讲，传输模式主要应用于两台主机或一台主机和一台VPN网关之间通信；隧道模式主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。

当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。

加密和验证

IPSec提供了两种安全机制：加密和验证。加密机制保证数据的机密性，防止数据在传输过程中被窃听；验证机制能保证数据真实可靠，防止数据在传输过程中被仿冒和篡改。

加密

IPSec采用对称加密算法对数据进行加密和解密。如图21-17所示，数据发送方和接收方使用相同的密钥进行加密、解密。

图21-17  加密和解密的过程
 

用于加密和解密的对称密钥可以手工配置，也可以通过IKE协议自动协商生成。

常用的对称加密算法包括：数据加密标准DES（Data Encryption Standard）、3DES（Triple Data Encryption Standard）、先进加密标准AES（Advanced Encryption Standard）。其中，DES和3DES算法安全性低，存在安全风险，不推荐使用。

验证

IPSec的加密功能，无法验证解密后的信息是否是原始发送的信息或完整。IPSec采用HMAC（Keyed-Hash Message Authentication Code）功能，比较完整性校验值ICV进行数据包完整性和真实性验证。

通常情况下，加密和验证通常配合使用。如图21-18所示，在IPSec发送方，加密后的报文通过验证算法和对称密钥生成完整性校验值ICV，IP报文和完整性校验值ICV同时发给对端；在IPSec接收方，使用相同的验证算法和对称密钥对加密报文进行处理，同样得到完整性校验值ICV，然后比较完整性校验值ICV进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。

图21-18  验证过程
 

同加密一样，用于验证的对称密钥也可以手工配置，或者通过IKE协议自动协商生成。

常用的验证算法包括：消息摘要MD5（Message Digest 5）、安全散列算法SHA1（Secure Hash Algorithm 1）、SHA2。其中，MD5、SHA1算法安全性低，存在安全风险，不推荐使用。

密钥交换

使用对称密钥进行加密、验证时，如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题：

• 带外共享密钥

  在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是安全性低，可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。

• 使用一个安全的密钥分发协议

  通过IKE协议自动协商密钥。IKE采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。同时，通信双方通过交换密钥交换材料来计算共享的密钥，即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥，这样极大地提高了安全性。