TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
A TLS 1.2 cipher suite for ECDSA certificates with ECDHE key exchange, AES-256-GCM encryption and SHA-384.
What it is
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (code 0xC02C) is a TLS 1.2 cipher suite from RFC 5289. It combines ephemeral elliptic curve Diffie-Hellman key exchange, an ECDSA server certificate, AES with a 256-bit key in Galois/Counter Mode, and SHA-384 as the PRF hash.
It is the 256-bit variant of TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and the ECDSA counterpart of TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All of them provide forward secrecy and authenticated encryption; the choice between them depends on the server certificate type and on whether a policy asks for 256-bit keys.
RFC 9325 lists it among the recommended TLS 1.2 suites. It is only used when TLS 1.2 is negotiated; with TLS 1.3 the key exchange and certificate type are chosen separately and the record protection comes from a TLS 1.3 suite such as TLS_AES_256_GCM_SHA384.
Servers that hold both an ECDSA and an RSA certificate can choose between this suite and its RSA counterpart, depending on which certificate they want to present to the client.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 12 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
All measured clients send it. OpenSSL-based clients such as Python requests, httpx, Guzzle and Debian curl put it 4th, directly after their three TLS 1.3 suites, because their default OpenSSL cipher order puts 256-bit suites first. Chrome, curl_cffi and curl-impersonate chrome116 send it 6th, Node.js fetch 7th and Go net/http 3rd.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 in the TLS details.
Run the TLS fingerprint test