本文档说明当前版本（快速开发阶段）里已经识别出的安全边界、已知风险与后续改进方向。

当前 child host 向 parent host 注册，以及 child 与 parent 之间的 WebSocket 握手，主要依赖对方自报的 .well-known 信息。

这意味着当前流程更偏向“声明式信任”：

• child 注册到 parent 时，会提交自己的 .well-known
• child 建立到 parent 的 WebSocket 连接时，也主要基于这份自报信息完成握手
• parent 当前并没有对 host 身份做严格的 credential 校验

换句话说，当前实现里 .well-known 更像“身份声明”，还不是“强认证凭证”。

由于 host 之间注册和握手目前缺少严格认证，恶意方理论上可以伪造一个 host：

• 冒充合法 child 向 parent 发起注册
• 冒充合法 host 与 parent 建立 WebSocket 连接
• 伪造 .well-known 内容，诱导 parent 接受错误的拓扑关系

这会使 host 注册关系成为当前系统里较容易被攻击的入口之一。

如果好友建立流程只依赖对方自报身份，而没有更强的认证或多方确认机制，那么攻击者也可能：

• 冒充某个 entity 发起好友建立
• 利用用户对地址、名字或来源的误判建立错误信任
• 在后续消息交互中伪装成可信联系人

当前版本的 host-to-host 注册、WebSocket 握手与好友建立机制，尚不能视为严格安全认证方案。

在没有额外认证能力之前，系统更适合：

• 受控环境
• 开发测试环境
• 有外部信任边界保护的内网部署

不应默认认为当前机制已经足以抵御恶意 host 冒充或身份伪造。

由中央服务器管理 entity 与 host 的身份信息，作为可信注册与校验中心。

可行方向包括：

• 由中心平台统一登记 host 与 entity 的身份材料
• child 向 parent 注册时，附带由中心平台签发或可验证的身份凭证
• parent 在接受注册和 WebSocket 握手前，先校验凭证有效性

这个方案的核心是把“自报身份”升级为“由可信平台背书的身份”。

在没有中心平台的前提下，可以引入更强的去中心化认证机制，例如多人确认或多方签名：

• 新好友关系不是单方声明即生效，而是要求额外确认
• host 注册不是单次上报即接受，而是结合已知可信节点做交叉验证
• 对关键身份变更引入多人认证或观察期

这个方案的核心是降低单点伪造身份即可建立信任的风险。

从安全角度看，当前最需要明确的一点是：

.well-known 只能作为发现信息和初始声明，不能作为严格身份认证依据。

因此，后续如果要继续推进多 host 互联，建议优先补齐以下能力：

• host credential 机制
• 注册阶段的身份校验
• WebSocket 握手阶段的对端认证
• 好友建立阶段的更强验证流程

在这些能力补齐之前，应在文档和实现中明确标注：当前注册与握手流程存在 host 冒充和好友冒充风险。