一、概述
本文着重分析 WebRTC 的安全性，分析其安全性考虑及安全性实现，回答了以下问题:
- WebRTC 加密过程需要或依赖 CA (Certificate Authority)吗? 不需要 CA, 但可能依赖 CA.
- DTLS-SRTP 加密机制中, DTLS 与 SRTP 的关系是什么? DTLS 实现秘钥交换和管理, SRTP 实现具体的加密和解密过程.
- DTLS 握手交换秘钥的安全性如何进行保障? 明文传输，但通过其它机制保证握手阶段数据的一致性.
二、顶层结构
为了解释和回答上述问题，需要对 WebRTC 的整体结构进行初步的描述.
根据 [RFC9429] , 无论是 WebRTC 的何种变体，都遵循着 媒体信令 和 媒体传输 的两级分层:
媒体信令: 通过 HTTPS 、加密SIP 或 加密WebSocket 等方式实现 SDP的交换(协商), 具体协议类型由应用决定，信令传输安全也交由应用负责.
媒体传输: 规定数据传输使用 DTLS-SRTP , 数据传输安全由 DTLS-SRTP 负责.
但是 媒体传输 一定是安全的吗?
在没有 CA 的背书下, DTLS-SRTP 是无法解决 MITM (中间人攻击);
故媒体信令传输过程中, SDP 引入了一种新的机制，用于解决此问题. (在后文会具体展开描述)
除了中间人攻击之外, DTLS-SRTP 传输是安全的.
三、媒体传输
DTLS-SRTP 的关系是什么, 在 [RFC5736](Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)) 解释了它们之间的关系.
- DTLS : 支持 秘钥交换(DTLS Handshake Protocol) 和 数据加密 (DTLS Record Protocol)
- SRTP : 仅支持数据加密
故 SRTP 在实践过程中需要一种其他协议帮助其实现秘钥管理，这个协议就是 DTLS.
DTLS-SRTP 的完成描述是: 秘钥交换过程使用 DTLS 的握手实现, SRTP 则实现数据加密和解密.
(1) 秘钥交换
其中 DTLS 的握手协议是基于 TLS 制定的，可以在 [RFC5246](The Transport Layer Security (TLS) Protocol Version 1.2) 中找到:
其中 * 为可选, 以双向认证(包含上述所有步骤)为例进行解释说明:
| 角色 | 信令 | 描述 |
|---|---|---|
| 客户端 | ClientHello | 提供可选加密算法 |
| 服务端 | ServerHello | 选择具体的加密算法 |
| 服务端 | Certificate | 服务端发送证书 |
| 服务端 | ServerKeyExchange | 发送秘钥交换参数 |
| 服务端 | CertificateRequest | 要求客户端提供证书 |
| 服务端 | ServerHelloDone | |
| 客户端 | Certificate | 客户端发送证书 |
| 客户端 | ClientKeyExchange | 发送密钥交换材料 |
| 客户端 | CertificateVerify | 验证客户端身份 |
| 客户端 | ChangeCipherSpec | 通知对方要开始加密 |
| 服务端 | Finished | 握手完成信号包 |
完整流程如上, 其中 Certificate 是需要其它机制保证其安全:
即单纯的 DTLS 握手解决不了 我是我 这个核心问题, 在存在中间人窃听过程中, 中间人可伪造证书横跨在客户端及服务端之间.
常见的做法是对双端发送的证书做 CA 认证, 来回答 我是我 的这个问题;
但 WebRTC 对此的安全处理与此稍微不同，虽然本质是一样的, 在后文展开描述.
(2) 数据加密
由于 SRTP 已经相对来说比较成熟，一般实际开发过程中由 libsrtp 实现, 故此部分可简略描述.
通俗简单地描述, DLTS 未将接收到的数据原封不动地传输给 SRTP, SRTP 需要发送的数据也会原封不动地传输给 DTLS.
(3) 相关参考
- RFC6347 : Datagram Transport Layer Security Version 1.2
- RFC5736 : Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
- RFC3711 : The Secure Real-time Transport Protocol (SRTP)
- RFC5264 : The Transport Layer Security (TLS) Protocol Version 1.2
四、信令交互
在 媒体传输 中遗留了一个问题，如何证明 我是我.
在传统做法中，可以通过 CA 来证明 我是我 的这个问题, CA 认证可以确保证书的完整性不被破坏, 即数据未被篡改.
更进一步, DTLS 握手过程中的安全性，不依赖于数据加密，仅依赖于数据一致性.
为了实现数据一致性，WebRTC 的做法是对证书做一个 HMAC 指纹运算 (本质上就是证书的哈希值)，然后这个证书指纹通过其它安全的方式进行传输.
这样，在 DTLS 握手阶段的 Certificate 环节，服务端和客户端就可以对收到的证书进行同样的哈希运算得到对比指纹，如果指纹与原先通过其它途径获取到的证书指纹是一致的，则回答了 我是我 这个问题.
这个的其他途径是什么?
[RFC8122](Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)) 描述了这个过程，
通过在 SDP 里携带一个新的 attribute fingerprint，携带这个证书指纹.
故这里隐含了两条信息:
- 数据传输的安全性隐式地依赖与信令传输的安全性，若 SDP 传输是通过安全协议 (如 HTTPS 、加密 SIP 等)，则可认为数据传输是安全的
- 数据传输使用的证书可能不是 CA 认证过的证书， 可以是自签证书，但是自签证书可能隐式地收到CA证书的安全保护 (如 WHIP RTC 推流， SDP 是通过 HTTPS 进行的)
WebRTC 的安全性考虑性，本质上是安全链传递.
相关参考:
- RFC 8122 : Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
为什么 WebRTC 的媒体传输设计考虑不依赖于 CA 认证?
因为在实践操作过程中几乎不可能实行, [RFC8122](3.3 The Need for Self-Signed Certificates) 中进行的详细描述, 主要难点在于:
- RTC 设计是应用在任意终端的, 而 CA 证书一般是公网服务器才具备的条件
- CA 认证要求 IP 是固定的, 而很多情况下地址是动态的 (如使用 DHCP)
故实际媒体传输使用的证书往往使用自签证书.