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

Question

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

我有一个想法，它不再工作（没有降级）因为在 TLS 1.0 中如果最后一个块是填充它是 0x101010...（块大小为 16）而不是 0xXX... XX10（XX=Random），所以直接猜16Byte比只猜最后一个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 (cipherblock 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 之间的关键区别，这使得接收方能够检查填充是否正确，而不是实际上从有效的应用程序数据块。

（比较 TLS 1.0 的 https://www.rfc-editor.org/rfc/rfc6101#section-5.2.3.2 for SSL 3.0 with 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.

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

Why does POODLE Attack only affect after downgrading to SSL 3.0?

ssl

padding

poodle-attack