Skip to content

09-02: Exercises

Question

Break down the cipher suite name TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 into its four components, and state what each one does.

Solution

Per 09-03: Cipher Suites, a cipher suite name encodes four separate pieces:

TLS_ ECDHE _ RSA _WITH_ AES_256_GCM _ SHA384
     ^^^^^   ^^^          ^^^^^^^^^^^   ^^^^^^
     (1)     (2)             (3)          (4)

Component 1: ECDHE — Key Exchange

ECDHE = Elliptic Curve Diffie-Hellman Ephemeral. This is how the two sides agree on a shared secret for the session (see 07-05: Diffie-Hellman Key Exchange for the underlying Diffie-Hellman math).

  • "Ephemeral" means a fresh key pair is generated for every single session, rather than reusing the same long-term key. This provides forward secrecy: even if a private key is compromised later, past captured sessions can't be decrypted retroactively, because each session's actual secret was never derived from a long-term key alone.

Component 2: RSA — Authentication

This is how the server proves its identity — the server's certificate (see 07-08: Digital Certificates & PKI) contains an RSA public key, and the server signs part of the handshake with the matching RSA private key so the client can verify it's really talking to the certificate's rightful owner.

💡 Notice: RSA appears here for authentication only in this particular suite — the actual key exchange is handled separately by ECDHE. (Some older/legacy suites instead use RSA for the key exchange itself, which is exactly the weaker, non-forward-secret pattern flagged as deprecated in 09-06: TLS Best Practices & HTTPS.)

Component 3: AES_256_GCM — Bulk Cipher

This is how the actual session data is encrypted once the handshake is done — see 07-03: AES & Block Cipher Modes.

  • AES = the cipher algorithm.
  • 256 = the key size in bits (256-bit AES).
  • GCM = Galois/Counter Mode, an authenticated encryption mode — it provides both confidentiality (encryption) and integrity checking in one operation, which is why GCM-based suites are preferred over older modes like CBC (see 07-03: AES & Block Cipher Modes for why CBC needs more careful handling).

Component 4: SHA384 — Hash/MAC

Used within the handshake's integrity/PRF (pseudorandom function) machinery — for example, in generating the Finished message MACs (see 09-02: The TLS Handshake). Note: because GCM already provides its own built-in authentication for the bulk data, this hash is mainly used for handshake-level integrity rather than per-record authentication (that job now belongs to GCM).

Final Answer

Component Value Role
Key exchange ECDHE Establish a shared session secret, with forward secrecy
Authentication RSA Prove the server's identity via its certificate
Bulk cipher AES_256_GCM Encrypt session data with built-in integrity (authenticated encryption)
Hash SHA384 Used in handshake integrity/PRF operations

This is a strong, modern cipher suite: ephemeral key exchange (forward secrecy) + a 256-bit authenticated-encryption cipher — exactly the profile recommended in 09-06: TLS Best Practices & HTTPS.