Cipher Suite.

A cipher suite specifies the bundle of algorithms used by a secure protocol to protect a session. In TLS 1.2 (RFC 5246), a suite like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 selects ECDHE for key exchange, RSA for authentication, AES-128-GCM for encryption, and SHA-256 for the PRF. TLS 1.3 (RFC 8446) simplified the model by negotiating key exchange and signatures separately from the AEAD: only five suites remain (e.g., TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256), and every one provides forward secrecy.

Why legacy suites are dangerous. Weak suites have driven a decade of practical attacks. RC4 was formally prohibited in TLS by RFC 7465 after biases in its keystream enabled plaintext recovery. 3DES and other 64-bit-block ciphers are vulnerable to the Sweet32 birthday attack (CVE-2016-2183), which recovers plaintext after roughly 32 GB of traffic under one key. Export-grade cryptography enabled FREAK (CVE-2015-0204) and Logjam, downgrading connections to breakable 512-bit RSA and Diffie-Hellman. Anonymous (aDH/aECDH) suites omit authentication entirely and invite active interception.

Hardening. Disable RC4, 3DES, export and anonymous suites, and static-RSA key exchange; prefer AEAD suites with ECDHE (or the TLS 1.3 defaults). Tools like Qualys SSL Labs, testssl.sh, and configuration profiles from Mozilla, NIST SP 800-52r2, and the German BSI codify safe defaults.

flowchart TD
  A[Client Hello:<br/>offered cipher suites] --> B[Server picks one suite]
  B --> C[Key exchange<br/>ECDHE / RSA]
  C --> D[Authentication<br/>certificate signature]
  D --> E[Bulk encryption<br/>AES-GCM / ChaCha20]
  E --> F[Integrity<br/>AEAD tag / HMAC]
  F --> G[Secure session]