Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
A "practical attack against XML's cipher block chaining (CBC) mode" has been demonstrated: XML Encryption Flaw Leaves Web Services Vulnerable.
Does this weakness of CBC-mode which is used here also affect SSL/TLS?
Related: Is the CBC weakness in XML Encryption a new discovery? Are other applications vulnerable?
No; the problem with XML is that it doesn't include a Message Authentication Code (MAC), or anything else to validate the ciphertext; the only validation that XML does is checking if the CBC padding is sane. The attack uses that as an Oracle to decrypt data; the attacker generates an encrypted region with the last two blocks being carefully chosen; if the last block decrypts to a sane padding, that gives him information on what the last block decrypted to). SSL/TLS always includes a MAC along with the encrypted data; hence if the attacker generates his own encrypted data, the MAC will fail (because he can't generate that), and so the attacker will get no details on what the decrypted data looked like.
Now, there is one exception to that; when Vaudenay first discovered this attack (Password interception in a SSL/TLS channel), he realized that (because of the order of operations that TLS uses, it decrypts first and then checks the MAC) if the attacker could distinguish between a padding failure and a MAC failure, he could still use this attack. Now, in this case, actually trying this attack always causes the TLS connection to drop on the first attempt (and hence it's useful only if you can get the system to set up repeated sessions with the same plaintext); nevertheless, nowadays I would hope that all SSL/TLS implementations try to be careful to not leak that to an attacker.
Only if you are using TLS in ways it is not meant to be used.
For this attack to work, you need an validation oracle, which decrypts a piece of ciphertext using the key and tells you if it is valid (for some known value of "valid"). This is easy to do with a SOAP web service receiving XML-Enc-encrypted data, but not so much with TLS (and SSL, I think).
Firstly, most TLS cipher suites include authentication (i.e. a MAC), and messages with incorrect MAC will not passed on to the application (whether or not the decrypted message would be valid for the application).
Secondly, if a message arrives with incorrect MAC, not only this message is rejected, but the whole TLS connection (and its underlying TCP connection) is torn down. And the next connection then would usually have a new session key (if you don't use a pre-shared-key cipher suite without any session keys).
(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]:
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.
