Suite de cifrado.

Una suite de cifrado especifica el conjunto de algoritmos que un protocolo seguro usa para proteger una sesión. En TLS 1.2 (RFC 5246), una suite como TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 selecciona ECDHE para el intercambio de claves, RSA para la autenticación, AES-128-GCM para el cifrado y SHA-256 para la PRF. TLS 1.3 (RFC 8446) simplificó el modelo negociando el intercambio de claves y las firmas por separado del AEAD: solo quedan cinco suites (por ejemplo, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256), y todas ofrecen confidencialidad hacia el futuro (forward secrecy).

Por qué las suites heredadas son peligrosas. Las suites débiles han impulsado una década de ataques prácticos. RC4 quedó formalmente prohibido en TLS por el RFC 7465 después de que los sesgos en su flujo de claves permitieran recuperar texto en claro. 3DES y otros cifrados de bloque de 64 bits son vulnerables al ataque de cumpleaños Sweet32 (CVE-2016-2183), que recupera texto en claro tras unos 32 GB de tráfico con una misma clave. La criptografía de grado export hizo posibles FREAK (CVE-2015-0204) y Logjam, degradando las conexiones a RSA y Diffie-Hellman de 512 bits, que son rompibles. Las suites anónimas (aDH/aECDH) omiten por completo la autenticación e invitan a la interceptación activa.

Endurecimiento. Deshabilite RC4, 3DES, las suites export y anónimas, y el intercambio de claves con RSA estático; prefiera suites AEAD con ECDHE (o los valores predeterminados de TLS 1.3). Herramientas como Qualys SSL Labs, testssl.sh y los perfiles de configuración de Mozilla, NIST SP 800-52r2 y el BSI alemán codifican valores predeterminados seguros.

flowchart TD
  A[Client Hello:<br/>suites de cifrado ofrecidas] --> B[El servidor elige una suite]
  B --> C[Intercambio de claves<br/>ECDHE / RSA]
  C --> D[Autenticación<br/>firma del certificado]
  D --> E[Cifrado de datos<br/>AES-GCM / ChaCha20]
  E --> F[Integridad<br/>etiqueta AEAD / HMAC]
  F --> G[Sesión segura]