Empty TLS application records being injected in Tor streams

[Robert Hogan]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20081202/a357fe07/attachment.pgp>