TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
A TLS 1.2 cipher suite with DHE key exchange, an RSA certificate and AES-256-GCM. OpenSSL clients still offer it early.
What it is
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (code 0x009F) is the 256-bit sibling of TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, also from RFC 5288. Key exchange is ephemeral finite-field Diffie-Hellman with an RSA certificate, the records are protected with AES-256 in GCM mode, and SHA-384 is the PRF hash.
The record layer is as strong as in the ECDHE suites. The weak spot is the key exchange: in TLS 1.2 the server chooses the Diffie-Hellman parameters, and servers configured with small 1024-bit groups or shared default groups were exposed to the Logjam attack. Finite-field Diffie-Hellman is also much slower than elliptic curve key exchange.
TLS 1.3 removed server-chosen Diffie-Hellman parameters: it allows only named groups, such as ffdhe2048, from the supported groups list.
Servers that want forward secrecy without the cost of finite-field Diffie-Hellman can simply prefer the ECDHE suites, which every client in our data offers alongside this one.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 7 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
None of the Chrome-like clients we measured offer any DHE suite. OpenSSL-based clients such as Python requests, httpx, Node.js fetch and Guzzle, and both curl builds, still do, so any TLS_DHE_ suite in a ClientHello is a strong sign that the client is not a current browser.
Debian curl and Guzzle offer this suite remarkably early, at position 6, ahead of most ECDHE suites. Node.js fetch sends it 13th, macOS curl 13th, and Python requests and httpx 14th.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 in the TLS details.
Run the TLS fingerprint test