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.
Attachment:
signature.asc
Description: This is a digitally signed message part.