Attacker is both inside (hostile Javascript) and outside (has control of the WiFi hotspot). Attacker wants to get the victim's cookie on some other site.
2
Hostile Javascript issues a GET HTTPS request to the bank site; the request contains the cookie. Encryption is CBC, let's say with 3DES. In the stream, attacker arranges for the last byte of the cookie to be the first of an 8-byte block.
The attacker knows the bytes immediately after the cookie (start of the next HTTP header).
So attacker sees y = E((X || c) xor d) where X is the last byte of the cookie, c is the next (known) 7 bytes, and d is the previous encrypted block (also known).
Attacker then instructs his Javascript to issue a request including the bytes A || c such that A is his guess of the unknown byte, and that sequence happens as first block of a record.
Attacker also arranges for the previous record to have length such that the padding for the previous record has length 8 bytes.
The attacker intercepts and alters the two records (the one that contains 'A || c' and the previous one).
He replaces the last block of the first record with d, and the first block of the second record with y.
Replacement in the first record has probability 1/256 of being accepted by the server, because of the SSL 3.0 padding (it depends on whether decryption yields a final byte of value 7, the other bytes being ignored).
The attacker can see that by just setting a small delay between sending of the two records, just to see if the server complains or not.
If the server does not complain, then it will accept the subsequent record, or not, depending on whether A = X or not.
Thus, with an average of 128*256 calls, the attacker guesses the last byte of the cookie.
He then iterates with the previous one, and so on.
There are details to adjust in the description above (data after A || c must match the modification of the first encrypted block of the second record) but it seems that it works on the paper.
The root cause: SSL 3.0 CBC padding allows for a lot of modifications that will be ignored upon decryption, which gives leverage to play IV-based games.
In TLS 1.0 all the padding bytes are fixed and the implementations must check them, so this attack does not work.
RFC 7366 (encrypt-then-MAC) would actually help a lot against these attacks. But it is not defined for SSL 3.0.
That's it. We'll see tomorrow how things turn out.
Given the various lengths of RSA key pairs (1024, 2048, 4096) what are the odds of two users having generated the exact same private key?
Canonical question regarding the recently disclosed padding oracle vulnerability in SSL v3. Other identical or significantly similar questions should be closed as a duplicate of this one.
What is the Poodle vulnerability?
I use [product]. Am I affected?
Is [product] vulnerable to the Poodl...
