CBC模式加密、解密数据数据padding错误

[microrover]

tls_cbc_encrypt函数下面的语句：
padding_len = 16 - rem - 1;
for (i = 0; i <= padding_len; i++) {
padding[i] = (uint8_t)padding_len;
}

应该修改为：
padding_len = 16 - rem;
for (i = 0; i <padding_len; i++) {
padding[i] = (uint8_t)padding_len;
}

同理：
解密的地方对于padding的数据检测，少检测1个byte。

目前代码：可以client和server互通，没有问题，但是不知道有没有隐患。

[microrover]

🔍 代码隐患与修正分析

1. 加密（Encrypt）部分的隐患

在 TLS 1.0 - 1.2 的 CBC 模式中，填充规则如下：

• 需要填充的字节数量 = padding_len（范围 0 到 255）。
• 需要额外增加 1 个字节来记录 padding_len 本身的值（即 padding_length 字段）。
• 填充的所有 padding_len 个字节，其值都必须等于 padding_len。

当前错误代码的问题：

// 错误代码
padding_len = 16 - rem - 1;
for (i = 0; i <= padding_len; i++) {
    padding[i] = (uint8_t)padding_len;
}

• 逻辑错误：16 - rem - 1 实际上是在计算“除了 padding_length 字段外还需要填充多少字节”。假设 rem 为 0（数据刚好是16字节对齐），padding_len 会变成 15。
• 循环越界与错误赋值：for (i = 0; i <= padding_len; i++) 会循环 16 次。这意味着它把 padding_length 字段本身也当成了填充数据，并且把它的值也强行改成了 padding_len（15）。这完全破坏了 TLS 协议中“最后一个字节代表前面填充了多少个字节”的规则。

你的修改意见（正确）：

// 修正后的代码
padding_len = 16 - rem; // 计算需要填充的总字节数（包含padding_length字段）
for (i = 0; i < padding_len; i++) {
    padding[i] = (uint8_t)padding_len; // 前 padding_len 个字节填充 padding_len 的值
}
// 注意：padding[padding_len] 即最后一个字节，需要单独赋值为 padding_len

• 符合标准：这样计算出的 padding_len 才是真正需要追加的填充长度（例如刚好对齐时，需要追加 16 个字节的 0x10）。
• 赋值正确：循环 i < padding_len 确保了前面的填充数据被正确赋值，而最后一个字节（padding_length）也能被正确设置为填充长度。

2. 解密（Decrypt）部分的隐患

你提到“解密的地方对于 padding 的数据检测，少检测 1 个 byte”，这是完全正确的。

• TLS 填充规则：解密后，程序需要读取数据的最后一个字节，假设它的值为 N。然后程序必须向前检查 N 个字节，确认这 N 个字节的值是否也都等于 N。
• 当前代码隐患：如果解密代码少检测了 1 个 byte（即没有把最后一个代表长度的字节纳入校验，或者循环次数少了一次），就会导致填充校验不严谨。
• 严重后果（Padding Oracle 攻击）：解密端的填充校验必须极其严格。如果校验逻辑有偏差（比如少检查一个字节，或者对无效填充和 MAC 校验失败的报错响应时间不同），攻击者就可以利用这种微小的差异（即 Padding Oracle），在不知道密钥的情况下，通过不断篡改密文并观察服务器的响应，逐字节地反推出明文。著名的 POODLE 和 Lucky13 攻击就是利用了 TLS 填充校验中的细微缺陷。

---

📝 总结与建议

目前的代码能互通，很可能是因为通信双方都使用了同样错误的逻辑（即“负负得正”），或者测试的数据刚好掩盖了边界条件的错误。但在与标准库（如 OpenSSL、浏览器内置 TLS 栈）对接时，这段代码必然会导致握手失败或应用数据解密报错。

强烈建议立即按照你的思路进行修改：

1. 加密端：修正 padding_len 的计算公式，并确保最后一个字节正确记录了填充长度。
2. 解密端：严格遵循 TLS RFC 5246 标准，确保对填充字节的个数和值进行**完整、严格且恒定时间（Constant-time）**的检测，防止引入侧信道漏洞。

[wangtsiao]

参考资料：RFC 5246, TLS 1.2, Section 6.2.3.2 CBC Block Cipher

这个代码实现的是 TLS CBC padding，不是 PKCS#7 padding。

TLS 最后一个字节是 padding_length 字段。

参考RFC的结构定义

block-ciphered struct {
    opaque content[TLSCompressed.length];
    opaque MAC[SecurityParameters.mac_length];
    uint8 padding[GenericBlockCipher.padding_length];
    uint8 padding_length;
};

比如要要补齐 N 个字节，就写 N 个值是 N - 1 字节

所以下面这个没问题

padding_len = 16 - rem - 1;
for (i = 0; i <= padding_len; i++) {
    padding[i] = (uint8_t)padding_len;
}