Suíte criptográfica.

Uma suíte criptográfica define o conjunto de algoritmos que um protocolo seguro usa para proteger uma sessão. Em TLS 1.2 (RFC 5246), uma suíte como TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 escolhe ECDHE para a troca de chaves, RSA para a autenticação, AES-128-GCM para a cifragem e SHA-256 para a PRF. O TLS 1.3 (RFC 8446) simplificou o modelo ao negociar a troca de chaves e as assinaturas separadamente do AEAD: restam apenas cinco suítes (por exemplo, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256), e todas fornecem sigilo de encaminhamento (forward secrecy).

Por que as suítes legadas são perigosas. As suítes fracas impulsionaram uma década de ataques práticos. O RC4 foi formalmente proibido no TLS pela RFC 7465 depois que enviesamentos no seu fluxo de chaves permitiram a recuperação de texto em claro. O 3DES e outras cifras de bloco de 64 bits são vulneráveis ao ataque de aniversário Sweet32 (CVE-2016-2183), que recupera texto em claro após cerca de 32 GB de tráfego sob uma mesma chave. A criptografia de grau de exportação viabilizou o FREAK (CVE-2015-0204) e o Logjam, rebaixando as conexões para RSA e Diffie-Hellman de 512 bits, que são quebráveis. As suítes anônimas (aDH/aECDH) omitem totalmente a autenticação e convidam à interceptação ativa.

Endurecimento. Desative RC4, 3DES, as suítes de exportação e anônimas e a troca de chaves com RSA estático; prefira suítes AEAD com ECDHE (ou os padrões do TLS 1.3). Ferramentas como o Qualys SSL Labs, o testssl.sh e os perfis de configuração da Mozilla, do NIST SP 800-52r2 e do BSI alemão codificam padrões seguros.

flowchart TD
  A[Client Hello:<br/>suítes criptográficas oferecidas] --> B[O servidor escolhe uma suíte]
  B --> C[Troca de chaves<br/>ECDHE / RSA]
  C --> D[Autenticação<br/>assinatura do certificado]
  D --> E[Cifragem de dados<br/>AES-GCM / ChaCha20]
  E --> F[Integridade<br/>etiqueta AEAD / HMAC]
  F --> G[Sessão segura]