Radicle 披露关键协议漏洞，私有仓库明文传输导致机密性失效

一句话结论

Radicle 核心协议缺陷致使私有仓库数据以明文传输且允许身份冒充，所有现有节点版本机密性失效，建议立即暂停明网运行。

关键要点

• radicle-node 在完成 Noise XK 握手后丢弃加密状态，后续 Gossip 元数据、路由表及 Git 对象包均通过未加密 TCP 套接字以明文传输。
• 存在身份验证漏洞，攻击者可利用捕获的明文节点 ID 冒充白名单节点，直接从种子节点拉取私有仓库。
• 缺陷根源在于底层 Rust 代码库 Heartwood 中传输配置与帧分发架构分离，帧分发层在写调用期间绕过了加密例程。
• 维护者建议立即暂停明网私有仓库运行，团队须将明网连接中的私有仓库视为已泄露并轮换加密令牌、凭据及生产环境密钥。
• 自定义 Noise 传输层将被弃用，转而采用基于 QUIC 和 TLS 的开源点对点协议栈 Iroh，此次升级将打破网络向后兼容性并导致硬性网络分区。

背景与事实

点对点代码协作网络 Radicle 披露了其核心网络协议中存在的两个关键安全漏洞，这些漏洞使得迄今为止所有节点版本的机密性不复存在。独立工程师 Kostis Maninakis 发现，虽然 Radicle 在建立连接时会执行 Noise Protocol Framework 握手流程，但该守护进程会在协商完成后立即丢弃生成的加密状态。Radicle 采用了基于原始 TCP 套接字的三消息 Noise XK 握手模式，发起方和响应方交换临时密钥和长期公钥并推导出两个对称会话密钥，这一操作过程在密码学中被称为“拆分”（split）。然而，radicle-node 会将这些推导出的密钥以未加密的形式保存在内存中，此后的一切通信均以明文形式直接通过未加密的 TCP 套接字进行传输。

除了传输过程未加密外，连接握手过程还存在一个身份验证漏洞。攻击者可以通过提供与白名单中的对等节点关联的伪造节点 ID 来建立连接。路径上的窃听者可以被动地捕获以明文形式传输的有效节点 ID，随后利用该身份验证漏洞冒充已获授权的对等节点，直接从种子节点拉取私有仓库。该核心缺陷源于底层 Rust 代码库 Heartwood 中传输配置与帧分发之间的架构差异。在初始化过程中，网络状态机处理 Noise 握手，但帧分发层在写调用期间绕过了加密例程。

在捕获两个本地守护进程之间的网络流量并进行检查后发现，握手完成后的传输帧中并不包含任何身份认证标签或流密码。帧布局以原始的 Radicle 协议魔术字节序列开头，紧接着是未加密的 Git 压缩文件头。由于传输帧省略了消息认证码，中间网络设备可以被动地记录或重新排序数据包。Git 内容的完整性得以保持，因为 Git 对象采用的是内容寻址且引用经过了加密签名，这意味着攻击者无法在不让签名失效的情况下修改仓库内容，但传输的机密性却无法得到保障。

影响分析

对于中文开发者与从业者而言，此漏洞构成严重的供应链安全风险。使用 Radicle 的软件团队必须立即采取防御性措施。首先，必须将通过明网连接克隆、推送或分发的所有私有仓库视为已遭泄露。工程负责人应立即轮换存储在这些仓库中的任何加密令牌、凭据或生产环境密钥，以阻断潜在的数据泄露路径。其次，在修补后的二进制文件发布之前，各团队必须将节点操作限制在隔离的覆盖网络内。运维人员可以在已授权的主机之间配置加密的 WireGuard 隧道或 SSH 端口转发，例如使用 `ssh -N -L 8776:127.0.0.1:8776 seed-node.internal.infra` 将全局代理标志设置为指向 Tor 出口节点并不能解决这个安全隐患，因为离开出口节点的流量会以明文的形式流经公共互联网。只有在连接完全经由已通过身份验证的 Tor 洋葱服务或 I2P 守护进程进行时，才能真正地保持点对点机密性。

适用边界

该安全结论与缓解措施主要适用于使用 Radicle 现有节点版本进行明网连接的私有仓库管理场景。将全局代理指向 Tor 出口节点无法解决安全隐患，因为出口后的流量仍以明文流经公共互联网。只有当连接完全经由已通过身份验证的 Tor 洋葱服务或 I2P 守护进程进行时，才能在当前版本中保持点对点机密性。此外，由于现有协议缺乏版本协商功能，向后兼容的网络层缓解措施无法部署，因此隔离网络与架构改造是唯一的可行路径。

孤本观察

基于本文事实，尽管 Git 内容寻址与签名机制保护了数据的完整性，使得攻击者无法篡改仓库内容，但传输层的机密性失效与身份验证漏洞的组合，暴露了去中心化网络在默认配置下对隐私保护的严重缺失，这提醒开发者不能仅依赖底层数据结构的完整性来保证整体通信安全。

来源：InfoQ 中文 AI