摘要

  • MBONED 组播安全草案第 01 版是仍可能变化的 Informational Internet-Draft，不是 RFC，也不证明任何浏览器已经实现。
  • 共享密钥让接收端解密，不等于证明目标发送端创作了每个内容单元；朴素的对称认证还可能赋予接收端伪造能力。
  • 逐单元认证必须在内容进入解析器和渲染器前完成；对象级最终校验可能在计算、内存和恢复成本已经发生后才失败。
  • 来源、重放与缺失、请求绑定、来源站许可、私密模式同意以及用户可见结果分别需要回执。

“已经解密”不是安全释放状态

解密回答的是接收端是否持有打开密文的材料。它没有自动回答材料是谁生成的，也没有证明内容应该交给哪个请求、哪个解析器或哪次用户操作。在一对多系统中，多台设备往往共享同一解密材料，这使两类权力更容易混淆。

如果同一对称秘密既用于解密又用于证明发送者，那么持有秘密的接收端也可能生成其他成员会接受的标签。草案并未说所有组安全方案都如此；它指出协议必须加入某种认证不对称性，使“可以听”不能自然升级为“可以代表源站说话”。

浏览器的释放门必须依赖这个来源判决，而不是依赖解密成功。解析器、编解码器与渲染代码都是大型攻击面。先使用、后认证，会把最终失败变成迟到的取证，而不是有效的前置控制。

时间不对称也有成本

TESLA 不靠公钥签名制造不对称，而是延迟公布对称验证材料。接收端先缓存数据，等到预定时间之后得到密钥，再验证此前到达的内容。密钥公布后才到的数据必须丢弃。

这项设计把来源权力与普通接收者分开，却产生明确的时间合同：双方需要足够的时钟同步，应用还要承受超过单向传播时延的等待。低延迟目标不能把这段等待偷偷删掉，否则认证机制仍存在于文档里，数据却已经进入高风险代码。

运维记录应保存接收时间、认证区间、预计披露时间、实际披露时间、判决与释放时间。只记“标签最终有效”无法证明解析器是否在有效判决前看过字节。

签名与清单把信任搬到别处

逐包非对称签名让发送端保管签名私钥，接收端只持有验证材料。这样可以减少共享秘密带来的说话权膨胀，但验证公钥从哪里来、为何属于目标源、适用于哪个时期仍需独立证明。

AMBI 一类方案通过经过认证的带外通道分发有序摘要清单。内容包与清单相符，才能得到来源与顺序证据。清单通道的认证是前提；父页面来源提供的 HTTPS 地址可以成为一种关联方式，但这只是架构例子，不是部署证明。

每种机制都把信任放在不同位置。公钥方案依赖密钥来源，TESLA 依赖时间与延迟，清单方案依赖带外通道、覆盖范围和缺口处理。统一的“安全组播”开关会遮住这些不同的失败方式。

对象末尾的判决可能已经太晚

若系统只在完整对象组装后核对摘要，一个注入包就可能让整个对象失效。在最终失败前，接收端已经缓存片段、排序、纠错，甚至部分解码。许多接收端随后发起单播恢复，一次小注入便可能放大成对内容提供者的大量请求。

逐包认证能更早丢弃篡改或伪造单元，但它仍不提供完整的顺序、唯一性与完备性。UDP 没有原生可靠交付、按序、去重和重放防护。序列号、TESLA 时间区间或严格有序的摘要清单必须分别暴露重复、重排和缺失。

因此监控需要两个分母：每个包的认证失败率，以及每个失败包触发的恢复工作量。很低的错误率也可能有很高的容量代价，尤其当同一热门对象被许多接收者同时重建。

真实来源仍可能回答错误请求

HTTPS 单播通常在同一受保护会话中关联请求与响应。组播数据通道天然单向，并不携带单个客户端发出的请求。两个通道都可以由可信来源签名，但属于不同对象、不同权限或不同版本。

若没有额外的密码学绑定，路径上的对手可以在两个客户端均信任的通道之间交换数据。包的签名不一定失效，来源也没有变，错误发生在“这份数据回答哪次请求”。

应用必须验证请求标识、对象标识、版本或等价上下文是否进入认证覆盖范围。来源认证回答谁说了，请求绑定回答为什么这次交付属于我，业务授权回答能否使用，用户结果回答实际发生了什么。四者不能共用一个成功状态。

浏览器许可与网络熔断不是同一权力

恶意来源站可以诱导浏览器加入大量组播通道。浏览器首先应限制通道与承载页面来源的关系，或要求类似跨来源授权的明确许可。这项控制保护用户不被网页任意订阅，不代表上游网络还有容量。

接入路由器可以观察异常订阅扇出，在过载或滥用时实施熔断，可能优先停止不受欢迎的内容。它保护共享网络资源，却无权替内容来源签名，也不决定应用是否接受某个对象。

私密浏览模式还要面对 IGMP 或 MLD 暴露的成员信息。草案建议加入前取得用户明确批准。批准的是一个可观察的网络动作，不是内容真实性、绝对匿名或最终观看结果。

加密不会抹掉共同交付

加密可以阻止没有密钥的一方读出载荷，却不自动隐藏包长、节奏、端点和协议模式。组播还有一个特殊事实：路径观察者可以判断相同内容被送往多个接收方向，即使它看不懂密文。

某台接收设备被攻破时，当期组密钥与明文可能一起暴露。通过 TLS 1.3 等前向保密单播通道逐个鉴权并交付短期组密钥，再按时期轮换和删除，可以限制后续长期密钥泄露对旧流量的影响。

但轮换日期不是删除回执。系统还需证明发送端已经切换、接收端不再接受旧时期、设备清除了旧秘密。成员表中删除一行不等于密码学排除已经完成。

建立逐层可追责账本

账本应分别记录：接收端准入、授权决定、密钥时期、交付通道、安装确认、验证密钥或清单身份、逐单元认证、序列与重放状态、缺失与恢复、请求绑定、来源站许可、私密模式同意、向解析器释放以及应用结果。

日志不得保存组秘密或个人内容。可对设备、请求与对象标识做哈希，并按时期保留。关键是事故发生时能知道哪一层的哪个主体作出了什么判断。

告警应覆盖：同一秘密在没有不对称控制时兼任解密和来源证明；认证前使用；TESLA 披露后到达；清单缺口；恢复放大；通道交换；未获来源许可的加入；私密模式无同意加入；密钥退役后继续接受。

来源与限制

冻结材料包括第 01 版草案及 Datatracker 状态、历史与引用，MBONED 工作组，互联网与 UDP 威胁模型 RFC，SSM 与跨域 ASM 退役，TLS 1.3，TESLA、NORM、ALC 与组播认证，以及 WebRTC 安全、Client Hints、QUIC、WebTransport 与 AMBI 记录。

这些材料证明协议文字与官方状态，不证明实现一致性、采用率、性能、真实注入、接收端失陷、隐私事件或浏览器渲染结果。开篇为检验控制链而构造。

来源