encrypt_then_mac
encrypt_then_mac switches TLS 1.2 CBC suites to the safer encrypt-then-MAC order. OpenSSL-based clients send it, browsers do not.
What it is
encrypt_then_mac (extension 22) is defined in RFC 7366. In the original TLS design, CBC cipher suites compute the MAC over the plaintext and then encrypt both, an order that made padding oracle attacks such as Lucky Thirteen possible. With this extension, the record is encrypted first and the MAC is computed over the ciphertext, so tampered records are rejected before any decryption happens.
It only affects CBC suites in TLS 1.2 and earlier. AEAD suites such as AES-GCM and ChaCha20-Poly1305 already authenticate the ciphertext, and TLS 1.3 uses only AEAD suites, so the extension has no effect there.
RFC 9325 says CBC suites SHOULD NOT be used unless encrypt_then_mac is negotiated, which is why careful TLS 1.2 deployments still care about it.
Both sides must agree: the server echoes the extension when it accepts.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 6 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
In our measurements Python requests, httpx, Node.js fetch, Guzzle and Debian curl send it, all clients built on OpenSSL. Chrome, curl_cffi, curl-impersonate, macOS curl and Go net/http do not. Its presence is a reliable sign of an OpenSSL-based client rather than Chrome.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for encrypt_then_mac in the TLS details.
Run the TLS fingerprint test