What kind of data is appended to the message encrypted in AES128-CBC?

Question

I'm currently using wireshark to analyse TLSv1 traffic. I generate the traffic to an Apache (OpenSSL) using the following java (jdk 6) code :

        URL url = new URL(strUrl);
        HttpURLConnection httpc = (HttpURLConnection) url.openConnection();
        httpc.setRequestMethod("POST");
        httpc.setDoOutput(true);
        httpc.setFixedLengthStreamingMode(32);
        OutputStream out = httpc.getOutputStream();

        String request = "A";
        byte[] bytesRequest = new byte[1];
        bytesRequest[0] = Character.toString((char)Integer.parseInt(partsRequest[0])).getBytes("UTF-8")[0];
        out.write(bytesRequest);
        out.flush();
        out.close();

The chosen algorithm in the handshake is AES128_CBC_SHA.

So if I understand things correctly, the POST request is encrypted and sent, then we use the last cipherblock of this request as an IV for the message "A" to be encrypted.

However, when sniffing the traffic with Wireshark I noticed that the size of the encrypted data is of 32 bytes even if Wireshark decrypt it only as 1 byte :

So my question is : what is the nature of the appended data, padding, or info about the length of the message, or both ?

Also, I encrypted both 16 and 32 bytes and I respectively end up with 48 and 64 encrypted bytes, even though padding is not necessary (I'm using messages of the block size).

Answer 1

So my question is : what is the nature of the appended data, padding, or info about the length of the message, or both ?

With this ciphersuite, the encrypted data consists of the plaintext data, and the HMAC of the plaintext (and header and sequence number); this HMAC is 20 bytes long.

Hence, if you encrypt 1 byte, then you'll end up encrypting 21 bytes; with CBC mode, this gets padded up to 32 bytes; exactly what you see. And, a 16 byte message becomes 36 bytes with the HMAC, hence 48 bytes after padding; and a 32 byte message becomes 52 bytes, which is 64 byes after padding.

One correction to a statement you made:

even though padding is not necessary (I'm using messages of the block size).

Actually, even if the 20 byte HMAC wasn't added, you always have to add at least one byte of padding; if the prepadded message was a multiple of 16 bytes long, that means that you'll need to add a full 16 bytes of padding. If you encrypt a 12 byte message (so it becomes 32 bytes after the HMAC), that becomes 48 bytes after padding; if padding was not added, then on decryption, there'd be no way to distinguish between "this decrypted message was precisely 32 bytes long", vs "this decrypted message was shorter than 32 bytes, and had padding added"