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

Question

I'm wondering which changes from SSL 3.0 to TLS 1.0 exactly fixed the POODLE Attack. The Base for this Attack is the Messageblocks M1||MAC||PAD, so a whole Block is used for MAC and Padding.
I have the Idea, that it doesn't work anymore (without downgrading) cause in TLS 1.0 if the last Block is Padding it is 0x101010... (With block size of 16) and not 0xXX...XX10 (XX=Random), so it's a lot more Heavy to guess 16 Bytes directly instead of only the last Byte.
But are there any other security parameters that fixed this problem or did I mentioned it right? Like is the end of the Messages not ||MAC||PAD anymore? Or is the PAD maybe signed or something like that?
Regards
Julian

Answer 1

SSL 3.0 and TLS 1.0 differ in how they treat the padding.
See https://www.openssl.org/~bodo/ssl-poodle.pdf and this section:
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.
The messages in TLS1.0 are still structured the same, see this structure from RFC 2246:
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
The padding is defined as such:
Each uint8 in the padding data vector must be filled with the padding length value.
This is the crucial difference between SSL 3.0 and TLS 1.0 in that regard, which makes the receiver able to check that the padding is right, and not being in fact leftover from valid application data blocks.
(compare 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 for TLS 1.0)
This is also explained on https://www.imperialviolet.org/2014/10/14/poodle.html like that:
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.
And later:
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.