On Friday 05 December 2008 16:33:24 Ben Laurie wrote: <..> > > Analysis > -------- > > For this attack to work, the attacker must be able to control a > plaintext block for which he knows the preceding ciphertext block, > C_(j-1). SSL and TLS open up this problem because the IV for each > packet is the previous packet's final ciphertext block[1]. > When you say 'packet' here I understand you to mean 'application record'. I hope that's correct.There can multiple records in a single TLS network packet. > Thus, if the attacker can choose plaintext for a TLS packet that > immediately follows a TLS packet he has observed, he can take a guess > at the plaintext of any packet he has seen in that ciphertext stream > and test whether the guess is correct. > My understanding is that the chosen plaintext and the plaintext that is being guessed at must be adjacent for this to work. And that is why the empty 'unpredictable content' records between real application records frustrate the attack. P_i and P_j can't be interrupted by an unknown plaintext. My reason for thinking this is that if I observe an empty TLS application record and 'know' the record following it contains a Tor VERSIONS command then the attack would still hold, unless the attack depended on being able to guess the plaintext of the empty application record as well. I suspect my understanding has fallen down somewhere here. > Not many applications exist that allow the attacker to do this. In > particular, if an attacker has an ability to inject plaintext into a > TLS connection that contains data unknown to him, then the connection > must contain data not supplied by him. > > Therefore any protocol running over TLS that contains data entirely > controlled by a single party is immune. Note, though, that this does > not include protocols like POP3 or IMAP, where the payloads are the > result of many different people sending emails. Nor does it include > Tor. It does, however, include static web pages. > Doesn't predictable content equate to control over content in this situation? The early parts of tor circuit construction are fairly predictable. So in the absence of empty application records an attacker could take a packet dump of a Tor conversation, attack the early part of the conversation with guesses at the VERSIONS and NETINFO sections and potentially come up with some hits. A lot of the discussion here and elsewhere deals with real-time inspection of the packets. I am missing why the as-it-happens factor is important, doesn't the attack apply to recorded sessions for analysis at leisure?
Attachment:
signature.asc
Description: This is a digitally signed message part.