ChaCha20-Poly1305: Browser Support, Cipher Suites

What is ChaCha20-Poly1305?

ChaCha20-Poly1305 is an AEAD cipher the IETF standardized in RFC 8439. It encrypts data with the ChaCha20 stream cipher under a 256-bit key and a 96-bit nonce, then authenticates the ciphertext with a Poly1305 tag. Browsers, OpenSSH, WireGuard, and IPsec all use it.

Which browsers does ChaCha20-Poly1305 support?

Every modern browser supports ChaCha20-Poly1305 as a TLS 1.2 and TLS 1.3 cipher suite. Internet Explorer and Opera Mini are the only major exceptions, and the global usage figure on caniuse sits above 96%.

What cipher suites use ChaCha20-Poly1305?

ChaCha20-Poly1305 appears in one TLS 1.3 suite and three TLS 1.2 suites. The TLS 1.3 suite drops the key-exchange and signature names, since TLS 1.3 negotiates those in separate extensions. The TLS 1.2 suites keep the full ECDHE-and-signature naming.

• TLS_CHACHA20_POLY1305_SHA256: The TLS 1.3 cipher suite, defined in RFC 8446, code point 0x13,0x03. Every TLS 1.3 implementation is required to support at least one of TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, or this suite.
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: The TLS 1.2 suite for RSA-signed certificates, defined in RFC 7905, code point 0xCC,0xA8. This is the most common ChaCha20 suite negotiated against TLS 1.2 web servers.
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: The TLS 1.2 suite for ECDSA-signed certificates, code point 0xCC,0xA9. Cloudflare, Google, and Let's Encrypt with ECDSA leaf certificates negotiate this suite.
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: The TLS 1.2 finite-field DHE variant, code point 0xCC,0xAA. It is rare in practice, since modern servers prefer ECDHE.

The snippet below uses OpenSSL to force a connection through the TLS 1.3 ChaCha20 suite, then through one of the TLS 1.2 suites. Run it against a server that supports the cipher and the s_client output names the negotiated suite on the New, TLSv1.x line.

# Connect with OpenSSL and force the ChaCha20-Poly1305 TLS 1.3 suite.
openssl s_client -connect example.com:443 \
  -tls1_3 -ciphersuites TLS_CHACHA20_POLY1305_SHA256

# TLS 1.2 equivalent: only offer the ChaCha20 cipher suites.
openssl s_client -connect example.com:443 \
  -tls1_2 -cipher 'ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305'

# In the handshake output, look for the negotiated line:
#   New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256

What are the use cases of ChaCha20-Poly1305?

ChaCha20-Poly1305 shows up wherever a protocol needs a fast, side-channel-resistant AEAD that runs well in software. The cipher is a default in modern web traffic, modern VPNs, and modern SSH.

• HTTPS on mobile devices: Cloudflare, Google, and Akamai prefer ChaCha20-Poly1305 for clients that signal a ChaCha20-first preference list. The pattern matches Chrome and Safari on lower-end ARM phones and saves battery on long sessions.
• WireGuard VPN tunnels: WireGuard uses ChaCha20-Poly1305 as its only data-channel cipher. The protocol design rules out negotiation, so every WireGuard peer encrypts and authenticates with the same construction.
• OpenSSH connections: OpenSSH ships [email protected] as the default cipher on modern releases. The suite covers both record encryption and the length field, which closes a class of length-leak attacks against the SSH transport.
• QUIC and HTTP/3: QUIC defines TLS 1.3 cipher suites for its packet protection, and TLS_CHACHA20_POLY1305_SHA256 is one of the three required suites. Servers behind HTTP/3 negotiate it for mobile clients alongside AES-GCM.
• IPsec and S/MIME: RFC 7634 added ChaCha20-Poly1305 to IKEv2 and IPsec ESP, and S/MIME 4.0 lists it as an AEAD content-encryption algorithm. Both use cases lean on the same construction the browsers and SSH stacks ship.
• Library defaults: libsodium, BoringSSL, OpenSSL, and Bouncy Castle expose ChaCha20-Poly1305 as a first-class AEAD primitive, which makes it the go-to construction for application-layer encryption in IoT firmware and mobile apps.

What are the known issues with ChaCha20-Poly1305?

The construction itself is sound, but the moving parts around it, nonce handling, server preference order, and legacy client coverage, drive most of the field-level pain.

• Nonce reuse breaks confidentiality: Every encryption with a given key needs a unique 96-bit nonce. A repeated nonce on the same key leaks the XOR of the two plaintexts and lets an attacker forge Poly1305 tags. TLS rotates nonces per record, but custom application-layer use of the cipher has to manage the counter explicitly.
• Older clients miss it: Internet Explorer, Edge 12 to 18, Safari on macOS 10.13 and earlier, and the legacy AOSP Android Browser do not support ChaCha20-Poly1305. A server cipher list that drops AES-GCM in favor of ChaCha20 will break those clients on the handshake.
• Server preference matters: Many TLS 1.2 servers honor server preference order, so a cipher list that puts AES-GCM before ChaCha20 forces every connection to AES-GCM, even on a battery-constrained mobile client. NGINX, HAProxy, and Apache all expose a chacha20-equal-preference toggle.
• Two cipher-suite code points historically: Chrome 33 to 48 used a draft code point, while Chrome 49 onward and OpenSSL 1.1 use the RFC 7905 code points. A misconfigured server that only advertises the draft code point will not negotiate with modern clients.
• HSM and FIPS gaps: Hardware security modules and FIPS 140-3 validated stacks often only certify AES-GCM. Workloads under those constraints cannot use ChaCha20-Poly1305 for record protection without an exception, even when the rest of the fleet prefers it.
• Length-extension on OpenSSH variants: Older non-OpenSSH ChaCha20 SSH variants did not authenticate the packet length field, which led to plaintext-recovery research. OpenSSH's [email protected] fixed this, but custom SSH-like protocols that copied the early design need the OpenSSH variant.

In my experience, the cleanest deployment is to enable both ChaCha20-Poly1305 and AES-256-GCM on the server, set chacha20-equal-preference so the client signal wins, and keep one AES-CBC suite around only for the IE 11 long tail. The mobile clients pick ChaCha20 on their own, the desktop clients land on AES-GCM, and the legacy holdouts still negotiate something the server can audit.

Citations

All ChaCha20-Poly1305 version numbers and platform notes in this guide come from these primary sources:

• RFC 8439, ChaCha20 and Poly1305 for IETF Protocols: datatracker.ietf.org/doc/html/rfc8439
• RFC 7905, ChaCha20-Poly1305 Cipher Suites for TLS: datatracker.ietf.org/doc/html/rfc7905
• RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: datatracker.ietf.org/doc/html/rfc8446
• RFC 7634, ChaCha20, Poly1305, and Their Use in IKEv2 and IPsec: datatracker.ietf.org/doc/html/rfc7634
• Wikipedia, ChaCha20-Poly1305: en.wikipedia.org/wiki/ChaCha20-Poly1305
• Cloudflare blog, It takes two to ChaCha (Poly): blog.cloudflare.com/it-takes-two-to-chacha-poly
• Cloudflare blog, Do the ChaCha: better mobile performance with cryptography: blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography
• Mozilla Server Side TLS: wiki.mozilla.org/Security/Server_Side_TLS
• Mozilla NSS release notes, NSS 3.24: firefox-source-docs.mozilla.org/security/nss/releases/nss_3_24.html
• Apple Developer, Security framework SecureTransport: developer.apple.com/documentation/security/secure_transport
• Chrome Platform Status, ChaCha20 cipher suites: chromestatus.com/feature/5658119915208704
• WireGuard protocol whitepaper: wireguard.com/papers/wireguard.pdf
• OpenSSH PROTOCOL.chacha20poly1305 specification: github.com/openssh/openssh-portable/blob/master/PROTOCOL.chacha20poly1305