# SSLV3.0 Poodle Man-in-the-Middle scenario

I have gone through the answers in this thread SSL3 "POODLE" Vulnerability.

In the first answer,the following has been mentioned.

""The last ciphertext block thus gets decrypted, which yields a value ending with c7 XOR e7. That value is then XORed with the previous encrypted block. If the result ends with a byte of value 7 (that works with probability 1/256)""

Could you explain how could the last byte turns out as '7' with a probability of 1/256

I understand that the 256 is the number of combinations of the last byte possible.

I am just not able to figure out what all ways can the client request be modified such a way that 1 in 256 times the result is 7 and the server will accept the request?

Updated to better explain what's going on after referencing the original paper.

Since it's block encryption and the attacker is tricking the user into sending requests, the attacker can force the requests to 1) have a full block of padding and 2) have a block where a specific byte of the secret cookie is at the end. Since the block cipher decryption is the same per block across a single stream, the attacker takes the whole block of padding and replaces it with the whole block ending with the specific cookie byte then sends it off to the server. If it gets accepted, the attacker knows that the last byte of the cookie block decrypted to `00000111`, which (through some math on the encrypted values) allows the attacker to calculate the unencrypted byte of the cookie. If it doesn't work (which it won't 255 times out of 256), then the attacker needs to force the user to submit an entirely new request (which means an entirely different round of encryption, so it'll have completely different encrypted values even if it's the same unencrypted data). Only after it's accepted will the attacker change values, and what he/she will change will only be the part of the cookie that's in the last byte of the block he/she is swapping.

Old post:

Since there are 28 = 256 different values a byte can be, and since the attacker can't predict what the output will be, he/she must guess until that last byte has the one value that is valid, namely a value of 7.

By the nature of the XOR operation, if one input is static then there is exactly one value for the other input that will produce a desired output. So if the c7 is `01010101`, only an e7 of `01010010` will result in `00000111`. The attacker can't know c7, but he or she can change e7 (since that's just the value of the byte in the request) until the server doesn't return an error.

• That part is understood..what all ways can the client request be modified such a way that 1 in 256 times the result is 7 and the server will accept the request? – naren1 Apr 9 '15 at 17:15
• The attacker just changes the target byte to be each of the possible 256 values. All the XORing that happens on the target byte will be the same if the other bytes are the same, and when that XORing (on the server) outputs `00000111` then the server registers the padding as valid and doesn't send an error back to the attacker. – Aron Foster Apr 9 '15 at 17:32
• So,you mean to say the attacker will be tampering about 8+1 bytes of data that will be sent?..8 bytes of the last block + e7.Wouldn't the SERVER reject this message because the MAC failed?..Thanks a lot for responding.. – naren1 Apr 9 '15 at 21:20
• Okay, I was initially a little wrong. I've updated my post to accurately reflect what's happening, and now I have a good handle on the POODLE attack. Let me know if you have more questions! – Aron Foster Apr 9 '15 at 23:43
• Thank you for taking your time to answer.Is it because of the Initialization Vector we can sure that out of every 256 requests 1 of the requests will be a hit? I am wondering if you would know how often an entirely different set of encryption keys will be exchanged between the browser and the server? Will the server force the browser to use a new set of encryption keys after it has failed to get the accurate reading on the encrypted padding block? – naren1 Apr 13 '15 at 16:14