Really great explanation, as I asked there I don't see how it can be used if we don't know how long the padding is.
One idea would be to try to change the ciphertext so it would produce a entire padding block (and then it would be easy to test if it is indeed an entire block of padding just be tampering it without modifying the last byte and it would still be accepted).
One of the requirements for the attack is partial plaintext control. This is feasible if you're running malicious JavaScript in the user's browser.
So what you do is generate an HTTP request that, taken together with the SSL MAC, will align on a block boundary. Then you're guaranteed to have one full block of padding.
It might sound difficult to pull this off with multiple unknowns (other cookies, user agent string, etc.), but in practice it would be easy. You could make sure things line up correctly just by incrementing your packet length by one byte at a time until you see the record size jump by a block.
Comments
Really great explanation, as I asked there I don't see how it can be used if we don't know how long the padding is.
One idea would be to try to change the ciphertext so it would produce a entire padding block (and then it would be easy to test if it is indeed an entire block of padding just be tampering it without modifying the last byte and it would still be accepted).
I guess someone here could answer my question?
One of the requirements for the attack is partial plaintext control. This is feasible if you're running malicious JavaScript in the user's browser.
So what you do is generate an HTTP request that, taken together with the SSL MAC, will align on a block boundary. Then you're guaranteed to have one full block of padding.
It might sound difficult to pull this off with multiple unknowns (other cookies, user agent string, etc.), but in practice it would be easy. You could make sure things line up correctly just by incrementing your packet length by one byte at a time until you see the record size jump by a block.