What's the use of HMAC or hashing in TLS or SSL inspection

Question

In the Server hello, I got the below Cipher suite

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

Now, I know that we are using DHE for the key exchange, we are using RSA for the authentication, and AES for the encryption, and I know the complete process how exactly the key exchange and complete handshake occur.

But what I want to know is the use of hashing in the entire process.

1. do we create a HASH of every packet which is exchanged between the client and server, and we attach the hash and then encrypt in the packet?

2. do we keep on sending the Hash of every packet even after the SSL handshake is completed?

3. why we are not able to see the HASH part in Wireshark because it is all encrypted? I am decrypting all my traffic in Wireshark but still not able to see any hash value in any packet.

Also whats the use of the below keys

client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]

client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

Answer 1

The hash (specifically, the MAC) is part of the TLS record (sort of like "packet" but not actually related to the underlying Ethernet packet) but sent encrypted within the payload. It is present in the "handshake finished" messages (sent once by each side at the end of the handshake) and every "data" message sent from either end. It is an HMAC (HMAC-SHA2-256 in this case) computed using a MAC-specific key (one of two actually; client and server each have a different key they use for generating the HMAC, though of course both know the other's key so they can verify the HMAC).

Because the MAC is within the encrypted part of the message, it's not visible until the message is decrypted, at which point it's verified but then generally discarded (no further use). To see it in Wireshark or a similar program, you'd need a view that shows you the raw decrypted version of the encrypted portion of each record (rather than showing you just the decrypted payload of the record, or the decrypted payload reconstructed into the higher-level protocol such as HTTP, or of course the still-encrypted payload+MAC).

I found this great site for breaking down the TLS packet structure: https://tls12.xargs.org/#client-application-data, and will refer to it throughout this answer as "the example". You can see that, from start to finish, a TLS 1.2 client message using this cipher suite looks like this:

• Header (5 bytes)
  • Record type (1 byte, indicating "client data")
  • TLS version (2 bytes, major and minor version, 1-indexed, includes SSL versions, so TLS 1.2 is 0x03, 0x03)
  • Record payload length (2 bytes, network byte order a.k.a. big-endian, does not include the header length but does include the IV)
• Encryption IV (16 bytes for AES, unique for every encryption)
• Encrypted payload (AES in CBC mode always produces a multiple of the block length which is 16; encrypted plaintext includes the MAC; example is 32 bytes long)

The plaintext of the message is as follows:

• The actual message payload (In the example, the ASCII string "ping", 4 bytes)
• The MAC (in the example, HMAC-SHA1, which is 20 bytes; with your cipher suite, HMAC-SHA2-256, which is 32 bytes)
• Padding using a modified version (every padding byte is reduced by one) of the padding defined in PKCS#7(https://en.wikipedia.org/wiki/PKCS_7) (brings the plaintext length to a multiple of the block size which for AES is 16 bytes; always at least one byte of padding to avoid ambiguity so will be 1-16 bytes inclusive; 8 bytes in the example).

The MAC is an HMAC (Hash-based Message Authentication Code) using the hash algorithm specified in the cipher suite (SHA1 in the example, SHA2-256 in your question) as the pseudo-random function, and computed from the following data:

• Key: determined from the exchanged pre-master secret; client and server use different keys to create the MAC (and the other's key to verify the MAC). The key is the same for all messages sent in a given direction within a particular session.
• Message (the following fields concatenated without spacing):
  • Sequence number (unsigned 64-bit integer, network byte order; uniquely identifies this record in this direction; counts from zero for all encrypted traffic including the handshake-finished messages, each direction has independent sequence numbers)
  • Record type (1 byte, as in header)
  • Protocol version (2 bytes, as in header)
  • Data length (2 bytes, network byte order)
  • Data (in the example, the 4-byte ASCII string "ping")

You can look up the details of the HMAC construction if you want, though any cryptography library should be capable of computing HMACs given a pseudorandom function (typically a member of the Secure Hash Algorithm a.k.a. SHA family), a key, and a message.

Because the MAC is computed on the plain-text payload and then encrypted with the payload, it can't be verified until the record is decrypted (MAC-then-encrypt). However, it is also totally impractical for an attacker to tamper with the message; they would need both the encryption key and the MAC key to modify the message and then update the MAC to match. Conversely, if the MAC were outside of the encrypted portion (sent in plain text), the attacker would only need the MAC key (if they happened to know the modified plaintext of the message already, and the sequence number, they could recompute the MAC. In practice this won't ever happen without also exposing the encryption key - at which point all security is lost - because the MAC key is generated and protected the same as the MAC key). However, it's also impossible to verify the integrity of the ciphertext, including the padding, prior to decryption. Pre-TLS (SSL) protocol versions allowed the server (or client) to report padding errors in a way visible over the network, which enabled padding oracle attacks where a man-in-the-middle attacker who could generate encrypted traffic (e.g. by making a victim's browser send lots of requests to the same server) could brute-force decrypt the encrypted message (including parts the attacker don't know, classically the HTTP cookies) in linear time (max 255 requests per byte).

It might seem odd that the sequence number is included in the MAC but not present elsewhere in the record. However, TLS is designed for use over a reliable network protocol - typically TCP - which has its own sequence numbers (totally unrelated to the TLS ones) used to ensure that packets arrive in order. Thus, the client and server can simply keep track of how many TLS records have made it from the network stack up to the application layer (where TLS is computed), and know that those records are in the order that they were intended. If the order has been tampered with, the sequence numbers failing to match expectations - and thus the MAC failing to verify for re-ordered records - allows the TLS protocol to reject modified traffic.

The client/server write IVs, as generated during key generation, are only for cipher suites that use an implicit nonce (one where instead of sending the nonce/IV over the network, it is computed using info known to both parties). AES-CBC in TLS does not use an implicit nonce, so you shouldn't expect a TLS implementation to generate them for this cipher suite. (See https://www.rfc-editor.org/rfc/rfc5246#section-6.3.) The IV used in the encryption and decryption is unique and unpredictable (but not secret) for every message. The client/server write MAC secrets are of course the keys used for HMACs created by the client or the server, respectively; those do need to be generated from the pre-master secret (the value that is actually exchanged/generated during key exchange) because they are constant for the session, and never sent in plain text.