dtp协议_dtls

详解 WebRTC 传输安全机制：一文读懂 DTLS 协议 　　DTLS(Datagram Transport Layer Security) 是基于 UDP 场景下数据包可能丢失或重新排序的现实情况下，为 UDP 定制和改进的 TLS 协议。在 WebRTC 中使用 DTLS 的地方包括两部分: 协商和管理SRTP密钥和为DataChannel提供加密通道。

　　本文结合实际数据包分析 WebRTC 使用 DTLS 进行 SRTP 密钥协商的流程。并对在实际项目中使用 DTLS 遇到的问题进行总结。 　　01 　　DTLS 协议简介 　　在分析 DTLS 在 WebRTC 中的应用之前，先介绍下 DTLS 协议的基本原理。 　　DTLS 协议由两层组成: Record 协议 和 Handshake 协议。 　　1. Record 协议: 使用对称密钥对传输数据进行加密，并使用 HMAC 对数据进行完整性校验，实现了数据的安全传输。 　　2. Handshake 协议：使用非对称加密算法，完成 Record 协议使用的对称密钥的协商。 　　1. HandShake 　　TLS 握手协议流程如下，参考 RFC5246。

　　DTLS 握手协议流程如下，参考 RFC6347。 　　

图片 　　

图片 　　TLS 和 DTLS 的握手过程基本上是一致的，差别以及特别说明如下： 　　DTLS 中 HelloVerifyRequest 是为防止 DoS 攻击增加的消息。 　　TLS 没有发送 CertificateRequest，这个也不是必须的，是反向验证即服务器验证客户端。 　　DTLS 的 RecordLayer 新增了 SequenceNumber 和 Epoch，以及 ClientHello 中新增了 Cookie，以及 Handshake 中新增了 Fragment 信息（防止超过 UDP 的 MTU），都是为了适应 UDP 的丢包以及容易被攻击做的改进。参考 RFC 6347。 　　DTLS 最后的 Alert 是将客户端的 Encrypted Alert 消息，解密之后直接响应给客户端的，实际上 Server 应该回应加密的消息，这里我们的服务器回应明文是为了解析客户端加密的那个 Alert 包是什么。 　　RecordLayer 协议是和 DTLS 传输相关的协议，UDP 之上是 RecordLayer，RecordLayer 之上是 Handshake 或 ChangeCipherSpec 或 ApplicationData。RecordLayer 协议定义参考RFC4347，实际上有三种 RecordLayer 的包:，DTLS 明文的 RecordLayer。 　　，压缩的数据，一般不用。 　　，加密的数据，在 ChangeCipherSpec 之后就是这种了。 　　没有明确的字段说明是哪种消息，不过可以根据上下文以及内容判断。比如 ChangeCipherSpec 是可以通过类型，它肯定是一个 Plaintext。除了 Finished 的其他握手，一般都是 Plaintext。 　　02 　　SRTP 密钥协商 　　1. 角色协商 　　在 DTLS 协议，通信的双方有和之分。在 WebRTC 中 DTLS 协商的身份是在 SDP 中描述的。描述如下，参考SDP-Anatomy中 DTLS 参数。 　　属性在 RFC4145， 　　setup:active，作为 client，主动发起协商； 　　setup:passive, 作为 sever，等待发起协商； 　　setup:actpass, 作为 client，主动发起协商。作为 server，等待发起协商。 　　相关视频参考 　　音视频免费学习地址：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发未来十年，C/C++程序员发展方向学完升职加薪，跳槽涨薪利器——音视频开发！_哔哩哔哩_bilibili 　　【文章福利】本人工作多年，整理了一些比较好的面试题、学习资料、教学视频和学习路线图共享在群文件，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等），免费分享，大家有需要的可以加入群自取~希望对大家有帮助





　　2. 算法协商-Hello 消息 　　ClienHello 和 ServerHello 协商 DTLS 的 Version、CipherSuites、Random、以及 Extensions。

图片 　　

图片：Client 给出自己能支持的、或者要使用的最高版本，比如 DTLS1.2。Server 收到这个信息后，根据自己能支持的、或者要使用的版本回应，比如 DTLS1.0。最终以协商的版本也就是 DTLS1.0 为准。 　　：Client 给出自己能支持的加密套件 CipherSuites，Server 收到后选择自己能支持的回应一个，比如 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)，加密套件确定了证书的类型、密钥生成算法、摘要算法等。 　　：双方的随机数，参与到生成 MasterSecret。MasterSecret 会用来生成主密钥，导出共享密匙和 SRTP 密钥。详见 [导出 SRTP 密钥]。 　　：Client 给出自己要使用的扩展协议，Server 可以回应自己支持的。比如 Client 虽然设置了 SessionTicket TLS 这个扩展，但是 Server 没有回应，所以最终并不会使用这个扩展。 　　Cipher Suite 　　

图片 　　在 Hello 消息中加密套接字使用中的注册的名字。IANA 名字由 Protocol，Key Exchange Algorithm，Authentication Algorithm，Encryption Algorithm ，Hash Algorithm 的描述组成。 　　例如，TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 的含义如下：: Transport Layer Security (TLS) 　　: Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) 　　: Rivest Shamir Adleman algorithm (RSA) 　　: Advanced Encryption Standard with 128bit key in Galois/Counter mode (AES 128 GCM) 　　: Secure Hash Algorithm 256 (SHA256) 　　加密套接字在 ciphersuite.info 可以查到。在查到 IANA 名字的同时，也可以查到在 OpenSSL 中的名字。TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 在 OpenSSL 中的名字为 ECDHE-RSA-AES128-GCM-SHA256。 　　Note: 关于 Authentication(认证)、KeyExchange(密钥交换)、Encryption(加密)、MAC(Message Authentication Code) 消息摘要等，可以参考 RSA密钥协商。 　　Extension 　　DTLS 的扩展协议，是在 ClientHello 和 ServerHello 的 Extensions 信息中指定的，所有的 TLS 扩展参考TLS Extensions。下面列出几个 WebRTC 用到的扩展：: DTLS 握手完成后 (Finished)，使用 SRTP 传输数据，DTLS 生成 SRTP 的密钥。RFC5764。ClientHello 中的扩展信息定义了 RFC5764 4.1.2. SRTP Protection Profiles 和 srtp_mki。 　　

图片 　　，原来的名字为，描述支持的 ECC 加密算法，参考RFC8422 5.1.1.Supported Elliptic Curves Extension，一般用的是 secp256r1。

图片 　　，DTLS1.2 的扩展，指定使用的 Hash 和 Signature 算法，参考 RFC5246 7.4.1.4.1. Signature Algorithms。DTLS1.0，RSA 用的是 md5sha1 摘要算法，DSA 用的是 sha1 摘要算法。 　　

图片 　　，扩展 MasterSecret 的生成方式，参考 RFC7627。在 KeyExchange 中，会加入一些常量来生成 MasterSecret。TLS 定义了扩展方式，如果用这个扩展，DTLS 的方式和 TLS 会有些不同。 　　，参考 RFC5746。 　　除了这些扩展协议，和 SRTP 密钥导出相关的还有： 　　RFC5705: Keying Material Exporters for Transport Layer Security (TLS)，DTLS 如何从 MasterSecret 导出 Key，比如 SRTP 的 Key。 　　RFC5764: DTLS Extension to Establish Keys for the SRTP，DTLS 的 use_srtp 扩展的详细规范，包括 ClientHello 扩展定义、Profile 定义、Key 的计算。 　　3. 身份验证-Certificate

图片 　　数字证书是由一些公认可信的证书颁发机构签发的，不易伪造。数字证书可以用于接收者验证对端的身份，接收者收到某个对端的证书时，会对签名颁发机构的数字签名进行检查，一般来说，接收者事先就会预先安装很多常用的签名颁发机构的证书（含有公开密钥），利用预先的公开密钥可以对签名进行验证。 　　Server 端通过 Hello 消息，协商交换密钥的方法后，将 Server 证书发送给 Client，用于 Client 对 Server 的身份进行校验。Server 发送的证书必须适用于协商的 KeyExchange 使用的加密套接字，以及 Hello 消息扩展中描述的 Hash/Signature 算法对。 　　在 WebRTC 中，通信的双方通常将无法获得由知名根证书颁发机构 (CA) 签名的身份验证证书，自签名证书通常是唯一的选择。RFC4572定义一种机制，通过在 SDP 中增加自签名证书的安全哈希，称为 ” 证书指纹 “，在保证 SDP 安全传输的前提下，如果提供的证书的指纹与 SDP 中的指纹匹配，则可以信任自签名证书。在实际的应用场景中，SDP 在安全的信令通道 (https) 完成交换的，SDP 的安全完整是可以做到的。这样在 DTLS 协商过程中，可以使用证书的指纹，完成通信双方的身份校验。证书指纹在 SDP 中的描述如下，参考SDP-Anatomy中 DTLS 参数。 　　4. 密钥交换-KeyExchange 　　ServerKeyExchange 用来将 Server 端使用的公钥，发送给 Client 端。分为两种情况： 　　1.算法: 如果服务端使用的是 RSA 算法，可以不发送这个消息，因为 RSA 算法使用的公钥已经在 Certificate 中描述。 　　2.算法，是根据对方的公钥和自己私钥计算共享密钥。因为 Client 和 Server 都只知道自己的私钥，和对方的公钥；而他们的私钥都不同，根据特殊的数学特性，他们能计算出同样的共享密钥。关于 DH 算法如何计算出共享密钥，参考DH算法。

图片 　　ClientKeyExchange 用来将 Client 使用的公钥，发送给 Server 端。 　　1.算法：如果密钥协商使用的 RSA 算法，发送使用 server 端 RSA 公钥，对 premaster secret 加密发送给 server 端。 　　2.算法：如果密钥协商使用的 DH 算法，并且在证书中没有描述，在将客户端使用的 DH 算法公钥发送给 Server 端，以便计算出共享密钥。

图片 　　KeyExchange 的结果是，Client 和 Server 到了 RSA Key， 或通过 DH 算法计算出共享密钥。详见 [导出 SRTP 密钥] 的过程。 　　5. 证书验证-CertificateVerify 　　客户端使用 ClientRequest 中描述的 Hash/Signature 算法，对收到和发送的 HandShake 消息签名发送给 Server。Server 端对签名进行校验。

图片 　　6. 加密验证-Finished 　　当 Server 和 Client 完成对称密钥的交换后，通过通知对端进入加密阶段，epoch 加 1。 　　随后 Client 使用交换的密钥，对 “client finished” 加密，使用 Finished 消息，发送给服务端。Server 使用交换的密钥，对 “server finished” 进行加密发送给客户端。一旦验证了 finished 消息后，就可以正常通信了。

图片 　　03 　　导出 SRTP 密钥 　　上面介绍了 DTLS 的过程，以下通过结合上面例子给出的实际数据，详细说明 SRTP 密钥的导出步骤。 　　1. 协商后的加密算法 　　加密套件：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xc02f) 　　椭圆曲线算法为：secp256r1，椭圆曲线的点压缩算法为：uncompressed。 　　椭圆曲线算法的基础知识的介绍在ECC椭圆曲线加密算法-ECDH,ECDHE,ECDSA，由文档中我们可以知道，确定椭圆曲线加密算法有如下参数：素数 p，用于确定有限域的范围。椭圆曲线方程中的 a，b 参数。用于生成子群的的基点 G。子群的阶 n。子群的辅助因子 h。 　　定义为 　　通过在SECG-SEC2 2.4.2 Recommended Parameters secp256r1中可以查到 secp256r1 对应的参数如下： 　　2. 通过 KeyExchange 交换椭圆曲线算法公钥 　　ECDH Server Parameter 　　记为 　　ECDH Client Paramter 　　记为 　　3. 根据 ECDHE 算法计算共享密钥 (pre-master-secret) 　　假设 Server 的使用的椭圆曲线私钥为 Ds, Client 使用的 Dc，计算共享密钥的如下 , 参考ECC 椭圆曲线加密算法-ECDH,ECDHE,ECDSA 　　S = Ds * Cpk = Dc * Spk 　　这个共享密钥就是我们在 RFC 文档中看到的 　　4. 计算master secret 　　计算 过程如下，可参考 Computing the Master Secret 　　计算出来的 为 48 Bytes，其中 和 在 Hello 消息中给出。 是伪随机数函数（pseudorandom function），在协商的加密套件中给出。 　　5. 使用 master_secrete 导出 SRTP 加密参数字节序列 　　使用 RFC5705 4. Exporter Definition给出的计算方式，使用参数 ，，计算字节序列： 　　在 DTLS-SRTP 4.2. Key Derivation 中描述了需要的字节序列长度。 　　master_key_len 和 master_salt_len的值，在 描述的profile中定义。我们的实例中使用的 profile 为 ，对应的 profile 配置为： 　　也就是我们需要 字节序列。 　　6. 导出SRTP密钥 　　计算出 SRTP 加密参数字节序列，在 DTLS-SRTP 4.2. Key Derivation 描述了字节序列的含义： 　　至此我们得到了, Client和Server使用的SRTP加密参数：master_key 和 master_salt。 　　04 　　DTLS 超时重传 　　DTLS 是基于 UDP 的，不可避免会出现丢包，需要重传。如果处理不当，会导致整个通信双方无法建立会话，通话失败。RFC6347 4.2.4 给出了超时和重传机制。 　　在处理重传时，以下几点需要注意： 　　1. 在 DTLS 协议中，为了解决丢包和重传问题，新增了 message_seq。 在发送 DTLS 重传消息时，一定要更新其中的 ，这样对端将把包识别是一个重传包，响应正确消息。否则，会默默丢弃这些包，不进行响应。 　　2. 当 server 端收到 client 的 FINISHED 消息，并发送 FINISHED 消息给 client，更新 server 状态为协商完成，开始发送 SRTP 数据。此时发送给 client 的 FINISHED 消息，出现丢包。client 收到 SRTP 数据后丢弃。同时，再次发送 FINISHED 消息到 server，server 要正确响应。否则，会导致 DTLS 协商完成的假象，通话失败。 　　3. 使用 openssl 1.1.1 之前版本，无法设置 DTLS 超时重传时间，可以超时重传机制不可用，大家开始转向使用 boringssl。openssl 1.1.1 开始版本已经支持设置 DTLS 超时重传，达到和 boringssl 同样的效果。参考 DTLS_set_timer_cb。 　　05 　　OpenSSL 的 DTLS 功能 　　DTLS 是一个庞大的协议体系，其中包括了各种加密，签名，证书，压缩等多种算法。大多数项目是基于 OpenSSL 或 BoringSSL 实现的 DTLS 功能。在实际项目使用 OpenSSL 的 DTLS 功能，与协商有关的接口总结如下。 　　1.X509_digest，计算证书 fingerprint，用在 SDP 协商中的属性。 　　2.SSL_CTX_set_cipher_list，设置使用的加密套件，通过设置算法的描述，影响 Hello 消息中的 cipher list。 　　3.SSL_CTX_set1_sigalgs_list设置签名算法。通过设置签名算法的描述，影响 hello 消息中 扩展。signature_algorithms 对 DTLS 的，，消息。signature_algorithms 设置不正确，会出现 internal error，不容易定位问题。 　　4.SSL_CTX_set_verify设置是否校验对端的证书。由于在 RTC 中大多数据情况下使用自签证书，所以对证书的校验，已校验身份是需要的。 　　5.SSL_CTX_set_tlsext_use_srtp设置扩展。srtp 扩展中的 profile，影响 srtp 加密时使用密钥的协商和提取。 　　6.SSL_set_options使用和 [SSL_set_mtu] 设置 fragment 的大小。默认 OpenSSL 使用 fragment 较小。通过上面两个接口，设置适合网络情况的 fragment。 　　7.DTLS_set_timer_cb，设置超时重传的 Callback，由 callback 设置更合理的超时重传时间。 　　在开源项目 SRS（https://github.com/ossrs/srs） 中已经支持了 WebRTC 的基础协议，对 DTLS 协议感兴趣的同学，可以基于 SRS 快速搭建本机环境，通过调试，进一步加深对 DTLS 的理解。 　　06 　　总结 　　本文通过 WebRTC 中 SRTP 密钥的协商过程，来说明 DTLS 在 WebRTC 中的应用。DTLS 协议设计的各个加密算法的知识较多，加上 TLS 消息的在各种应用场景中的扩展，难免有理解和认知不到的地方，还需要进一步深入探索。