6.2 DTLS 与 SRTP 安全层

6.2 DTLS 与 SRTP 安全层

线路打通之后、媒体开通之前，中间隔着一场加密握手。本节讲这场握手怎么进行、密钥从哪来、逐包加密怎么生效，以及安全类故障的定位方法。安全层是全书"信任链"设计的集中体现：信任不经过任何中间方，全部在两端之间当面建立。

握手：角色、身份与密钥

握手的三件套在协商阶段就已备好。角色：会话描述里的设置属性提前约定了谁主动谁响应，避免了双方同时抢发或互相等待的死局。身份：两端各自生成一张自签证书，把证书的指纹写进会话描述经信令送达对端；握手时对端出示证书，引擎用先前信令里收到的指纹逐字节核对——对得上才继续，对不上立即断开。密钥：握手成功后，双方从握手材料里各自导出对称密钥，这套密钥从未在任何报文里明文出现过，信令服务器看不到、中转服务器也看不到。

握手发生在第三章选出的线路上，因此它天然验证了线路不仅"通"而且"通到正确的人"。这也解释了一个安全设计的关键点：指纹核对把"信令通道"与"媒体信任"解耦——即使信令被劫持，劫持者拿不出与指纹匹配的证书，媒体照样建不起来；最坏结果是连不上，而不是被窃听。

逐包加密由安全实时传输协议承担：握手导出的密钥交给加密库，发送侧对每个媒体包的载荷加密、追加认证标签，接收侧验签解密。认证标签让任何篡改都会被当场识破。加密只覆盖载荷与部分头部扩展，基础头部保持明文——前节说过，这是排错能力的关键保留。密钥还支持按会话周期轮换，长通话的密钥泄露窗口被进一步压窄。

安全类故障的两张脸

安全故障在表象上都是"握手不成、媒体不开"，但根因分两大类，处置方向完全相反。第一类是身份核验失败：指纹对不上、证书格式异常、握手消息校验不过。它的日志特征是握手进程走完了若干步后明确报出核对类错误，抓包里能看到完整的往返。这类是配置问题——证书生成流程出错、会话描述被中间件改写、指纹字段被截断，逐项核对配置即可。

第二类是网络阻断：握手报文根本过不去。它的特征是握手停在最初几步，重传若干次后超时，典型于只放行普通网页流量的企业网络——媒体端口的握手包被策略拦截。处置方向是基础设施：部署中转并走复用端口的传输形态，让加密流量伪装成普通网页流量穿过策略，这正是第 8.2 节部署清单的由来。

区分两类故障的速判法则：抓包里有来有回是配置问题，只有去没有回是网络问题。这一句能在排错的第一分钟把方向定对，价值极大。

密钥的生理周期

密钥并非终身制。引擎支持会话内轮换：握手材料可以按周期重新协商，新旧密钥在切换窗口内并行可用，媒体流无感换锁。轮换的意义在于压缩单把密钥的暴露窗口——长通话、高价值会议场景下，密钥暴露面随时间累积，周期性换锁把风险切成短段。默认周期以小时计，对绝大多数产品无感；金融、医疗类客户的安全审计常把"是否支持会话内轮换"写进合规项，工程上把它当标准能力对待即可。

与轮换相关的排错点也交代一句：切换窗口内新旧密钥有一小段共存期，若两端时钟或重传节奏异常，偶发的解密失败会落在这段窗口里，日志特征是"解密失败计数短暂抬升后归零"。看到这种形态不必惊动安全团队，那是换锁的门缝，不是入侵。

握手期间媒体会丢吗

会丢一小段。握手完成之前没有密钥可加密，媒体只能排队等候，握手时长直接决定"接通到出声"的延迟。这也是为什么握手在线路上的往返次数值得优化——每次往返都直接加在首帧延迟上。中转与复用端口方案除了穿策略，顺带还稳定了握手路径，对首帧延迟同样友好。

自签证书会过期吗

引擎按会话生成临时自签证书，生命周期与会话绑定，不存在长期证书的过期问题。指纹核对的对象就是这张临时证书，因此会话描述必须在握手开始前送达对端——信令时序混乱会让指纹核对无据可依，表现为握手在核对环节失败。

安全层的观测点

加密让内容不可读，但安全层自身的运行状态是完全可观测的，把三个最有用的观测点列出来。握手阶段计数：握手走到第几步有明确的状态记录，卡在哪一步直接指示故障类别（见上一节的两张脸）。解密失败计数：稳态通话里它应恒为零，非零即异常——偶发且伴随密钥轮换是换锁门缝，持续增长是密钥或实现出了真问题。证书与指纹的自检：引擎可导出本次会话实际使用的证书指纹，与会话描述里的声明比对，这是排查"中间被调包"疑虑的直接手段。

把这三个观测点接入监控，安全类故障就从"最吓人的故障"变成"最可测的故障"——它的一切异常都会在计数与状态上留痕，恰恰是全书可观测性最好的子系统之一。

案例：一批专线客户"全员连不上"的定位

背景。某客户在内部专线网络里试点，所有终端连接失败，而同一套服务在公网环境完全正常。接入方怀疑引擎缺陷，工单升级到定制团队。

操作。先抓包：握手只有客户端问候持续重传，服务端问候从未出现——只有去没有回，初判网络阻断。为验证，让客户 IT 在策略里放行媒体端口后复测，握手立刻走完、媒体开通，证实初判。但放行端口在客户安全规范里不可接受，于是切换方案：部署中转并启用复用端口的传输形态，媒体握手与数据全部封装在标准网页端口上。

结果。免放行方案上线后，专线环境连接成功率达到公网水平，客户安全团队审阅流量形态后予以放行。

解读。这个案例的两点经验值得沉淀：其一，安全故障先分两张脸再动手，能省掉大量无效排查——本案若先查证书链就南辕北辙了；其二，企业网络里的实时通信部署，"穿策略"不是可选项而是必选项，产品化的中转与复用端口方案要在架构早期就位，而不是等客户撞上再说。

变式。偶尔会遇到指纹核对失败与网络问题并存的混合形态：握手能走几步但中途失败，根因是中间件对会话描述做了改写，指纹字段被损坏。此时抓包里握手有来有回但报错在核对环节——按配置问题查，最终落到信令链路的中间件上。这提醒我们：信令虽不接触密钥，但信令的完整性同样在信任链上。

要点回顾

本节要点：握手角色在协商时预定，指纹经信令交换、在握手时当面核对，密钥从握手材料导出、从不经过任何中间方；逐包加密覆盖载荷、保留头部明文；安全故障分身份核验与网络阻断两张脸，看抓包有无往返即可速判；企业网络部署必须自带穿策略方案。下一节看同一条加密管道上的另一个乘客：数据通道。