摘要

  • RFC 9662 保留旧 RSA/CBC 套件作为迁移共同面，同时要求实现并优先采用具备前向保密性的 ECDHE/GCM 套件；TLS 与 DTLS 的版本规则并不相同。
  • “已实现、已启用、已提供、应优先、已协商”是五种事实，任何一种都不能替代某条 syslog 事件的接收与留存证据。
  • 完整回执应把设备、策略修订、连接代次、证书判断、事件标识、发送结果、收集器接收、持久化写入和检索回读连接起来。

设备清单被分成两列。服务器和新交换机使用 TCP 上的 TLS；旧控制器与一批现场终端使用 UDP 上的 DTLS。升级报告给两列都盖上了“RFC 9662”标记。故障发生后，团队却无法回答最简单的问题：缺失的那条告警原本属于哪条连接，又在哪一步消失。

这不是标准写得不够长，而是把不同现实层误并成了一格。

RFC 9662 更新 RFC 5425 与 RFC 6012 的安全 syslog 密码选择。早期共同面围绕 TLS_RSA_WITH_AES_128_CBC_SHA 展开，无法提供前向保密；DTLS 映射还把已经过时的 DTLS 1.0 作为必须实现的协议。新文件既提高底线，也承认大量设备不能瞬时迁移。

这个折中很重要：如果在设备升级前直接移除唯一共有套件，密码指标可能变得更漂亮，日志却可能全部中断。但折中也要求管理者保存两本账——什么是目标状态，什么是为了连续性暂时保留的例外。

两条运输路径，不能共用一张模糊证明

TLS 路径继续以 TLS 1.2 为必须实现的基础。实现还应支持 TLS 1.3，并在支持时优先协商它。这说明共同能力和升级方向，不说明某次长连接实际用了哪个版本。

DTLS 路径的规则更直接：DTLS 1.0 不得使用，DTLS 1.2 必须使用；DTLS 1.3 应被支持，并在实现后优先选择。RFC 8996 与 RFC 9325 给出了淘汰旧版本和安全使用 TLS/DTLS 的更广背景。

因此，“版本 1.2”不是足够的审计字段。TLS 1.2 与 DTLS 1.2 的丢失、排序、重连和确认边界不同。DTLS 保护一个数据报，不会凭空创造应用层接收确认；TLS 保持一条连接，也不能证明源端队列没有溢出，或收集器没有拒绝某条记录。

连接记录必须写明传输、端点、连接代次、协商版本与套件。事件记录则需要自己的标识、生成时间、入队时间、发送尝试和收集结果。两组记录通过连接代次与事件标识相连，而不是靠“安全连接正常”这句话代替。

同时必须实现，不等于同时必须使用

RFC 9662 把 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 与旧的 TLS_RSA_WITH_AES_128_CBC_SHA 都放入必须实现的集合，以保存迁移期间的互操作共同面。实现是产品能力；启用是本地策略；提供是一次握手中的候选；优先级是候选之间的排序；协商才是这次连接的结果。

如果资产系统只保留“支持 ECDHE/GCM”，它可能掩盖三种现实：本地配置没有启用，对端没有共同能力，或顺序错误使旧套件持续胜出。相反，一台设备实现了旧套件，不代表管理者必须在所有接口启用它。

IANA TLS 参数登记表 能统一编号和状态语义，却观察不到任何设备的配置与握手。标准文本、登记状态、产品能力、本地配置和运行结果必须分开保存。

对于只能使用旧套件的设备，RFC 9662 把决定交给网络管理者：可以评估是否暂时允许，以保证日志在升级前继续送达。这个决定不能变成无期限的默认值。例外记录至少要列明设备类别、固件、指定收集器、允许的套件、业务理由、补偿控制、责任人、批准时间、到期日和升级测试。

还要记录例外是否真的被使用。一个从未协商旧套件的例外可能可以关闭；一个每小时都被选中的例外说明升级依赖仍然存在。静态配置截图无法给出这两种判断。

禁止 0-RTT 只关闭了一个重放入口

RFC 9662 明确禁止安全 syslog 使用 TLS 1.3 early data。原因不是性能无关紧要，而是 early data 的安全属性较弱，且 RFC 5424 的 syslog 协议 本身不提供重放保护。重复告警可能放大事件数量，也可能重复触发依赖日志的自动动作。

但“不使用 early data”不等于普通握手后的消息具有恰好一次语义。事件仍可能在加密前被重复生成，在不明确的失败后重发，在源队列压力下丢失，在 DTLS 路径中消失，被收集器拒绝，写入错误租户，因存储失败未落盘，或在索引阶段变得不可检索。

测试必须拆成两项。第一项证明客户端没有把 syslog 负载作为 early data 发送，收集器也不会按 early data 接收。第二项让带唯一标识的测试事件走普通握手后路径，并在预定索引与保留窗口中被回读。第一项通过，绝不能自动替第二项通过。

证书正确，也只走到连接边界

RFC 5280 提供证书与路径验证基础。安全 syslog 还需要把路径结果、参考身份和本地授权结合起来。一条数学上有效的证书链可能结束在不希望的信任锚，可能没有匹配预期服务身份，也可能认证了一个本地政策不应接收的对端。

即使身份判断完全正确，它证明的仍是一条通道，而不是其中的特定事件。最小事件回执应包含隐私安全的源标识、设备时钟与序列背景、事件生成与入队时间、连接代次、发送尝试、收集器接收编号、持久化写入结果、索引目的地、保留等级和回读结果。不能保留测试正文时，可以使用加盐标记连接各段记录。

故障分类也必须诚实：无共同套件、禁用版本、证书路径失败、参考身份错误、对端未授权、early data 被拒、连接中断、队列溢出、数据报丢失、收集器拒绝、存储失败、索引错位与回读缺失。把它们都写成“安全 syslog 失败”，就无法分配责任。

从最终查询向源端倒查

先问管理层真正需要的结果：授权调查者能否在承诺的保留窗口内检索到目标事件？从查询结果找到持久化对象和收集器接收记录，再找到传输发送、连接代次和源端队列记录；最后把连接还原到协商版本、套件、会话恢复、early-data 状态、证书判断和本地策略版本。

这条逆向链能阻止三种局部成功冒充全局成功。密码团队可以证明现代握手存在；收集团队可以证明进程健康；存储团队可以证明索引在线。只有共同的事件标识能够证明目标记录跨过了全部边界。

Heng Lu 的最小初始规范给出恰当比例：共同底线应当小、清晰、可检验，本地迁移选择则必须由可追责的证据约束。现实层提醒我们，标准地位、支持能力、配置政策、协商结果与留存证据不是同一层。运行代码优先则把最后判断放回实际协商、传输、接收与保存事件的系统。

RFC 9662 修好了安全 syslog 的密码共同面。组织还必须证明某次连接选了什么，以及某条日志最终去了哪里。

来源