py-libp2p WebRTC 证书测试中的假绿灯陷阱

WebRTC-Direct 在 libp2p 中的设计较为特异：它将 TLS 证书哈希直接嵌入 multiaddr 中，即 /webrtc-direct/certhash/<hash>。在拨号时，通过 DTLS 握手获取对端证书，计算其哈希值并与 multiaddr 中声明的哈希进行比对。整个流程无需依赖 CA 机构，multiaddr 本身就充当了证书 pin 的角色。

为使 aiortc 使用 libp2p 生成的证书，py-libp2p 初期采取了如下实现方式：

config = RTCConfiguration(certificates=[rtc_cert])
return RTCPeerConnection(configuration=config)

直接设置证书属性失效的原因

在 aiortc 1.5 之后，这种写法会直接抛出 TypeError，因为 certificates= 参数已被移除。常见的修改方案是将证书赋值到实例属性上：

pc = RTCPeerConnection(configuration=config)
pc._certificates = [rtc_cert]  # 看着对劲，实则无效
return pc

所有单元测试均通过，loopback echo 测试也未报错：建立 data channel，发送 payload，接收 payload，整个流程看似正常。这一版本几乎被合并至 main 分支并发布。

但问题隐藏在 pc._certificates 上。aiortc 内部并不读取该属性，它实际使用的字段是 self.__certificates。由于 Python 对类体中以双下划线开头的属性进行 name mangling，最终编译为 self._RTCPeerConnection__certificates。

从外部设置 _certificates 时，实际创建的是一个新的属性，这与 aiortc 所使用的私有属性毫无关系。参与 SDP 生成、写入 a=fingerprint 的仍然是 aiortc 自动生成的证书。

由此引发了以下错位：

证书哈希不匹配导致拨号失败

• multiaddr 中广播的是 我们自身 的证书哈希
• DTLS 握手使用的是 aiortc 自动生成 的证书
• 实际拨号失败，并报出 Remote DTLS fingerprint does not match certhash

loopback 测试通过是因为它根本不校验 fingerprint 与 multiaddr 是否匹配，仅简单地将收到的字节原路返回。被绕过的恰恰是唯一与证书 pin 相关的安全属性，而这正是测试覆盖盲区。

如何通过 Name Mangling 修复该 Bug？

修复方法是显式写入 mangled name，且必须在任何 SDP 操作触发之前完成：

pc = RTCPeerConnection(configuration=config)
pc._RTCPeerConnection__certificates = [rtc_cert]  # 这才是真正的槽位
return pc

循环回测还需补充一项检查：解析对端 SDP 中的 fingerprint，并与 multiaddr 中的 certhash 进行比对。缺少这一步，测试全绿并不能证明证书 pin 功能正常运行。

每次升级 aiortc 时，我都会首先执行 grep -r "__certificates" site-packages/aiortc，确认内部字段名是否发生变更。库的私有实现随时可能调整，但只要仍采用双下划线命名，name mangling 规则不可忽视。属性名不能凭直觉填写，应检查 dir(pc) 中真正带有类名前缀的字段。