Varying TCP Packet Size Using TLS with AES128 in CBC Mode

[Michael Thelen]

Hello,

I am using TLS v1.2 within the TLS implementation of Bouncy Castle. For
data encryption I am using a cipher with AES128 in CBC mode. Now I wanted
to fit a TLS record within a TCP Frame, playing around with always the same
payload size of 1200 Bytes. These bytes however are randomly created.
Sending the data over and over again, I realized that there is quite a
variance in TCP payload size, even though my original payload is always the
same length.

Where does it come from? Is this due to the padding implementation, which
adds more then minimum necessary? And even changes this randomly?

Best regards,
Mike

[Eckenfels. Bernd]

Hello,

just a general comment on your premiss: the data segments given to the SSL OutputStream might not be as equal as you expect them. If you do not use a BufferedOutputStream (and no compression or filter) they might be 1:1 what your application is producing: In a "pump data with this buffer" loop this means it is generally up to the buffer size, but can be less if the method which reads data into the buffer produces partial buffers. On the other hand if you use the Java BufferedOutputStream it will internally try to use the buffer, however it does not do this at all costs. Writes which are larger than the buffer will bypass it, and writes at the end of a partially filled buffer will not be split into to, but the filled buffer and after that the write will be flushed.

What kind of test program did you use? If you feed fixed size byte arrays of 1000 bytes into the SSL implementation it should (and I have not tested it) produce (after the initial split) same size segments.

Gruss
Bernd

-----Ursprüngliche Nachricht-----
Von: Michael Thelen [mailto:michael.thelen-CNgZ/***@public.gmane.org]
Gesendet: Mittwoch, 17. September 2014 14:26
An: dev-crypto-***@public.gmane.org
Betreff: [dev-crypto] Varying TCP Packet Size Using TLS with AES128 in CBC Mode

Hello,

I am using TLS v1.2 within the TLS implementation of Bouncy Castle. For data encryption I am using a cipher with AES128 in CBC mode. Now I wanted to fit a TLS record within a TCP Frame, playing around with always the same payload size of 1200 Bytes. These bytes however are randomly created.
Sending the data over and over again, I realized that there is quite a variance in TCP payload size, even though my original payload is always the same length.

Where does it come from? Is this due to the padding implementation, which adds more then minimum necessary? And even changes this randomly?

Best regards,
Mike











SEEBURGER AG Vorstand/Seeburger Executive Board:
Sitz der Gesellschaft/Registered Office: Bernd Seeburger, Axel Haas, Michael Kleeberg
Edisonstr. 1
D-75015 Bretten Vorsitzender des Aufsichtsrats/Chairperson of the Seeburger Supervisory Board:
Tel.: 07252 / 96 - 0 Dr. Franz Scherer
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: info-***@public.gmane.org HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

[Michael Thelen]

Hi Bernd,

thanks for your information. I am still not sure if this plays a role in
this case. From your description I would expect TCP fragmentation. I do
not have that. With 1200 bytes I made the payload so small that
everything fits within the MSS. But the bytes needed within the MSS
vary. I tracked this with Wireshark. It is the TLS encrypted payload
which has a different size from time to time even though the input is
always 1200 bytes.

I am using the Paho MQTT Client to test and I do not have any kind of
this behavior without TLS. The MQTT client does take a byte array to
send. So I am already passing a fixed byte array. In my case of 1200 bytes.

I conclude, that because I have not TCP fragmentation and everything can
be decoded fine by the MQTT server after decryption, even though I have
a varying encrypted payload length, it must have to do something with
the encryption. Because obviously it is transparent to the MQTT server.
It handles the received message fine.

I will try a different cipher tomorrow with AES128 in GCM mode and see,
if it makes any difference.

Best regards,
Mike

Post by Michael Thelen
Hello,
just a general comment on your premiss: the data segments given to the SSL OutputStream might not be as equal as you expect them. If you do not use a BufferedOutputStream (and no compression or filter) they might be 1:1 what your application is producing: In a "pump data with this buffer" loop this means it is generally up to the buffer size, but can be less if the method which reads data into the buffer produces partial buffers. On the other hand if you use the Java BufferedOutputStream it will internally try to use the buffer, however it does not do this at all costs. Writes which are larger than the buffer will bypass it, and writes at the end of a partially filled buffer will not be split into to, but the filled buffer and after that the write will be flushed.
What kind of test program did you use? If you feed fixed size byte arrays of 1000 bytes into the SSL implementation it should (and I have not tested it) produce (after the initial split) same size segments.
Gruss
Bernd
-----Ursprüngliche Nachricht-----
Gesendet: Mittwoch, 17. September 2014 14:26
Betreff: [dev-crypto] Varying TCP Packet Size Using TLS with AES128 in CBC Mode
Hello,
I am using TLS v1.2 within the TLS implementation of Bouncy Castle. For data encryption I am using a cipher with AES128 in CBC mode. Now I wanted to fit a TLS record within a TCP Frame, playing around with always the same payload size of 1200 Bytes. These bytes however are randomly created.
Sending the data over and over again, I realized that there is quite a variance in TCP payload size, even though my original payload is always the same length.
Where does it come from? Is this due to the padding implementation, which adds more then minimum necessary? And even changes this randomly?
Best regards,
Mike

[Michael Thelen]

Hi all,

the following code snippet in TlsBlockCipher.java looks like the answer
to my question. Could somebody please confirm that?

if (!version.isDTLS() && !version.isSSL())
{
// Add a random number of extra blocks worth of padding
int maxExtraPadBlocks = (255 - padding_length) / blockSize;
int actualExtraPadBlocks = chooseExtraPadBlocks(
context.getSecureRandom(), maxExtraPadBlocks);
padding_length += actualExtraPadBlocks * blockSize;
}

Best regards,
Mike

Post by Michael Thelen
Hi Bernd,
thanks for your information. I am still not sure if this plays a role in
this case. From your description I would expect TCP fragmentation. I do
not have that. With 1200 bytes I made the payload so small that
everything fits within the MSS. But the bytes needed within the MSS
vary. I tracked this with Wireshark. It is the TLS encrypted payload
which has a different size from time to time even though the input is
always 1200 bytes.
I am using the Paho MQTT Client to test and I do not have any kind of
this behavior without TLS. The MQTT client does take a byte array to
send. So I am already passing a fixed byte array. In my case of 1200 bytes.
I conclude, that because I have not TCP fragmentation and everything can
be decoded fine by the MQTT server after decryption, even though I have
a varying encrypted payload length, it must have to do something with
the encryption. Because obviously it is transparent to the MQTT server.
It handles the received message fine.
I will try a different cipher tomorrow with AES128 in GCM mode and see,
if it makes any difference.
Best regards,
Mike

Post by Michael Thelen
Hello,
just a general comment on your premiss: the data segments given to the SSL OutputStream might not be as equal as you expect them. If you do not use a BufferedOutputStream (and no compression or filter) they might be 1:1 what your application is producing: In a "pump data with this buffer" loop this means it is generally up to the buffer size, but can be less if the method which reads data into the buffer produces partial buffers. On the other hand if you use the Java BufferedOutputStream it will internally try to use the buffer, however it does not do this at all costs. Writes which are larger than the buffer will bypass it, and writes at the end of a partially filled buffer will not be split into to, but the filled buffer and after that the write will be flushed.
What kind of test program did you use? If you feed fixed size byte arrays of 1000 bytes into the SSL implementation it should (and I have not tested it) produce (after the initial split) same size segments.
Gruss
Bernd
-----Ursprüngliche Nachricht-----
Gesendet: Mittwoch, 17. September 2014 14:26
Betreff: [dev-crypto] Varying TCP Packet Size Using TLS with AES128 in CBC Mode
Hello,
I am using TLS v1.2 within the TLS implementation of Bouncy Castle. For data encryption I am using a cipher with AES128 in CBC mode. Now I wanted to fit a TLS record within a TCP Frame, playing around with always the same payload size of 1200 Bytes. These bytes however are randomly created.
Sending the data over and over again, I realized that there is quite a variance in TCP payload size, even though my original payload is always the same length.
Where does it come from? Is this due to the padding implementation, which adds more then minimum necessary? And even changes this randomly?
Best regards,
Mike