O handshake do TLS 1.3 em linhas gerais

O que é

A RFC 8446 define o handshake. O cliente envia um ClientHello com as extensões supported_versions, signature_algorithms e key_share; o key share é um valor público (EC)DHE efêmero para um ou mais grupos. O servidor escolhe um grupo e responde com um ServerHello que traz o seu próprio key_share. A partir daí, os dois lados derivam as chaves do handshake, e todas as mensagens seguintes são cifradas: EncryptedExtensions, o Certificate do servidor, o CertificateVerify (uma assinatura sobre a transcrição) e o Finished (um HMAC sobre a transcrição). O cliente responde com o seu próprio Finished e pode então enviar dados de aplicação. É uma única ida e volta, daí o nome "1-RTT". Se o cliente tiver apostado em um grupo que o servidor não suporta, o servidor envia um HelloRetryRequest e o cliente tenta de novo com outro key share, o que custa mais uma ida e volta.

Depois do handshake, o servidor pode enviar mensagens NewSessionTicket; uma conexão posterior apresenta o ticket como pre_shared_key e pode dispensar a troca de certificados. Com esse PSK, o cliente também pode enviar "early data" (0-RTT) já no primeiro envio. A RFC afirma de forma explícita que os dados 0-RTT não têm forward secrecy e que não há garantia de proteção contra replay entre conexões.

Por que importa

A RFC 8446 lista o que foi removido em relação ao TLS 1.2: suítes de cifras com RSA estático e Diffie-Hellman estático (transporte de chave RSA), compressão, DSA, grupos DHE personalizados e as cifras simétricas legadas; a renegociação é proibida por completo. Toda troca de chaves baseada em chave pública passa a oferecer forward secrecy, e todas as suítes restantes são AEAD (TLS_AES_128_GCM_SHA256 é de implementação obrigatória). O certificado deixa de ser visível na rede, o que muda o que middleboxes passivos e logs conseguem observar.

Como aplicar

• Prefira o TLS 1.3 sempre que as duas pontas o suportarem; a versão é negociada por meio de supported_versions, e não pelo campo de versão legado, de modo que middleboxes antigos que inspecionam esse campo ainda veem "TLS 1.2".
• Ofereça primeiro o grupo de key share que os pares esperados preferem, para evitar as idas e voltas do HelloRetryRequest; a RFC exige secp256r1 e recomenda X25519 para clientes.
• Deixe o 0-RTT desativado, a menos que a camada de aplicação envie antecipadamente apenas requisições idempotentes; a seção da RFC sobre proteção contra replay descreve tickets de uso único e verificações de atualidade (freshness) de que um servidor precisaria.
• Prefira a retomada com um key share novo (psk_dhe_ke): segundo a RFC, um PSK usado sozinho faz com que os dados de aplicação percam a forward secrecy, de modo que o vazamento de uma chave de tickets exporia essas sessões. Faça a rotação das chaves de tickets de qualquer forma.

Armadilhas

O "modo de compatibilidade com middleboxes" faz o TLS 1.3 parecer, na rede, uma retomada de sessão do TLS 1.2; por isso, para decifrar capturas de pacotes são necessários os segredos da sessão, e não apenas o certificado. Certificados de cliente continuam funcionando, mas são solicitados dentro da parte cifrada do handshake, de modo que proxies que terminam o TLS precisam tratá-los por conta própria.