ssl - 为什么 POODLE Attack 只在降级到 SSL 3.0 后才生效？

Question

我想知道从 SSL 3.0 到 TLS 1.0 的哪些更改完全修复了 POODLE 攻击。此攻击的基础是消息 block M1||MAC||PAD，因此整个 block 用于 MAC 和填充。

我有一个想法，它不再工作(没有降级)因为在 TLS 1.0 中如果最后一个 block 是填充它是 0x101010...( block 大小为 16)而不是 0xXX...XX10( XX=Random), 所以直接猜 16 Bytes 比只猜最后一个 Byte 重很多。

但是是否有任何其他安全参数可以解决此问题，或者我提到的是否正确？消息的结尾不再是 ||MAC||PAD 了吗？或者 PAD 是否有签名或类似的东西？

问候 朱利安

Answer 1

SSL 3.0 和 TLS 1.0 处理填充的方式不同。

参见 https://www.openssl.org/~bodo/ssl-poodle.pdf这部分:

The most severe problem of CBC encryption in SSL 3.0 is that its block cipher padding is not deterministic, and not covered by the MAC (Message Authentication Code): thus, the integrity of padding cannot be fully verified when decrypting. Padding by 1 to L bytes (where L is the block size in bytes) is used to obtain an integral number of blocks before performing blockwise CBC (cipher­block chaining) encryption. The weakness is the easiest to exploit if there’s an entire block of padding, which (before encryption) consists of L-1 arbitrary bytes followed by a single byte of value L-1.

TLS1.0 中的消息结构仍然相同，请参阅 RFC 2246 中的结构:

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

填充是这样定义的:

Each uint8 in the padding data vector must be filled with the padding length value.

这是 SSL 3.0 和 TLS 1.0 之间的关键区别，这使得接收方能够检查填充是否正确，而不是实际上是有效应用程序数据 block 的剩余部分。

(比较 SSL 3.0 的 https://www.rfc-editor.org/rfc/rfc6101#section-5.2.3.2 和 TLS 1.0 的 https://www.rfc-editor.org/rfc/rfc2246.html#section-6.2.3.2)

这在 https://www.imperialviolet.org/2014/10/14/poodle.html 上也有解释像那样:

Consider the following plaintext HTTP request, which I've broken into 8-byte blocks (as in 3DES), but the same idea works for 16-byte blocks (as in AES) just as well:

[GET / HT][TP/1.1\r\n][Cookie: ][abcdefgh][\r\n\r\nxxxx][MAC DATA][•••••••7]

The last block contains seven bytes of padding (represented as •) and the final byte is the length of the padding.

[..]

An attacker can't see the plaintext contents like we can in the diagram, above. They only see the CBC-encrypted ciphertext blocks. But what happens if the attacker duplicates the block containing the cookie data and overwrites the last block with it? When the receiver decrypts the last block it XORs in the contents of the previous ciphertext (which the attacker knows) and checks the authenticity of the data. Critically, since SSLv3 doesn't specify the contents of the padding (•) bytes, the receiver cannot check them. Thus the record will be accepted if, and only if, the last byte ends up as a seven.

之后:

The critical part of this attack is that SSLv3 doesn't specify the contents of padding bytes (the •s). TLS does and so this attack doesn't work because the attacker only has a 2^-64 or 2^-128 chance of a duplicated block being a valid padding block.