feat(tunnel): add optional encryption for non-TLS Aether-tunnel traffic

[RWDai]

背景

当前 tunnel 节点会根据 aether_url 构造回连协议：

• https://... -> wss://.../api/internal/proxy-tunnel，Aether ↔ tunnel 之间由 TLS 保护。
• http://... -> ws://.../api/internal/proxy-tunnel，Aether ↔ tunnel 之间不是 TLS，会导致 tunnel 帧明文传输。

这里讨论的重点是 Aether ↔ tunnel 这段 tunnel 通道本身。origin/provider 目标是否是 HTTPS 与这个需求无关；即使 origin 是 HTTPS，只要 Aether ↔ tunnel 使用 ws/http，Aether 发给 tunnel 的请求元数据、headers、body，以及 tunnel 返回的响应数据，在这段通道上仍然缺少 TLS 保护。

需求

为 tunnel 增加一个可配置功能：当 Aether ↔ tunnel 使用非 TLS 通道（ws:// / http://）时，可以对 tunnel 帧或 payload 做应用层加密封装，避免这段链路裸明文传输。

示例配置名可以是：

encrypt_non_tls_tunnel = true
# 或 tunnel_payload_encryption = true

setup 中也应提供对应选项，例如：

Encrypt Aether <-> tunnel traffic when the tunnel connection is not TLS?

期望行为

1. 该功能是一个真实的加密开关，不只是 warning。
2. 开启后，即使底层连接仍是 ws://，Aether ↔ tunnel 之间承载的 tunnel 请求/响应内容也不应以可读明文出现。
3. 加密范围应覆盖 tunnel 数据帧中的敏感内容，例如请求 URL、headers、body、响应 headers/body 等。
4. 该功能应兼容现有 wss:// 模式；如果底层已经是 TLS，可以允许关闭、跳过或作为双层加密选项，由实现设计决定。
5. setup 和文档需要明确说明：这个选项保护的是 Aether ↔ tunnel 这一段，不讨论也不改变 tunnel ↔ origin/provider 的协议选择。

非目标

• 不讨论 origin/provider 是否为 HTTPS。
• 不要求把 origin HTTP 自动升级成 HTTPS。
• 不要求强制 aether_url 必须是 https://。
• 不只是提示用户 http/ws 有风险，而是提供可配置的加密能力。

可能实现方向

• 在 tunnel protocol 的 RequestHeaders / RequestBody / ResponseHeaders / ResponseBody payload 层增加加密封装。
• 增加协议版本协商，只有 Aether 和 tunnel 都支持时才启用。
• 使用管理 token 派生会话密钥，或增加独立的 tunnel encryption key。
• 为每条 WebSocket 连接或每个 stream 增加 nonce/序号，避免重放或 nonce 复用。
• 保留向后兼容：未开启或旧版本节点继续使用现有明文 frame 协议。

验收标准

• 配置文件和 setup 中有可持久化的“非 TLS tunnel 通道加密”选项。
• 开启后，ws:// Aether ↔ tunnel 通道中的敏感 tunnel payload 不再是可读明文。
• Aether 和 tunnel 两端完成协议能力协商，版本不兼容时给出清晰错误或自动回退策略。
• 文档明确区分：
  • wss:// = 传输层 TLS；
  • ws:// + tunnel payload encryption = 非 TLS 传输上的应用层加密；
  • tunnel ↔ origin/provider 不属于本 issue 范围。
• 测试覆盖开启/关闭该选项，以及非 TLS tunnel 下请求和响应仍能正常转发。

[RWDai]

整理一下收敛后的方案：MVP 不需要同时新增 tunnel_encryption_key_id 和 tunnel_encryption_key，只新增一个 tunnel_encryption_key 就够了。

核心结论

key_id 不是密码学必需项。它只是 key rotation / 多 key 并存时的 selector，用来让 server 快速判断该用哪把 key。第一版完全可以不做。

MVP 建议配置面只保留：

[[servers]]
aether_url = "http://aether.example.com"
management_token = "ae_xxx"
node_name = "jp-1"
tunnel_security = "non_tls_required"
tunnel_encryption_key = "base64-32-bytes..."

其中：

• tunnel_security 控制是否启用非 TLS secure tunnel；
• tunnel_encryption_key 是该 Aether server entry / tunnel 节点使用的长期 PSK；
• 每条 WebSocket 连接仍然应生成临时密钥材料，并通过 PSK-authenticated handshake 派生本连接的 AEAD session keys。

为什么不需要 tunnel_encryption_key_id

握手时 client 已经会发送 X-Node-Id，server 可以直接用：

node_id -> tunnel_encryption_key

来找到对应的 PSK。

也就是说，node_id 本身已经足够作为 key lookup 的主索引。

key_id 只有在这些场景才有价值：

• 同一个 node 同时存在多把 active key；
• 想做非常平滑的 key rotation；
• server 不想尝试 current/previous 两把 key；
• 审计日志里需要精确标识 key version。

这些可以留到后续版本，不需要压到 MVP。

key rotation 可以先不靠 key_id

如果后续要做轮换，第一版也可以不用显式 key_id：

node_id -> current_key
node_id -> previous_key

握手时：

1. 先用 current key 验证；
2. 失败再试 previous key；
3. 轮换窗口结束后删除 previous key。

这样能支持基本平滑轮换，同时不增加用户配置复杂度。

多 Aether / 多 tunnel 的模型

一个 Aether 对多个 tunnel

推荐每个 tunnel node 一把独立 key：

Aether
  node jp-1 -> key_a
  node us-1 -> key_b
  node sg-1 -> key_c

不要所有 tunnel 共用一把全局 key，避免单个节点泄露影响全部节点。

一个 tunnel 对多个 Aether

现有 [[servers]] 模型天然支持，每个 server entry 一把 key：

[[servers]]
aether_url = "http://aether-1.example.com"
node_name = "jp-1"
tunnel_security = "non_tls_required"
tunnel_encryption_key = "base64-key-for-aether-1"

[[servers]]
aether_url = "http://aether-2.example.com"
node_name = "jp-1"
tunnel_security = "non_tls_required"
tunnel_encryption_key = "base64-key-for-aether-2"

不建议多个 Aether 复用同一把 key。

交互上怎么避免用户手填

虽然配置文件里会有 management_token 和 tunnel_encryption_key，但普通用户不应该手动填。

建议管理端“添加 tunnel 节点”时自动生成：

• management_token
• tunnel_encryption_key

然后继续沿用当前一键安装体验，把它们注入安装命令：

AETHER_TUNNEL_AETHER_URL="http://aether.example.com" \
AETHER_TUNNEL_NODE_NAME="jp-1" \
AETHER_TUNNEL_MANAGEMENT_TOKEN="ae_xxx" \
AETHER_TUNNEL_SECURITY="non_tls_required" \
AETHER_TUNNEL_ENCRYPTION_KEY="base64..." \
sh install.sh

install/setup 负责写入 aether-tunnel.toml。用户感知上仍然是一条复制粘贴命令。

后续如果要进一步简化，可以再做一次性 provisioning token：

AETHER_TUNNEL_PROVISIONING_TOKEN="atp_xxx" sh install.sh

由 install 脚本向 Aether 拉取完整 server entry，成功后 provisioning token 作废。但这可以作为后续优化，不影响 MVP。

安全边界

非 TLS secure tunnel 至少应保证：

1. ws:// 下不再明文发送 management_token；
2. WebSocket Upgrade 后先完成 PSK-authenticated handshake；
3. 握手成功前不发送任何 relay frame；
4. 后续 RequestHeaders / RequestBody / ResponseHeaders / ResponseBody 使用 AEAD 加密；
5. frame header 可保持明文，但应作为 AEAD AAD 防篡改；
6. non_tls_required 遇到不支持的旧端应明确失败，不能静默回退明文。

同时文档需要明确：

• wss:// 仍是推荐方案；
• ws:// + secure tunnel 保护 Aether ↔ tunnel 的 token 和 payload 不明文传输；
• 它不等价于 HTTPS 伪装，也不保证不可被 DPI/GFW 识别；
• tunnel ↔ origin/provider 不属于这个选项的保护范围。

建议 MVP

MVP 字段收敛为：

tunnel_security = "off" | "non_tls_required"
tunnel_encryption_key = "base64-32-bytes..."

不引入 tunnel_encryption_key_id。以后确实需要多 key selector / 更复杂 rotation 时，再作为内部字段或高级字段补上。