2

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.

enter image description here

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]
2
  • I have to brush up on the exact details of TLS since its key material and handling are not trivial. But, informally, the hash is needed to sign the session parameters and MAC the packets (you don't want confidentiality alone, you also want integrity). This answers 1 and 2. 3 is not clear to me, if you strip TLS traffic you won't see any of its fields. Commented Oct 28, 2022 at 18:51
  • @MargaretBloom Where exactly we can see the Hash in the packet in wireshark? Commented Oct 28, 2022 at 19:37

1 Answer 1

4

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.

5
  • Mostly concur but (1) there is an option (rfc7366) for encrypt-then-mac of CBC suites in TLS1.2 but in practice things that implement it also implement 1.3 and that gets used (MtE can be decrypted by a timing attack, though not tampered; EtM does not allow tamper with only the MAC key, a case which wouldn't occur anyway) (2) TLS padding for CBC is not quite PKCS7: that has n bytes with value n, TLS has n bytes with value n-1 (3) HMAC is computed over seqnum, type, version, length, and body (4) write_IV's are not generated (or used) for CBC in TLS1.2 (or 1.1), see rfc5246 6.3 Commented Oct 29, 2022 at 4:44
  • Whoops thanks Dave. You're right about the padding (whyyyy do they do it differently? I guess it tolerates a hypothetical 256-byte blocksize but they could have wrapped around the value to 0) and I totally should have read closer and caught the length in there. Write IVs not being generated makes sense but both the question and example site mentioned them. EtM does permit tampering with the ciphertext (and usually thus the plaintext) if the attacker has the MAC key; were you thinking encrypt-and-mac? But as you say, that wouldn't happen without them also having the encryption key anyhow.
    – CBHacking
    Commented Oct 29, 2022 at 9:29
  • Padding: SSL3 padding was n-1 of unspecified and 1 of n-1; I guess TLS1.0 wanted to keep the last byte the same when it made the others rigid. In retrospect this may have been a mistake because 1.0 didn't require the receiver to check all the bytes and some implementations didn't, leaving them (along with SSL3) vulnerable to POODLE. (Even after 1.1 specified it some implementors apparently didn't check, but at least now it was clearly a bug.) Commented Oct 31, 2022 at 4:25
  • Tamper: in EtM attacker with MAC key only can change the ciphertext but not controllably, changing bits in one block causes garbage in the prior block -- EXCEPT the first block which while posting I temporarily forgot has no prior block, so I half-retract that. Commented Oct 31, 2022 at 4:28
  • Yeah, you can modify the IV to flip the corresponding bits in the first block precisely, or - at the cost of corrupting the entire block N - flip bits in N to precisely corrupt block N+1. Sometimes corrupting N is compatible with your goals though. Also that is specific to CBC mode; some other modes are much more vulnerable to ciphertext tampering (or are AEAD modes that self-verify and thus are immune without needing separate MACs, which I believe all of the TLS 1.3 cipher suites use).
    – CBHacking
    Commented Oct 31, 2022 at 5:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .