Handshake TLS.

O handshake TLS negocia a versão do protocolo, a cipher suite, a identidade do servidor e as chaves de sessão antes de qualquer dado de aplicação ser enviado. No TLS 1.2 (RFC 5246), o handshake demora dois round trips e usa ClientHello, ServerHello, Certificate, ServerKeyExchange, mais um par Finished que confirma a transcrição negociada. O TLS 1.3 (RFC 8446, 2018) condensa isto num único round trip, cifra tudo após o ServerHello, remove primitivas antigas (RC4, modos CBC sem AEAD, troca de chaves RSA estática, compressão) e suporta retomada 0-RTT — rápida, mas vulnerável a replay, pelo que só deve transportar pedidos idempotentes.

Ambas as versões modernas exigem (EC)DHE efémero para forward secrecy e autenticam o servidor através de um certificado X.509 validado ao longo de uma cadeia de confiança. O hash da transcrição do handshake e o MAC do Finished são o que historicamente quebrou ataques de downgrade e de renegociação: o POODLE (2014) forçou as vítimas a descer para o padding CBC do SSL 3.0, o FREAK e o Logjam (2015) coagiram RSA/DH de grau de exportação, e o BEAST explorou os IVs do CBC no TLS 1.0. O sentinela de proteção contra downgrade do TLS 1.3, presente no server random, sinaliza agora a adulteração. Outros modos de falha que importam operacionalmente incluem cipher suites fracas ou obsoletas, certificados expirados ou mal emitidos, ausência de OCSP stapling e incompatibilidades de SNI/certificado em infraestrutura partilhada.

sequenceDiagram
  participant C as Cliente
  participant S as Servidor
  C->>S: ClientHello (versões, cipher suites, key share)
  S->>C: ServerHello (suite escolhida, key share)
  S->>C: Certificate + CertificateVerify
  S->>C: Finished
  Note over C,S: Ambos derivam chaves simétricas via (EC)DHE
  C->>S: Finished
  C->>S: Dados de aplicação cifrados