4.3 四大安全信道协议横向对比

4.3 四大安全信道协议横向对比

本节摘要：选型争论的病根往往是拿一个维度打四个不同的题。本节把 TLS、Signal、Noise 框架、IPSec/IKEv2 摆上同一张桌子，按信任模型、前向保密粒度、元数据暴露、部署成本四个维度逐项对比，并给出一棵选型决策树。读完你能对具体场景给出有论证的协议建议，并说出所选方案明确不覆盖的威胁——后者才是选型成熟的标志。

先明确：它们不是竞争者

四个名字常被放进同一个"哪个更安全"的句子里，但先摆正关系。TLS 是应用层与传输层之间的安全信道，客户端-服务器模型，依赖证书体系。Signal 是端到端的消息协议，用户-用户模型，不依赖全球 PKI。Noise 是一个框架而非成品协议——它提供一组握手模式（数字编号标注各自的密钥交换结构），让你为点对点系统装配出定制的信道，许多现代工具的内部握手都出自 Noise 模式。IPSec/IKEv2 工作在网络层，把主机到主机或网络到网络的整条路径包进隧道，对上层应用完全透明。它们覆盖的地层不同：应用对话、个人消息、定制组件、网络管道。先问自己要保护的是哪一层，再谈选哪个——顺序反了就会得出"Signal 比 TLS 安全所以网站也该用 Signal"这类错位结论。

四维对比

这张表里最值得展开的是信任模型一行，它决定了一切。TLS 的证书体系把"身份正确"外包给证书机构——你信任的是一整套基础设施的纪律，好处是规模化、坏处是任何一次误签发都波及面广（证书透明日志就是为此而生的补救）。Signal 把身份锚在用户自己的比对行为上，安全上限更高（没有第三方能静默替换密钥），代价是把责任压给用户与产品交互。Noise 干脆不预设答案——框架让你选认证方式，也因此把"认证做没做对"的责任完整留给了实现者。IPSec 在企业内网场景用预共享密钥或内部证书，信任半径小而可控。

图 4-3 四协议能力对比矩阵

选型决策树

把对比表收拢成一棵可操作的树。第一问：保护对象在哪一层？应用与服务端之间的请求 → TLS；个人对个人的消息内容 → Signal 或其派生；自研系统内部组件间或嵌入式设备间 → Noise 模式；站点与站点、远程接入 → IPSec。第二问：身份的信任锚打算放哪？有成熟的内部 PKI 就走证书路线；没有且无法建设，预共享密钥或信任首用是现实选项。第三问：元数据敏不敏感？通信关系的图谱本身是资产（例如匿名举报、记者与信源），就要选能把元数据最小化的架构，协议只是其中一环，服务器的部署拓扑同样关键。第四问：运维预算多少？Noise 的高自由度对应高责任——没有现成的成熟实现与审计生态时，慎选。

⚠️ 选型汇报里最该写的一栏是"本方案不覆盖的威胁"：选 TLS 就写明端点安全与流量分析不在协议承诺内；选 Signal 类方案就写明初始信任依赖比对、备份同步扩大攻击面。把不覆盖的写清楚，比把覆盖的说漂亮更能证明选型的可靠。

最后给一个容易忽略的组合用法：分层组合是常态而非异端。应用用 TLS 连服务器、服务器之间用 IPSec 隧道互联、应用内部对用户内容再做一层端到端加密——三层各司其职，各自命题（2.3 节）互不重复也不留缝。评估这类系统时按层分别验证，不要试图用单一协议的结论覆盖整座楼。

三个场景走一遍决策树

决策树要实走才记得住。三个常见场景，各走一遍，重点看"论证过程"而非结论。

**场景一：公司内部管理后台的网站加密。**第一问定层——应用对服务端，TLS。第二问信任锚——公司已有内部 PKI，但对外网站直接走公有证书体系更省；选公有证书，透明日志提供了误签发的可审计性。第三问元数据——管理后台的访问图谱只在公司内可见，不敏感。第四问预算——标准方案零边际成本。结论顺带写出不覆盖项：端点安全、员工凭证钓鱼不在协议承诺内，靠双因素与设备管理补。整个论证十分钟，评审可以当场过。

**场景二：面向公众的私信产品，要求"服务端无法读内容"。**第一问——个人对个人内容，Signal 类结构。第二问——没有全球 PKI 可依赖，信任首用加安全编号比对，同时把"密钥变更告示"写进产品需求（这是 4.2 节的软肋清单）。第三问——元数据：私信产品的通信图谱就是业务数据，必须明确"服务器可见谁与谁在何时通信"这条边界并写进隐私声明。第四问——预算最高的一档：设备管理、多端同步、备份策略全套要自建。不覆盖项：本地备份若为明文，全盘承诺归零；客服审计需求与端到端承诺的冲突要提前设计（通常用客户端侧审批日志而非内容明文来解）。

**场景三：两家公司数据中心之间的流量互联。**第一问——站点对站点，IPSec。第二问——企业间无共同 PKI，预共享密钥或各自内部证书互换；密钥轮换频率写进互联协议。第三问——隧道模式天然遮蔽内部拓扑，正合需求。第四问——网关侧运维成本可接受，换来对上层应用完全透明。不覆盖项：端点应用的自身漏洞与隧道内的横向移动，信道不管，靠分段与监控。

三个场景走完会发现，决策树真正的价值不是"选谁"，而是逼每个场景把信任锚、元数据边界、不覆盖项说出口——这三件事说清楚了，选型汇报的骨架就齐了。

对比表之外补一句使用告诫：表是快照不是判决。四个协议都在演化——TLS 1.3 之后的版本还在收紧元数据暴露，Signal 的后量子改造在推进，Noise 模式库在扩充，IPSec 的套件基线在更新。拿着任何一张静态对比表用三年，本身就是一种部署事故。对比表的正确用法是把它当分析框架的备忘：维度（信任模型、前向保密粒度、元数据、成本）比行内结论更长寿，结论每年按最新版本刷新一遍，框架不动。这也呼应本节开头那句"先问地层再谈协议"——地层不常变，选型论证里的常量；具体协议的名次，是会随版本号变动的变量。

本节要点回顾

• 先定地层再谈协议：应用信道、个人消息、定制组件、网络管道各有其主协议，跨层比较"谁更安全"是错位问题。
• 信任模型决定一切：证书外包信任、用户行为锚定信任、实现者自选信任、预共享密钥——四种锚对应四种事故形态。
• 前向保密粒度不同：会话级够用于客户-服务器；消息级（双棘轮）服务异步个人通信；Noise 的粒度由所选模式决定。
• 元数据是独立维度：内容保密不等于通信图保密；对元数据敏感的场景要连部署拓扑一起设计。
• 汇报必写"不覆盖的威胁"：写清边界是选型可靠性的证明；分层组合按层验证，不用单一结论覆盖全局。

第 4 章的手推到这里收官。下一章把人工推演升格为机器推演：把协议写成形式模型，让验证工具几分钟能找到人眼十七年找不到的缝隙——包括 3.1 节那个著名的漏洞。