【网络通信 — 直播】网络通信协议简介 — SSL/TLS 与 DTLS

大家好，欢迎来到IT知识分享网。

【网络通信 — 直播】网络通信协议简介 — SSL/TLS 与 DTLS

【1】网络传输中加密的一般概念

对称密钥加密技术，加密过程和解密过程使用的是同一个密钥；

• 常见的对称加密算法有 DES、3DES、AES、Blowfish、IDEA、RC5、RC6；

非对称密钥加密技术，加密过程和解密过程使用了不同的密钥，分别为公开密钥和私有密钥；公钥是众所周知的，私钥只能由报文的目标主机所持有；

• 优点是不用担心密钥在通信过程中被他人窃取；缺点是解码速度慢，消耗更多的 CPU 资源；
• 常见的非对称加密算法有 RSA、DSA、DH 等；

数字签名，附加在报文上的特殊加密校验码，即所谓的校验和，其中利用了非对称加密密钥加密技术；

• 主要作用是防止报文被篡改，一旦报文被攻击者篡改，通过将其与校验和进行匹配，可以立刻被接收者发现；

数字证书，由一些公认可信的证书颁发机构签发，不易伪造；主要包括，证书序列号、证书签名算法、证书颁发者、有效期、公开密钥、证书签发机构的数字签名；

• 数字证书可以用于接收者验证对端的身份；
• 接收者收到某个对端的证书时，会对签名颁发机构的数字签名进行检查，一般来说，接收者会预先安装很多常用的签名颁发机构的证书，利用预先的公开密钥可以对签名进行验证；

【2】SSL/TLS 协议简介

SSL (Secure Socket Layer) 和 TLS (Transport Layer Security) 是在应用层和传输层之间加入的安全层；

• SSL/TLS 主要解决互联网通信中存在的三种风险
  • 窃听风险，第三方可以获知通信内容；
  • 篡改风险，第三方可以修改通信内容；
  • 冒充风险，第三方可以冒充他人身份参与通信；
• SSL/TLS 协议的主要解决方案
  • 所有信息通过加密传播，第三方无法窃听；
  • 具有数据签名及校验机制，一旦被篡改，通信双方立刻可以发现；
  • 具有身份证书，防止其他人冒充；

【2.1】SSL/TLS 的协议栈

SSL/TLS 建立在 TCP 传输层上，最常用的场景是在 HTTPS 中，通过在 HTTP 和 TCP 中加了一层 SSL/TLS，使得不安全的 HTTP 成为了安全的 HTTPS；

SSL/TLS 对于 TCP 传输层的加密是通过动态密钥对数据进行加密实现的，而动态密钥通过握手流程协商制定；在 SSL/TLS 握手过程中需要协商的信息如下

• 协议版本号；
• 加密算法，包括非对称加密算法、动态密钥算法；
• 数字证书，传输双方通过交换证书及签名来验证对方身份；
• 动态密钥，由于非对称加密对性能消耗较大，因此主要的通信过程都是使用动态密钥进行对称加密；对称加密使用的动态密钥则在握手过程中通过非对称加密来传输；

【2.2】SSL/TLS 的握手过程

SSL/TLS 的握手过程大体分成三个过程，明文通信过程、非对成加密通信过程、对称加密通信过程；

• 明文通信过程，在通信两端首次向对方发送 Hello 消息时，由于双方都没有协商好要使用的加密方式，因此该过程中的消息都是使用明文进行发送；
  • a. Client Hello，客户端首先向服务端发起握手，在握手消息中告诉对方自己支持的 SSL/TLS 版本、加密套件（包括非对称加密时使用的算法、对称加密时使用的算法、产生密钥的伪随机函数 PRF）与数据压缩算法（TLS 1.3 之后就已经没有这个字段）等；另外携带一个 Session ID，因为握手流程的开销比较大，使用 Session ID 可以在下一次与 TLS 握手的过程跳过后续繁琐的握手流程，重用之前的握手结果（如版本号、加密算法套件、master-key 等）并告知对方产生的一个随机数 A；
  • b. Server Hello，服务端响应一个 Server Hello 消息，携带协商出来的 TLS/SSL 版本号、加密套件和数据压缩算法，如果服务端同意客户端重用上次的会话，就返回一个相同的 Session ID，否则就填入一个全新的 Session ID 并告知对方一个随机数 B；
  • c. Server Certificate（可选），携带服务端数字证书（CA）以验证服务端身份，里面携带了服务端非对称加密所使用的公钥；
  • d. Server Key Exchange（可选），在使用某些非对称加密算法（例如 DH 算法）的情况下，Server Certificate 里的信息是不充分的，或者 Server Certificate 在某些通信过程中直接被省略了（没有验证服务端身份），需要 Server Key Exchange 里的额外信息来帮助客户端生成 pre-master key；
  • e. Client Sertificate Request（可选），在有些安全性要求高的场景，例如银行支付等，不仅需要验证服务端的身份，还需要验证客户端的身份，这时候服务端就会要求客户端提供客户端的身份证书；
  • f. Server Hello Done，表明 Server Hello 结束；
  • g. Client Certificate（可选），如果服务端要求客户端提供数字证书以验证身份，则客户端发送自己的身份证书给服务端；
• 非对称加密通信过程，由于非对称加密通信的性能较差，在实际的通信过程中其实使用的是对称加密通信，为了保证对称加密通信过程的安全性，也就是需要避免对称加密密钥被窃取，这个密钥在协商过程中使用非对称加密来进行加密；
  • a. Client Key Exchange，客户端在验证服务端的身份证书后，会取出其中的服务端公钥，产生一个随机数 C，作为 pre-master key，在本地使用之前的随机数 A、B 和这次生成的 C 共同生成对称加密密钥 master-key；使用服务端公钥对 pre-master key 加密后发送给服务端；
  • b. Certificate Verify（可选），如果服务端要求客户端提供客户端证书，那么客户端在发送 Client Key Exchange 之后必须马上发送 Certificate Verify，其中的内容是客户端使用自己的私钥加密的一段数据，提供给服务端用客户端的公钥来进行解密验证，以确保客户端发送的证书确实是它自己的证书；
  • c. Client Change Cipher Spec，提示服务端随后使用 master key 来进行对称加密通信；
  • d. Client Handshake Finished，表明客户端侧 SSL/TLS 握手结束；
  • e. Server Change Cipher Spec，提示客户端随后使用 master key 来进行对称加密通信；
  • f. Server Handshake Finished，表明服务端侧 SSL/TLS 握手结束；

非对称加密传输 KEY 的过程图示

• 对称加密通信过程，通过上述握手过程协商出对称加密算法及使用的对称加密密钥之后，随后的通信过程，即实际的应用通信过程，都使用对称加密；

对称加密传输数据过程图示

【2.3】SSL/TLS 握手消息格式

enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType msg_type; /* handshake type */ uint24 length; /* bytes in message */ select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; } body; } Handshake;

【3】DTLS 协议简介

DTLS (Datagram Transport Layer Security) 是适用于 UDP 传输过程的加密协议，DTLS 在设计上尽可能复用 TLS 现有的代码，并做一些小的修改来适配 UDP 传输，DTLS 与 TLS 具备了同样的安全机制和防护等级，同样能够防止消息窃听、篡改，以及身份冒充等问题；

【3.1】DTLS 协议栈

在 WebRTC 中，通过引入 DTLS 对 RTP 进行加密，使得媒体通信变得安全，通过 DTLS 协商出加密密钥之后，RTP 也需要升级为 SRTP，通过密钥加密后进行通信；

【3.2】DTLS 握手过程

相比 TLS 1.2，DTLS 1.2 的握手过程与 TLS 1.2 的大部分步骤一致，只是在服务端多了一步 HelloVerifyRequest，客户端因此也多了第二次的 ClientHello；

服务端在首次收到客户端发送的 Client Hello 之后，只会生成一个 Cookie，不进行任何其他的操作，并给客户端发送 HelloVerifyRequest 消息并带上生成的 Cookie，只有当客户端重新发送一次 Client Hello，并带上服务端发送的 Cookie 后，服务端才会继续握手过程；

【3.3】DTLS 握手消息格式

enum { hello_request(0), client_hello(1), server_hello(2), hello_verify_request(3), // New field certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType msg_type; uint24 length; uint16 message_seq; // New field uint24 fragment_offset; // New field uint24 fragment_length; // New field select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case hello_verify_request: HelloVerifyRequest;// New field case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; } body; } Handshake;

相比 SSL/TLS 消息格式中增加了 hello_verify_request (用于解决 Dos 攻击)，message_seq、fragment_offset、fragment_length (用于解决 UDP 传输的可靠性，避免出现重放、乱序、丢包的问题)；

【3.4】DTLS VS SSL/TSL

【3.4.1】重传机制

• TCP 自带重传机制保证消息不会丢失
• UDP 对消息的丢包没有任何保证，DTLS 额外增加了超时重传机制来确定握手消息到达；
  • 客户端发送消息之后，启动一个定时器，等待服务端返回响应；
    • 若超过了定时时间客户端还没有收到响应，则客户端便会知道要么是客户端请求消息丢失，要么是服务端响应消息丢失，客户端便会再次发送相同的请求消息；
    • 服务端即使确实发送了响应，若仍然收到相同的客户端请求消息，服务端可以推测需要重传响应，并再次发送响应消息；
  • 同样地，服务端也会启动定时器来等待下一条消息；

【3.4.2】序列号

• TCP 消息中自带序列号 seq 并处理了乱序的问题；
• UDP 对乱序问题没有任何保证，为了保证握手消息的有序性，DTLS 在握手报文中增加了 message_seq 字段便于接收方处理乱序消息，接收方直接处理属于当前步骤的消息，并提供一个缓存队列来缓存提前到达的消息；

【3.4.3】消息重放检测

• 消息重放也是 DoS 攻击的一种，攻击者可以截取发送者发送的数据，并直接原封不动地发给接收方，来达到欺骗接收方的目的；
• DTLS 增加了类似 IPsec AH/ESP 的消息重放检测，使用一个 bitmap 滑动窗口来接收消息，结合消息本身的序号，bitmap 可以判断该消息是否是太老的消息，若消息过老则直接抛弃；
• 该功能在 DTLS 中是可选的，因为某些 UDP 报文的重复只是单纯因为网络错误；

【3.4.4】报文大小限制

• TCP 面向字节流，TCP 会自动将报文进行拆分和组装，无需上层操心；
• UDP 面向报文，若 UDP 报文超过了 MTU（链路层的最大传输单元）限制，则会在 IP 层被强制分片，使得每一片大小都小于 MTU，接收方 IP 层需要进行数据报的重组，从而会多做许多工作，同时若其中一片丢失便会重组失败，导致整个 UDP 报文丢失；
  • DTLS 直接在 UDP 之上就对握手消息做了分段，在握手报文中添加了 fragment_offset（该段报文相对消息起始的偏移量） 和 fragment_length 字段（该段报文的长度）；

【3.4.5】Cookie

• TCP 可以使用 SYN Cookie 的机制来防范 DoS 攻击；
• 如果在 UDP 上直接使用 TLS 的握手方式，就可能发生以下两种情况 :
  • 1. 攻击者可以通过发送一系列握手启动请求来消耗服务器上的资源；
  • 2. 攻击者可以伪造受害客户端的 IP 地址向服务端发起 DTLS 握手，迫使服务端发送 Certificate 消息给受害客户端，上文提到过 Certificate 携带了很多信息，包括数字证书等，使得受害客户端不得不接受大量无用消息；
• DTLS 解决 DoS 的方法
  • 1. 当客户端首次给服务端发送 Client Hello 时，服务端只会生成一个 Cookie 并通过 HelloVerifyRequest 发送给客户端，不会执行分配缓冲区等操作，直到收到带上相同 Cookie 的 Client Hello 才会继续握手；
  • 2. HelloVerifyRequest 足够小不会造成大量数据发送

【3.4.6】加密方式

• SSL/TLS
  • SSL/TLS 不能独立解密单个封包，SSL/TLS 对于封包的认证需要序号作为输入，由于 TCP 是可靠的，TLS 的两端各自维护自身的收发序号，因此在 SSL/TLS 中并未直接传递序号；
• SSL/TLS 的某些加密算法不是独立解密的，需要依赖上个封包，典型的就是 RC4 流加密算法；
• DTLS
  • 由于 UDP 本身的不可靠，DTLS 在每条记录中显式携带的序号作为解码的输入；
  • DTLS 的不能支持 RC4 等流式加密算法；

文献资料

【1】The Transport Layer Security (TLS) Protocol V_1.2

【2】Datagram Transport Layer Security V_1.2

参考致谢
本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。

【1】一文读懂 DTLS 协议

【2】详解 WebRTC 传输安全机制：一文读懂 DTLS 协议

【3】HTTPS 碎片信息

【4】SSL/TLS算法流程解析

【5】HTTPS 详解一：附带最精美详尽的 HTTPS 原理图

【6】HTTPS 温故知新（三） —— 直观感受 TLS 握手流程(上)

【7】DTLS协议学习记录