How does TLS use hashing from the negotiated cipher suite

Question

I am trying to understand why TLS only uses hashing algorithm like SHA-384 instead of using an HMAC instance like HMAC-SHA-384.

If I understand correctly, this cipher suite (ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) means:

1. It uses Elliptic Curve Diffie-Hellman Ephemeral for Key Exchange in an insecure channel (internet).
2. It uses Elliptic Curve Digital Signature Algorithm for Authentication to ensure you are connecting to the intended party.
3. It uses (AES 128 GCM) for encryption to provide confidentially over an insecure channel.
4. It uses (SHA256) for hashing to ensure data integrity.

With that, here come my questions:

1. How does the hash get used? Are we first hashing the data and then encrypting it?
2. If we are simply appending the hash key into the data H(key||data), why don't we use HMAC as it is more robust?
3. Follow-up question, why do we need to sign our data if both parties have secured their encryption key, hashing key (My assumption here is if encryption and hashing are done correctly, only the intended party can decrypt and verify the data, so why bother signing the data)?

Answer 1

There are a couple places we use a hash in TLS. The first is as part of the signature. This is decided by means outside the cipher suite (usually the negotiation of the curve we're using for ECDSA) and can verify from what the cipher suite specifies. For example, you typically use SHA-256 with P256 and SHA-384 with P384.

The second place is in HMAC used as part of the TLS PRF (for TLS 1.2, from which the cipher suite you're using comes) or HKDF (for TLS 1.3). This is what the “SHA256” specifies. We derive keys using this PRF from the shared secret, including the encryption keys, any MAC keys, and other secrets (such as channel binding secrets).

The third place, for TLS 1.2, is in HMAC for data integrity if we're not using an AEAD, which provides data integrity. AES-GCM is an AEAD, so we don't use it here, but if we were using CBC, then we'd use HMAC-SHA-256 in this case. TLS 1.3 only allows AEADs, so this doesn't apply there.

We don't specifically sign the data sent over the channel. Instead, the server (and optionally, the client) signs either their part of the key exchange or data derived from the handshake, including the key exchange. That proves that their portion of the key exchange is authentic, and this is verified by the Finished message at the end. Once that's done, the data sent over the pipe is verified by the use of the MAC or AEAD.