Empty TLS application records being injected in Tor streams

[Ben Laurie]

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?
>>>
>>> Steven.
>> http://marc.info/?l=openssl-users&m=115654275717293&w=2
>>
>> 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
>> SSL_CTX_set_options()."
>>
>> 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...

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"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...
Name: on-tls-empty-record-insertion.txt
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20081205/f0a100e0/attachment.txt>