Can you help me understand some details about the attack using SSL3 POODLE bytes?

Question

I have read some articles or books (e.g., “Bulletproof SSL and TLS”) about POODLE, but they still don't answer my questions – which are:

1. From https://www.openssl.org/~bodo/ssl-poodle.pdf,

   Usually, the server will reject this record, and the attacker will simply try again with a new request. 

   My question is:

   Because this paper doesn't mention the attacker how to try again, I guess the attacker need try to modify the last byte ($C_{n-1}[15]$, from 0x00 up to 0xFF) of $C_{n-1}$ to reveal the cookies’ first previously unknown byte. I want to make sure if my understanding is correct or not?

2. From Adam Langley's blog (https://www.imperialviolet.org/2014/10/14/poodle.html)

   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.

   My question is:

   How does Adam get the chance ($2^{-64}$ or $2^{-128}$) in TLS?

Answer 1

to try again, I guess the attacker need try to modify the last byte

No. Some other (symmetric) padding oracle attacks do that, but here the attacker can't tweak the prior block and try another decryption because the MAC error already caused the session to be terminated. Instead the attacker causes the client (browser) to make a new request with the same data, and thus the same target plaintext (the cookie byte), but a random new key and state (IV). Statistically 1/256 of the time the last bytes in the $C_{i-1}$ (edited) and $C_{n-1}$ ciphertext blocks will be a 'lucky' pair that combines with the target (last) byte in $P_i$ so that the tampered plaintext block $P'_n$ ends with the desired value, 15 or 7 depending on the cipher blocksize. I.e. depending on your point of view either 1 of 256 values in $C_{n-1}$ reverses $C_{i-1}$ or 1 of 256 values in $C_{i-1}$ reverses $C_{n-1}$; the math treats them identically. For a slightly longer explanation, see my answer here or Steve Peltz's here.

How does Adam get the chance ($2^{−64}$ or $2^{−128}$) in TLS?

Since TLS unlike SSLv3 checks all the padding octets, there is only one valid all-padding block out of all possible blocks the size of the blocksize of the cipher, which is either 128 bits for AES Camellia SEED or ARIA, or 64 bits for triple-DES or IDEA -- or original DES or the deliberately weakened 'export' DES-40 or RC2-40 if still used, although even implementations that still used SSLv3 protocol prior to POODLE should have disabled the single-DES and export ciphersuites.