Rsyslog客户端对接SCHANNEL服务端 扩展缓冲区含额外数据时无法解密

根因定位步骤 #

首先明确错误码含义：80090308对应Windows SCHANNEL的SEC_E_INVALID_TOKEN错误，本质是传入解密接口的TLS记录格式不符合预期，和密钥协商结果无关，90%以上的场景是TLS记录分片边界处理错误导致。

• 抓包确认TLS分片规则
  标准TLS 1.2的单条记录最大明文长度为16384字节，超过16K的明文会被GnuTLS拆分为多条独立的TLS记录。你可以用tcpdump/Wireshark抓包两端的TLS流量，确认超过16K的日志对应的TLS记录数量、每个记录的长度是否符合规范。
• 校验服务端SCHANNEL接收逻辑
  检查自研服务端的DecryptMessage调用流程是否符合SCHANNEL规范：
  • 不能直接将单次recv返回的TCP缓冲区数据传入解密接口，TCP流无边界，单次recv可能返回半条TLS记录、或者多条TLS记录的组合
  • 当DecryptMessage返回SEC_E_INCOMPLETE_MESSAGE时，必须将当前所有未解密的数据完整存入缓冲区，和后续新接收的数据拼接后再重新传入解密接口，不能拆分或丢弃部分数据
  • 必须先解析TLS记录头（前5字节），读取到当前记录的完整长度后，凑够完整的单条TLS记录再传入解密接口
• 验证两端TLS扩展兼容性
  检查Rsyslog的GnuTLS配置是否开启了TLS最大帧长度扩展（RFC 6066），如果服务端SCHANNEL未开启对应扩展的支持，GnuTLS发送的超16K分片会携带服务端不识别的扩展字段，直接触发SEC_E_INVALID_TOKEN错误。

修复方案 #

• 优先修复服务端SCHANNEL接收逻辑，遵循标准TLS流处理流程：

1. 持续接收数据直到缓冲区长度≥5字节，解析TLS记录头获取当前记录的总长度
2. 继续接收数据直到缓冲区长度≥当前记录总长度
3. 截取完整的单条TLS记录传入DecryptMessage解密
4. 将缓冲区剩余未处理的数据前移，重复上述流程处理下一条记录

• 对齐两端TLS分片配置：
  若不想修改服务端逻辑，可以在Rsyslog的GnuTLS配置中添加MaxRecordSize 16384参数，强制GnuTLS不生成超过16K的TLS记录，避免跨端分片兼容问题。
• 临时验证方案：可以先将Rsyslog单条日志最大长度截断为16K以内，确认错误不再出现后再做正式修复，避免影响现有业务。

内容的提问来源于stack exchange，提问作者Rakesh