0
$\begingroup$

I have quite a big problem, because of a software implementation of TLS I had to adapt I had to create something which is now biting me.

It all comes down to this: I need to know the length of the plaintext when I want to decrypt it and the length of the ciphertext when I want to encrypt it. For the 2nd one I've made a (not so nice) workaround.

I have a workaround for the first problem, simply using TLS to encrypt the plaintext and then add a few bytes for the plaintext length and send this over.

So my question is: how big is the security risk if an attacker can see the plaintext length if i would send it in the clear together with the TLS protocol packet?

(more details here)

$\endgroup$
  • $\begingroup$ Note that your changed protocol will not be compatible to TLS anymore. $\endgroup$ – Paŭlo Ebermann Jun 6 '15 at 10:17
1
$\begingroup$

Not so high, the size of the plaintext should be known in advance. For all the stream cipher based cipher suites, including the ones with the newer authenticated ciphers the size of the plaintext can be directly derived from the ciphertext.

CBC mode only hides the plaintext length in the bounds of the block size - if that. You can however possibly abuse this to create a covert channel. Furthermore, you would be working out of spec - your scheme would not be compatible with TLS. You would only save up to the block size in bytes in your implementation at most, so the returns would be very small.

You may be better off choosing a cipher suite that uses a stream cipher instead. In that case the plaintext and ciphertext have the same length. Currently however that means RC4 or GCM mode encryption in TLS 1.2. In case of GCM you may have to subtract the size of the tag from your calculations of course.

$\endgroup$
  • $\begingroup$ I am using TLS_PSK_WITH_AES_128_GCM_SHA256 so that's not a problem. I know, but what i've done now is probably out of TLS spec anyway. but from a security standpoint sending the size of the plain text is no problem? might not be need, but it does not introduce a vulnerability because with some encryption modes the ciphtext and plaintext will be the same size anyway. $\endgroup$ – Vincent Jun 4 '15 at 13:34
  • $\begingroup$ I don't get it. If you use GCM mode you can already determine the plaintext length, unless I am entirely mistaken about that. There is no padding and a tag size that should be known. So there should be no need to add bytes to the encrypted packets. $\endgroup$ – Maarten Bodewes Jun 4 '15 at 16:54
  • $\begingroup$ Yes but if we were to switch to an other encryption method which does not keep the same length for plain and cipher text. I would still like it to work. $\endgroup$ – Vincent Jun 8 '15 at 6:29
  • $\begingroup$ I don't see why you don't have enough information as the padding would only be one block, and your CBC cipher needs that room anyway to be able to decrypt it. But as I said, it won't break the security. If it would then the stream cipher based cipher suites would be broken as well. $\endgroup$ – Maarten Bodewes Jun 8 '15 at 6:56
0
$\begingroup$

There's no risk in sending the (authenticated) packet length unencrypted as it's already observable by packet-inspection.

As you use AES-GCM, which adds a constant overhead (128-bit?) to the message and the TLS-specification is quite strict for the meta-data and there's no length extension (as is the case with CBC mode) an attacker can easily determine the length of your plaintext by simply observing the paket and hence a repetition of this number is no risk. (If it's authenticated...)

I don't have the exact TLS-spec in mind, but IIRC you should be able to predict packet and plaintext size pre-encryption / pre-decryption.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.