3
$\begingroup$

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 :

wireshark capture of the traffic

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).

$\endgroup$
2
$\begingroup$

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"

$\endgroup$
  • $\begingroup$ "Actually, even if the 20 byte HMAC wasn't added, you always have to add at least one byte of padding" Is it an implementation rule ? Cause the RFC for TLSv1 states : "The padding length should be such that the total size of the GenericBlockCipher structure is a multiple of the cipher's block length. Legal values range from zero to 255, inclusive." $\endgroup$ – watts Feb 28 '17 at 16:48
  • 2
    $\begingroup$ @watts: It's a rule, not an implementation suggestion. Look again at the TLS RFC (section 6.2.3.2): the amount of padding added is always one more than the value of the padding length field (as the space occupied by the padding length field isn't included in that count). Hence, the total amount of padding added is between 1 and 256 bytes. $\endgroup$ – poncho Feb 28 '17 at 20:30
  • 1
    $\begingroup$ And in TLSv1.0 for CBC suites many implementations including Java/JSSE (since somewhere in the middle of j6, check the release notes) 'split' each application record except the first into two protocol-level app-data records (1/n-1) as a defense against BEAST, even for apps that may not need defending. And did the same for SSLv3, before that was killed by POODLE more recently. Conversely in 1.1 and 1.2 (only j7+) with CBC, the encrypted app-data content expands by another block for the per-message explicit IV. $\endgroup$ – dave_thompson_085 Mar 1 '17 at 11:03

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.