Handshake TLS.

El handshake TLS negocia la versión del protocolo, el cipher suite, la identidad del servidor y las claves de sesión antes de enviar cualquier dato de aplicación. En TLS 1.2 (RFC 5246) el handshake requiere dos round trips y utiliza ClientHello, ServerHello, Certificate, ServerKeyExchange, más un par Finished que confirma la transcripción negociada. TLS 1.3 (RFC 8446, 2018) lo reduce a un solo round trip, cifra todo lo que sigue al ServerHello, elimina primitivas heredadas (RC4, modos CBC sin AEAD, intercambio de claves RSA estático, compresión) y admite reanudación 0-RTT — rápida pero vulnerable a replay, por lo que solo debería transportar peticiones idempotentes.

Ambas versiones modernas exigen (EC)DHE efímero para forward secrecy y autentican al servidor mediante un certificado X.509 validado a lo largo de una cadena de confianza. El hash de la transcripción del handshake y el MAC del Finished son lo que históricamente rompió los ataques de downgrade y de renegociación: POODLE (2014) forzaba a las víctimas a bajar al relleno CBC de SSL 3.0, FREAK y Logjam (2015) coaccionaban RSA/DH de grado exportación, y BEAST explotaba los IV de CBC de TLS 1.0. El centinela de protección frente a downgrade en el server random de TLS 1.3 ahora señala la manipulación. Otros modos de fallo que importan operativamente incluyen cipher suites débiles o en desuso, certificados caducados o mal emitidos, ausencia de OCSP stapling y desajustes de SNI/certificado en infraestructura compartida.

sequenceDiagram
  participant C as Cliente
  participant S as Servidor
  C->>S: ClientHello (versiones, cipher suites, key share)
  S->>C: ServerHello (suite elegida, key share)
  S->>C: Certificate + CertificateVerify
  S->>C: Finished
  Note over C,S: Ambos derivan claves simétricas mediante (EC)DHE
  C->>S: Finished
  C->>S: Datos de aplicación cifrados