SRS4.0之RTMP转WebRTC06 ---- DTLS协议

角色协商

对于DTLS来说，有Client和Server之分，这里主要是通过sdp来协商的。

offer:
a=fingerprint:sha-256 D4:50:20:EA:EE:A6:86:59:77:3B:88:84:95:69:8A:AE:79:1A:C0:35:D9:25:EE:3F:0E:02:CB:2B:AF:99:F5:9E
a=setup:actpass
answer:
a=fingerprint:sha-256 06:5D:44:D5:6A:62:A9:2E:5F:C5:5E:1E:99:3A:9F:11:20:7B:71:B1:D3:DF:CA:70:2D:82:0F:7D:AC:DC:0C:CC
a=setup:passive

setup:

1. active，作为client，主动发起协商
2. passive，作为server，等待发起协商
3. actpass，作为client，主动发起协商；作为server，等待发起协商

fingerprint：证书的摘要签名，用来验证证书使用，DTLS收到证书后，基于相同的hash计算哈希值，同fingerprint比较，相等，则说明证书有效。

DTLS握手过

过程和TLS总体差不多，目的就是交换对称秘钥，实现后面的加密。

具体可以参考：https://mp.weixin.qq.com/s/tHW6sWRZUzkOtl2BsRbV1w

1. ClienHello 和 ServerHello ：协商DTLS 的 Version、CipherSuites、Random、以及 Extensions

 Version：DTLS 1.2

CipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GSM_SHA256

　　TLS：协议

　　ECDHE：秘钥交换

　　RSA：对消息摘要使用私钥RSA加密生成数字签名，客户端使用公钥解密

　　AES_256_GSM：对称加密算法，最终数据交换使用对称加密

　　SHA256：对个人信息和公钥进行HASH算法生成信息摘要

Random: aa2425b20f7cf9fcc72d9a031b4374c2c597e57832b62f1b59fa75c332f711aa

　　双方的随机数，参与到生成 MasterSecret。MasterSecret 会用来生成主密钥，导出 SRTP 密钥。详见 [导出 SRTP 密钥]

2. 身份验证-Certificate

 

Certificate: 308201153081bda00302010202045d24d118300906072a8648ce3d040130143112301006… (id-at-commonName=ossrs.net)

这里证书通过sha256之后等于sdp里面的fingerprint，这里是自签名证书，通过这个来保证安全

 3. 密钥交换-KeyExchange

ServerKeyExchange和ClientKeyExchange，双方互相交换公钥，然后生成共享密钥。

4. 证书验证 - CertificateVerify

使用 ClientRequest 中描述的 Hash/Signature 算法，对收到和发送的 HandShake 消息签名发送个 Server。Server 端对签名进行校验。

5. 加密验证 - Finished

当 Server 和 Client 完成对称密钥的交换后，通过 ChangeCipherSpec 通知对端进入加密阶段，epoch 加 1。

随后 Client 使用交换的密钥，对 "client finished" 加密，使用 Finished 消息，发送给服务端。Server 使用交换的密钥，对 "server finished" 进行加密发送给客户端。一旦验证了 finished 消息后，就可以正常通信了。

 SRS握手过程

1. 初始化：收到/rtc/v1/play/后，创建SrsDtls

2. 握手：SrsDtlsImpl::do_handshake()

3. 握手结束：SrsDtlsServerImpl::on_handshake_done()

参考：

1.详解 WebRTC 传输安全机制：一文读懂 DTLS 协议