ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)

TLS key exchange is how a client and a server agree on a shared secret. They never send the secret over the wire. ECDHE is the flavour of Diffie-Hellman that modern TLS uses. ECDHE stands for Elliptic Curve Diffie-Hellman Ephemeral. RFC 8422 calls it Ephemeral Elliptic Curve Diffie-Hellman instead. ECDHE is key agreement over an elliptic curve. Each side generates a fresh ephemeral key pair for every handshake, and destroys it afterwards. The trailing E is the whole point of the name: the keys are fresh for every connection, so a server private key that leaks later cannot decrypt sessions recorded before the leak. This property is called forward secrecy. RFC 8422 ties the two together in one sentence: these key exchanges “provide forward secrecy if and only if fresh ephemeral keys are generated and used, and also destroyed after use” (section 2).

ECDHE is not the encryption. A symmetric AEAD cipher such as AES-GCM does that. ECDHE is not the authentication either. That comes from the certificate signature: RSA, ECDSA or EdDSA. ECDHE is not a curve. X25519, X448 and NIST P-256 are curves that ECDHE runs on. ECDHE is the step in between. It produces the shared secret from which every session key is derived. In practice, that makes it the single asymmetric operation on the hot path of an HTTPS connection.

How it works

Both sides have to end up holding the same secret. Anyone watching the wire must learn nothing useful. The arithmetic is the same in every TLS version:

1. Client and server agree on one named curve. In practice, that curve is X25519 or NIST P-256 (secp256r1). TLS 1.2 negotiates it with the Supported Elliptic Curves extension. RFC 8422 narrowed that extension’s registry to secp256r1, secp384r1, secp521r1, x25519 and x448 (RFC 8422 section 5.1.1). TLS 1.3 renamed the extension supported_groups. It lists the same five curves under the heading “Elliptic Curve Groups (ECDHE)” (RFC 8446 section 4.2.7).
2. Each side generates a fresh ephemeral key pair on that curve and sends only the public part.
3. Each side combines its own private scalar with the peer’s public point. For secp256r1, secp384r1 and secp521r1, the result is “the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string”. For X25519 and X448, the result is the output of the scalar multiplication function applied to the secret key and the peer’s public key. That output “is used raw, with no processing” (RFC 8446 section 7.4.2; RFC 7748 section 6.1 works the X25519 case through as an example).
4. That shared secret feeds the key schedule. The key schedule derives the symmetric traffic keys. The AEAD cipher then protects the application data. Both sides discard the ephemeral private keys.

What changes between TLS versions is when the ephemeral shares travel. That timing decides the handshake latency.

TLS 1.2 spends a round trip on the exchange. The server sends its ephemeral public key and the curve in the ServerKeyExchange message. The client answers with its own key in ClientKeyExchange (RFC 8422 section 2.1). The ServerKeyExchange parameters are signed with the private key of the server’s certificate. ECDHE_ECDSA signs with ECDSA or EdDSA; ECDHE_RSA signs with RSA (section 2.2). That signature is what stops an on-path attacker substituting an ephemeral key of his own.

TLS 1.3 makes the client guess instead. It puts one or more ephemeral shares in a key_share extension in its very first message (RFC 8446 section 4.2.8). So a full handshake finishes in one round trip. The cipher suite stops naming the exchange altogether. A suite such as TLS_AES_128_GCM_SHA256 names only the AEAD cipher and the hash, because “these cipher suites do not specify the key exchange algorithm” (NIST SP 800-52 Rev. 2 section 3.3.1). The curve is negotiated in the extensions instead. Ephemeral (EC)DHE is one of three key exchange modes there, alongside PSK-only and PSK with (EC)DHE (RFC 8446 section 2). Neither PSK mode carries a certificate. So every certificate-authenticated TLS 1.3 handshake is an (EC)DHE handshake. Forward secrecy is therefore a property of the version, not a configuration choice.

Why it matters for a CDN

A CDN edge terminates TLS for every HTTPS request it serves. The key exchange is therefore a per-connection asymmetric cost, paid at the platform’s full request rate. The property ECDHE delivers is the platform’s exposure if a key ever leaks. Both sides of that trade are ECDHE’s.

The cost side is bounded largely by key size. NIST SP 800-57 Part 1 Rev. 5 Table 2 puts a 256-bit elliptic curve key (ECC, f = 256-383) at the same 128-bit security strength as a 3072-bit RSA key (IFC, k = 3072). So an ECDHE public value is tens of bytes, where an equivalent finite-field or RSA value is hundreds. That is why edges default to elliptic curves rather than to finite-field DHE.

Then count how many TLS sessions one request actually touches. Cloudflare documents three connections in the life of a request that misses cache: visitor to Cloudflare, an internal Cloudflare hop, and Cloudflare to the origin. Each of those is an independent TLS session with its own key agreement. Configuring ECDHE on the client-facing listener therefore settles only the first leg. The edge-to-origin leg is negotiated separately, against whatever the origin offers.

Forward secrecy is why the ephemeral form earns that cost here. A shared edge fronts many origins. A passively recorded stream of ciphertext is exactly what a harvest-now-decrypt-later attacker keeps, until it becomes readable. Every one of those connections used a key pair that no longer exists anywhere. So a later theft of the long-term private key does not unlock any of the recording. Keyless SSL attacks the same risk from the other end. It keeps the certificate’s private key off the edge entirely. ECDHE limits what a leak of that key would be worth in the first place.

What CDNs do

• Cloudflare. X25519 is an elliptic curve Diffie-Hellman protocol. Cloudflare’s post-quantum documentation states that, with TLS 1.3, X25519 “is the most commonly used algorithm in key agreement”. It also states that “as of October 2022, all websites and APIs served through Cloudflare over TLS 1.3 support post-quantum hybrid key agreement”, with X25519MLKEM768 as the recommended hybrid. Read support literally. The same page adds that “the connection is only post-quantum secured if the client also supports PQC”. These hybrids work only in protocols based on TLS 1.3, including HTTP/3 over QUIC (Cloudflare post-quantum cryptography).
• Fastly. “TLS 1.3 is now the default TLS version” (enabling TLS 1.3 through Fastly). Its documented TLS 1.3 key exchanges are X25519 and X25519MLKEM768. Clients that cannot speak 1.3 are not refused: “if a request comes from an older client, Fastly’s default behavior is to downgrade to TLS 1.2”. Every TLS 1.2 cipher suite Fastly lists is an ECDHE_RSA or ECDHE_ECDSA suite (Fastly TLS prerequisites and limitations).
• Akamai. Akamai has used a default profile for new certificates since 16 September 2020: ak-akamai-2020q1. This profile “supports TLSv1.2 and TLSv1.3 only” and offers ECDHE-ECDSA and ECDHE-RSA suites on the 1.2 side. Akamai states that “in TLS 1.3, the key exchange algorithm is not specified in the cipher suite”. Akamai also states that it “supports all standard key exchange algorithms”. It further states that “PQC client to edge is enabled by default for Enhanced TLS” (Akamai cipher profiles).

Watch out for

• The trailing E is the difference, but the names mislead in both directions. RFC 8422 removed the genuinely static key exchange algorithms ECDH_RSA and ECDH_ECDSA. It also deprecated their cipher suites (RFC 8422 Appendix B). So a static ECDH suite is not something to be configuring today. In the other direction, ECDH_anon is ephemeral in spite of the missing E. Despite the name beginning with ECDH_ (no E), the key used in ECDH_anon “is ephemeral just like the key in ECDHE_RSA and ECDHE_ECDSA”. Its real defect is that its parameters “MUST NOT be signed”, leaving the handshake unauthenticated (RFC 8422 section 2.3). NIST’s ordering rule remains the safe default: “prefer ephemeral keys over static keys (i.e., prefer DHE over DH, and prefer ECDHE over ECDH)” (SP 800-52 Rev. 2 section 3.3.1).
• An ECDHE_RSA suite does not mean RSA does the key exchange. In a TLS 1.2 suite name, the second token names the authentication only: “TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA uses ephemeral ECDH key establishment with parameters signed using RSA” (SP 800-52 Rev. 2 section 3.3.1). Reading the RSA as key transport is how people wrongly conclude that such a session is not forward secret.
• 0-RTT and PSK-only give up forward secrecy. A TLS 1.3 pre-shared key used on its own, the psk_ke mode, carries no fresh share. PSKs “can be used alone, at the cost of losing forward secrecy for the application data” (RFC 8446 section 2.2). Early data is weaker still but stated precisely: “the 0-RTT encryption keys do not provide full forward secrecy” (RFC 8446 appendix E.1.3). Those keys come from the PSK before any new (EC)DHE share is mixed in. So early data buys a round trip, but at the cost of that security property. The rest of a psk_dhe_ke handshake regains it.
• A wrong key_share guess costs a round trip. A TLS 1.3 client offers shares for the groups it guesses the server will accept. If it guesses wrong, “the server corrects the mismatch with a HelloRetryRequest and the client needs to restart the handshake” with a key_share the server will accept (RFC 8446 section 2.1). That adds a full round trip to connection setup. An edge that drops the curve mainstream clients guess first pays that penalty on every new connection. That is a latency regression that never shows up as an error.
• P-256 is the mandatory floor; X25519 is only a SHOULD. “In the absence of an application profile standard specifying otherwise”, a TLS-compliant application “MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519” (RFC 8446 section 9.1). The qualifier matters when a profile such as a compliance regime narrows the list. But the practical reading is unchanged: do not drop P-256 in pursuit of X25519.
• Curve choice is not purely a performance question. X25519 is designed for fast, constant-time implementation. Its security level “is slightly under the standard 128-bit level”. RFC 7748 immediately adds that “this is acceptable because the standard security levels are primarily driven by much simpler, symmetric primitives” (RFC 7748 section 7). So this is a footnote, not a reason to avoid X25519. The real limit is elsewhere: every named curve here rests on the discrete logarithm problem. X25519’s “security can be broken by quantum computers using Shor’s algorithm” (Cloudflare). SP 800-57 warns that its strength estimates “will be significantly affected when quantum computing becomes a practical consideration”. That is what the hybrid key agreements above are for.

Best practice

1. Run TLS 1.3 wherever the clients allow it. Every certificate-authenticated handshake there is an ephemeral (EC)DHE one, and “static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy” (RFC 8446 section 1.2). So the property is structural rather than configured.
2. Where TLS 1.2 must stay, offer ECDHE suites only. RSA key transport (the TLS_RSA_* suites) gives no forward secrecy. NIST “is deprecating the use of RSA key transport as used in TLS” (SP 800-52 Rev. 2 section 3.3.1). TLS 1.3 does not support RSA key transport at all.
3. Offer X25519 first and keep secp256r1 enabled behind it. X25519 is what mainstream clients put in their first key_share. That choice avoids the HelloRetryRequest round trip, and secp256r1 is the interoperable floor that RFC 8446 section 9.1 requires, absent a profile saying otherwise.
4. Generate the ephemeral pair per handshake and destroy it after use. That if and only if in RFC 8422 section 2 is the whole guarantee. A long-lived “ephemeral” key cached across connections silently removes forward secrecy, while the cipher suite name still says ECDHE.
5. Use session resumption to skip the exchange for repeat visitors. But resume in psk_dhe_ke mode, so a fresh (EC)DHE share still goes into the resumed handshake (RFC 8446 section 2.2). Treat 0-RTT early data as a separate decision with its own weaker guarantee.
6. Configure the origin leg too, not just the client leg. Track the post-quantum transition, so the edge negotiates a hybrid such as X25519MLKEM768 rather than X25519 alone. Cloudflare supports the hybrid on every TLS 1.3 site it serves. Akamai enables PQC client-to-edge by default on Enhanced TLS. But the negotiation still needs a client that offers the hybrid.