Imagine you're going to send a compressed and encrypted message to a friend, and I (the attacker) can do two things:
1) Append a bit to the message before it is compressed and encrypted.
2) See the size of the final message.
So I start by appending the string "4179174b19e0cdc91bf4" to your plaintext message. I see the final encrypted message size is 500 bytes.
Then, I redo the experiment, but this time, I append the string "[email protected]" to the message. The final encrypted message size is now 480 bytes. The string I injected was the same size, but the compression worked better this time, and I can guess it's because the string I picked is redundant with something in your plaintext.
Mix in a bunch of complicated math and a bit of javascript, and you've got an exploit.
This threat isn't specific to Django: it's being billed as a TLS attack, but any encryption system that uses compression the same way is vulnerable.
1) Append a bit to the message before it is compressed and encrypted. 2) See the size of the final message.
So I start by appending the string "4179174b19e0cdc91bf4" to your plaintext message. I see the final encrypted message size is 500 bytes.
Then, I redo the experiment, but this time, I append the string "[email protected]" to the message. The final encrypted message size is now 480 bytes. The string I injected was the same size, but the compression worked better this time, and I can guess it's because the string I picked is redundant with something in your plaintext.
Mix in a bunch of complicated math and a bit of javascript, and you've got an exploit.
This threat isn't specific to Django: it's being billed as a TLS attack, but any encryption system that uses compression the same way is vulnerable.