一、WebRTC安全体系：DTLS握手、SRTP加密、证书与指纹验证
聊到WebRTC的安全，很多人第一反应就是“哦，它用了加密”。但说实话，加密只是冰山一角。WebRTC的安全体系，是一整套从身份验证到数据传输加密的闭环设计。我当年第一次深入看WebRTC源码时，就被这套设计的严谨性震撼到了——它不是为了合规而加密，而是从骨子里就假设网络是不可信的。
今天我们就来拆解这个体系。核心就四个关键词：DTLS握手、SRTP加密、自签名证书、指纹验证。它们环环相扣，缺一不可。
1.1 为什么WebRTC必须加密？
先问个问题：为什么浏览器强制要求WebRTC加密？
因为WebRTC走的是P2P通道。数据直接从你的浏览器流向对方，中间不经过服务器中转。如果不加密，你的摄像头画面、麦克风声音，甚至文件传输内容，都会以明文形式暴露在公网上。你想想看，这有多危险？
所以W3C和IETF在制定标准时，直接规定：WebRTC的媒体通道必须使用SRTP加密，信令通道必须使用DTLS加密。不加密？浏览器直接拒绝建立连接。
核心原则：WebRTC的安全是强制性的，不是可选的。任何未加密的媒体流都不会被浏览器接受。
1.2 DTLS握手：建立安全通道的第一步
DTLS，全称Datagram Transport Layer Security。说白了，就是给UDP套上了TLS的外衣。为什么不用标准TLS？因为TLS依赖TCP的可靠传输，而WebRTC用的是UDP。DTLS就是为了解决UDP场景下的加密问题而生的。
DTLS握手的过程，和HTTPS的TLS握手很像，但有几个关键区别：
- 记录层不同：DTLS需要处理丢包和乱序，所以每个记录都有序列号
- 握手重传：UDP丢包是常态，DTLS内置了超时重传机制
- 无连接特性：DTLS不维护连接状态，每次握手都是独立的
我在项目中遇到过一个问题：两个WebRTC客户端在弱网环境下，DTLS握手总是超时。后来发现是默认的重传间隔太短，在丢包率超过20%的网络里根本握不上。我们手动调整了重传参数，才解决了问题。
避坑指南：我曾经在嵌入式设备上调试DTLS握手，发现某些低端芯片的随机数生成器太慢，导致握手延迟飙升。后来改用硬件随机数生成器，问题才解决。如果你也在做嵌入式WebRTC，记得关注随机数性能。
1.3 SRTP加密：保护你的音视频数据
DTLS握手完成后，双方就协商出了一套加密密钥。接下来，这些密钥会被用来加密实际的音视频数据。这里用的就是SRTP——Secure Real-time Transport Protocol。
SRTP不是从零发明的加密协议。它是在标准RTP的基础上，增加了加密和认证功能。具体来说：
- 加密：使用AES算法，默认是AES-128，也可以升级到AES-256
- 认证：使用HMAC-SHA1，防止数据被篡改
- 防重放：每个包都有序列号，接收方会检查是否收到过重复包
这里有个细节很多人会忽略：SRTP加密的是RTP的载荷，而不是整个包。RTP头部（比如序列号、时间戳）是明文的。为什么？因为中间的路由器、交换机需要根据这些头部信息做路由和QoS。如果全加密了，网络设备就没办法工作了。
注意：SRTP只加密载荷，不加密头部。这意味着攻击者虽然看不到你的视频内容，但可以知道你在什么时候发了多少数据包。这在某些场景下可能构成侧信道攻击风险。
1.4 证书与指纹验证：你是谁？我凭什么信你？
DTLS握手需要证书。但WebRTC用的不是CA签发的证书，而是自签名证书。为什么？因为WebRTC是P2P通信，没有中心化的证书颁发机构。每个客户端在启动时，都会生成一个临时的自签名证书。
那问题来了：自签名证书怎么验证？
答案是：指纹验证。证书的指纹，就是证书内容的哈希值。WebRTC会把证书指纹通过信令通道（比如WebSocket）传给对方。对方收到后，比对指纹是否匹配。如果匹配，说明这个证书确实是对方生成的，没有被中间人篡改。
这个过程，我习惯叫它“带外验证”。因为证书指纹是通过另一个通道传递的，不是通过DTLS本身。这相当于多了一层安全保障。
| 验证方式 | 说明 | 安全性 |
|---|---|---|
| CA证书验证 | 依赖第三方CA机构 | 高，但有单点风险 |
| 自签名+指纹 | 通过信令通道传递指纹 | 高，但依赖信令安全 |
| 无验证 | 直接信任对方证书 | 低，容易被中间人攻击 |
嗯，这里要注意：指纹验证的安全性，完全取决于信令通道的安全性。如果信令通道被劫持，攻击者可以替换指纹，从而实施中间人攻击。所以实际部署时，信令通道本身也要加密（比如使用WSS）。
1.5 整体流程：一张图看懂
说了这么多，我们来画一张流程图，把整个安全体系串起来。
1.6 实战中的注意事项
理论说完了，聊聊实战中容易踩的坑。
第一，证书过期问题。自签名证书虽然没有CA签发，但依然有有效期。默认情况下，WebRTC生成的证书有效期是30天。如果你的应用需要长时间运行（比如视频监控），记得在证书过期前重新生成并重新握手。
第二，指纹变更。每次重新生成证书，指纹都会变。如果你的应用依赖固定的指纹做白名单，那就要小心了。我见过有人把指纹硬编码在配置文件里，结果证书一更新，所有连接都断了。
第三，性能开销。DTLS握手涉及非对称加密，在低端设备上可能耗时几百毫秒。如果你做的是实时性要求极高的应用（比如远程手术），建议提前建立好DTLS连接，避免在关键时刻握手。
总结一下：WebRTC的安全体系，本质上是一套“先验证，后加密”的流程。DTLS负责握手和密钥协商，SRTP负责数据加密，自签名证书和指纹负责身份验证。三者配合，才构成了一个完整的、从信令到媒体的安全闭环。
好了，这一章就到这里。下一章我们会深入DTLS握手的细节，看看每个消息的具体格式和交互过程。到时候我会带上Wireshark抓包截图，咱们一起手撕协议。