What does each part of the cipher suite ECDHE-RSA-AES128-GCM-SHA256 do?
ECDHE agrees on the keys, RSA proves the server's identity, AES-128 in GCM mode encrypts and authenticates the data, and SHA-256 drives the key derivation.
| Part | Job | In this connection |
|---|---|---|
| ECDHE | Key exchange | Ephemeral elliptic-curve Diffie-Hellman: both sides send a temporary public value and compute the same secret. New values every handshake, so forward secrecy |
| RSA | Authentication | The server signs its ECDHE value with the RSA key from its certificate. This is the key openssl req generated |
| AES128 | Bulk encryption | Symmetric encryption of all records with a 128-bit session key. Fast, and hardware-accelerated on the ESP32 |
| GCM | Mode of operation | Galois/Counter Mode, an AEAD mode: it encrypts and adds an authentication tag, so any change to a record is detected |
| SHA256 | Hash for the PRF | Used to derive the session keys from the premaster secret and both randoms, and in the Finished check |
The split explains the design. Public-key operations (ECDHE, RSA) are slow, so they are used once per handshake, only to agree on keys and prove identity. Everything after that uses fast symmetric AES. The full IANA name is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256; OpenSSL and curl print the shorter form.
The suite is chosen by the server from the list in the ClientHello. In TLS 1.3 the names shrink to just the symmetric part (TLS_AES_128_GCM_SHA256), because key exchange and authentication are negotiated separately.
Go deeper:
ciphersuite.info — TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 — the breakdown of this exact suite.- Wikipedia — Cipher suite — the naming scheme and how negotiation works in TLS 1.2 and 1.3.
- Wikipedia — Galois/Counter Mode — how GCM combines counter-mode encryption with an authentication tag.