(This answer is an expansion on Poncho's "exception" to his/her argument that the attack does not work on SSL/TLS)
The XML attack can (and has been) used to attack SSL/TLS. It has a few conditions that make it more complicated than in the XML case and more restrictive in its applicability.
The conditions that need to be met are [CHVV03]:
- A block cipher with CBC and padding checks are used
- The adversary can intercept and modify encrypted packets
- The adversary can distinguish padding errors from other types of errors (or successful decryption)
- The portion of plaintext (secret) to be recovered is in a predictable place and often communicated to the server
It was not always the case that the first condition was default (often stream cipher RC4 was used by default), but now with AES, it is more often the case.
The third condition is more complicated in SSL/TLS than in XML for reasons pointed out in the other answers: SSL/TLS data has a MAC. The attack works by modifying the ciphertext and will overwhelmingly cause the MAC check to fail. As a result, by only observing that some error was generated will not be enough to distinguish a MAC check error from a padding error. Further, the error itself is transmitted over the secure channel so even if the error itself explicitly says if it is a MAC or padding error, the adversary cannot distinguish them (assuming they are the same length).
However not all is lost: Canvel et al. demonstrate that it is (or at least was) possible to use a timing attack. Checking the padding is quick, and the check does not need to touch every bit of the input. By contrast, checking the MAC does. As a result, the researchers were able to show with OpenSSL that the two errors can be distinguished by measuring the time it takes for the server to return an error when they are close to the server.
The fourth condition is a result of the fact that a MAC error causes the session to abort. In terms of the attack, it means if you ask the attack oracle if a certain byte of ciphertext encrypted under a certain key will decrypt to your guess and your guess is wrong, the oracle will generate a new key and your captured ciphertext is worthless. You have to wait for the sender to encrypt the same plaintext under the new key to continue.
Once again, this is not insurmountable. Canvel et al use the example of IMAP (email) over SSL/TLS, where every 5 minutes, your email client will send your email password over SSL/TLS to the server to authenticate and ask the server if there is any new mail (in fact, it does this independently for every folder that it is checking). Since the password is in a predictable place, the adversary can use the CBC-padding attack on it. Once he guesses wrong, he has to wait until the email client checks again to continue guessing.
It may be possible to use this attack in the BEAST setting where the adversary is able to prod the client into sending a cookie of SSL/TLS on demand.