Empty TLS application records being injected in Tor streams
ben at links.org
Fri Dec 5 16:33:24 UTC 2008
Robert Hogan wrote:
> On Thursday 20 November 2008 19:54:34 Robert Hogan wrote:
>> On Wednesday 12 November 2008 02:25:51 Steven J. Murdoch wrote:
>>> Does anyone have ideas on how to remove the redundant TLS application
>>> records, or otherwise improve the efficiency?
>> has the answer.
>> "Sending empty SSL record (I mean record with only MAC) before SSL
>> record with real application data guards against some timing CBC attacks
>> and is enabled in OpenSSL by default.
>> To disable this set SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS with
>> This corresponds exactly with what you're seeing - the empty record
>> always precedes the populated application record.
> I looked at this a bit more out of curiosity. The attack the empty records
> defend against is a confirmation attack based on the fact that TLS in CBC
> mode uses the previous cipher block as the IV for encrypting the current
> plaintext. So if the previous cipher block is available to the attacker,
> by just sniffing packets, and they are able to guess the plaintext in both
> the previous and current blocks they can confirm their guess.
> Alternatively they can choose a plaintext, encrypt it with their guess for
> the key, ask for an encrypted version of it and confirm whether they have
> guessed the key correctly if the cipher text matches. (A random IV
> protects against this last one.)
> " The attack itself is very simple. Remember that in CBC mode, each
> plaintext block is XOR'ed with the last ciphertext block and then
> encrypted to produce the next ciphertext block. Suppose the attacker
> suspects that plaintext block P_i might be x, and wants to test whether
> that's the case, he would choose the next plaintext block P_j to be x
> XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j
> XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his
> guess by looking at whether C_j = C_i."
> The empty records prevent this attack because each full application record
> (containing encrypted plaintext the attacker might be interested in) is
> interleaved with an empty record (with an unpredictable MAC in it). Since
> the attacker needs to be able to guess two adjacent plaintexts in order to
> perform the attack (P_i and P_j), the empty record with the unpredictable
> MAC will always make this impossible.
> So from Tor's point of view the question is whether the CBC confirmation
> attack is practical given the data Tor exchanges in TLS application
> records. Does Tor transmit two guessable plaintexts in a row? VERSIONS and
> NETINFO cells seem to fall into this category. Other cells seem much
> harder to guess.
Steven asked me to do an analysis of this a while back, which I did,
then forgot to post. Here it is...
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the tor-dev