5.1 DTLS握手与SRTP

5.1 DTLS 握手与 SRTP

本节摘要：DTLS（Datagram Transport Layer Security）是 TLS 适配 UDP 的版本，在 WebRTC 里它一身兼三职：用证书指纹验证对方身份、用握手产物导出媒体加密密钥、在自身之上承载数据通道。本节讲透握手流程与指纹比对，解释 SRTP 密钥的导出机制，并正面回答那个高频安全问题——信令服务器能不能偷听通话。

本节的学习收获

阅读完本节，你应当能够：

1. 说出 DTLS 与 TLS 的关系，以及为什么 WebRTC 不能直接用 TLS；
2. 描述 DTLS 握手在 WebRTC 里的时机：通路打通后、媒体开讲前；
3. 解释证书指纹与 SDP 的绑定关系，以及它如何防中间人；
4. 描述 SRTP 密钥的导出路径，说明密钥为什么不出终端；
5. 用「加密层次」回答「谁能听到通话内容」的边界问题。

一、问题与直觉：给 UDP 穿上 TLS 的铠甲

WebRTC 的媒体跑在 UDP 上，图的是低延迟；但 TLS 的握手与传输建立在 TCP 的可靠字节流假设上——TLS 直接搬过来会在 UDP 上碎一地。DTLS 就是把 TLS 的每一层适配到数据报世界：握手消息加编号防丢防重放，丢了的握手包重传，记录层的分块对齐数据报。对应用层而言，DTLS 提供的安全承诺与 TLS 相同——身份认证、密钥协商、数据加密——只是底层换了传输介质。

WebRTC 对 DTLS 的用法比常规更巧妙：DTLS 握手完成后，密钥并不用于加密 DTLS 通道里的「网页数据」，而是导出给 SRTP 用。媒体在 DTLS 通道之外以 SRTP 形态传输——这样媒体不必承担 TLS 记录层的封装开销，能直接跑在高效的 RTP 打包格式上，同时密钥安全性与 TLS 同级。这套组合的正式名称是 DTLS-SRTP。

时序上要记得它的位置：ICE 探测成功只是「路通」，DTLS 握手才宣告「人真、话密」。你观察状态机时会发现 iceConnectionState 已到 connected 而 connectionState 还在 connecting——中间隔着的正是 DTLS 握手。

二、核心原理：指纹、握手与密钥导出

第一步，指纹入约。 每个终端为本次通话生成一张自签证书，把证书的摘要（指纹）写进 SDP 的属性行，随 offer 与 answer 走信令交换。DTLS 握手开始后，对端出示证书，本地把证书算出摘要、与 SDP 里那份比对——一致才继续。中间人能拦截信令、能篡改 SDP 吗？能，但那属于信令通道被攻破的问题；只要指纹经信令送达且信令通道本身是 TLS 加密的，中间人就无法在媒体路径上顶替任何一方，因为他拿不出与指纹匹配的证书私钥。

第二步，握手交换。 双方走完整 DTLS 握手：协商加密套件、交换证书、各自验证指纹、完成密钥交换。握手产物（共享密钥材料）留在两端。

第三步，密钥导出。 两端用同一套密钥导出规则，从握手产物里派生出 SRTP 会话密钥。关键点在于：密钥材料只存在于两台终端的内存里。信令服务器经手的 SDP 里只有指纹（公开可算的摘要），没有密钥；TURN 中继转发的只是密文。所谓「端到端加密」在 WebRTC 里不是营销词，而是协议结构。

图：从 DTLS 握手到 SRTP 开讲的密钥旅程

三、工程实践要点：安全边界与常见疑问

三个高频疑问给出协议级的答案。疑问一：信令服务器能听到通话吗？ 听不到。它见到的只有指纹与候选，媒体密钥在两端内存里，中继链路上是密文。但它能干两件更隐蔽的事：向两端注入伪造的 SDP（把自己的指纹塞进去，完成中间人）——防御手段是把指纹的哈希在人机验证环节（如通话前的安全码比对）做带外确认，高安全场景才需要。疑问二：录制的文件是加密的吗？ 取决于录制在哪里发生：浏览器内用 MediaRecorder 录的是解密后的本地流；服务端录制发生在 SFU 解密再加密的环节，服务端当然看得见内容。疑问三：换个通话还用同一把密钥吗？ 不。每次连接独立握手独立导出，重协商也会更新。

💡 关键直觉：把 DTLS-SRTP 理解成「先验明正身，再当场配一把一次性的锁」。锁的钥匙谁也没带走，下次见面重新配。

完整案例：合规审查里的「中间人」质询

背景：某远程医疗产品过等保审查，评审人质疑：浏览器与信令服务器之间有 TLS，但媒体是端到端加密的，如何证明「平台方（含信令服务运维者）无法获取诊疗音视频内容」。

操作：团队做了三件事构成证据链。其一，文档化密钥路径：SDP 里只有指纹，密钥由 DTLS 握手产物导出、仅存两端内存，附上协议引用；其二，演示攻防：用代理截获全部信令流量，展示其中不含任何可用于解密 SRTP 的材料，而 SRTP 密文离开终端后全程密文；其三，披露边界：信令服务器具备理论上的中间人能力（注入伪造指纹），产品的对策是客户端在高敏感模式下展示「安全码」，两端用户核对一致即确认指纹未被替换。

结果：评审通过，安全码机制进入产品作为高敏感会话的可选开关。

解读：这个案例的价值在于把「端到端加密」的承诺边界讲清楚：WebRTC 的协议结构保证了密钥不出终端，但信令通道的完整性是另一道独立的题——「内容加密」与「身份防顶替」分属两层，混为一谈的承诺在审查与事故面前都站不住。

变式：对「平台绝对不可见」要求更极致的场景（如端到端加密群通话），业界的做法是在 WebRTC 之外再叠加一层端到端密钥协商（成员间用类似安全消息协议的双棘轮机制派生会话密钥，再把媒体轨道加密一层）。WebRTC 的 DTLS-SRTP 此时退化为「传输加密」，内容保密由应用层密钥体系负责——分层叠加而不是改造底层，是协议栈思维的典型用法。

本节要点回顾

• DTLS 是 UDP 版 TLS：为数据报世界适配了握手与记录层，WebRTC 用它验身份、出密钥、载数据通道。
• 指纹是身份锚点：证书摘要经 SDP 交换，握手时比对，中间人拿不出匹配的证书私钥。
• 密钥走导出不走传输：SRTP 密钥从握手产物派生，仅存两端内存，信令与中继全程不见密钥。
• 承诺要分层表述：内容加密是协议结构保证，防信令通道顶替需要带外确认等额外机制。
• 录制位置决定可见性：浏览器内录的是本地流，服务端录制天然可见内容，合规设计要前置选择。