Empty TLS application records being injected in Tor streams
robert at roberthogan.net
Tue Dec 2 18:55:04 UTC 2008
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.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the tor-dev