ssl application data zero bytes myth

Question

Recently I analyzed several SSL/TLS application packets, and I found that rather interesting that some packets start with fixed 7 zero bytes in the very beginning of SSL/TLS application data packet.

TLS 1.2 application data example 1

TLS 1.2 application data example 2

I don't know why this happen? Intuitively the encrypted message should by random bytes.

Answer 1

I think this is a peculiarity specific to Galois Counter Mode. What Wireshark calls the “Encrypted Application Data” is in this case a GenericAEADCipher, which is defined in RFC 5246, section 6.2.3.3 and begins with:

opaque nonce_explicit[SecurityParameters.record_iv_length];

RFC 5288, section 3 describes this field for GCM:

Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.

The nonce doesn’t need to be random, or unpredictable – but it absolutely must be unique (see also this answer). Using the TLS record sequence number (not the TCP sequence number!) is a good way to ensure uniqueness within one connection, and so NSS, for example, follows that recommendation (see lib/ssl/ssl3con.c, lines 2148-2167 and 2994-3016 in NSS 3.27.1).

So, at the start of a new TLS connection, that nonce will just be a bunch of zeroes. Note that in your second screenshot, the last byte is already 01 – presumably, that’s the second record in the connection.