TLS_AES_128_GCM_SHA256
The default TLS 1.3 cipher suite: AES-128 in GCM mode for encryption and SHA-256 for key derivation, offered by every modern client.
What it is
TLS_AES_128_GCM_SHA256 (code 0x1301) is one of the five cipher suites defined by TLS 1.3 in RFC 8446, and the only one every TLS 1.3 implementation must support. It encrypts records with AES using a 128-bit key in Galois/Counter Mode (GCM), an authenticated encryption mode that protects both confidentiality and integrity in one pass.
Unlike TLS 1.2 suites, a TLS 1.3 suite name says nothing about key exchange or certificates. Those are negotiated separately through the supported_groups, key_share and signature_algorithms extensions. The SHA-256 part only names the hash used by HKDF to derive the session keys.
AES-128-GCM is fast on any processor with AES hardware instructions, which covers nearly all desktop and server CPUs and most modern phones. It is considered secure, and there is no practical reason to prefer AES-256 for typical web traffic.
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
Every TLS 1.3 client offers this suite, so its presence says little on its own. What separates clients is the order: Chrome, curl_cffi and curl-impersonate chrome116 put the three TLS 1.3 suites first in the order AES-128, AES-256, ChaCha20, the Firefox profile of curl-impersonate puts ChaCha20 second, and OpenSSL-based libraries such as Python requests, httpx, Node.js fetch and Guzzle lead with AES-256. Go net/http lists its TLS 1.2 suites first and the TLS 1.3 ones at the end. JA3 keeps that order, while JA4 sorts the suites before hashing, so the order shows up in JA3 but not in the JA4 cipher hash.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for TLS_AES_128_GCM_SHA256 in the TLS details.
Run the TLS fingerprint test