O que é um handshake TLS, e como ele funciona?

O que acontece durante um handshake TLS, passo a passo?

Aqui está um handshake real, usando TLS 1.3 (RFC 8446), a versão que a maioria dos navegadores negocia por padrão em 2026:

• ClientHello. O cliente envia um valor aleatório, as versões de TLS e os conjuntos de cifra que suporta, e um key_share: a sua metade de uma troca de chaves Diffie-Hellman para um grupo que está disposto a usar (comumente X25519 ou P-256). Oferecer material de chave já na primeira mensagem, em vez de esperar ser solicitado, é a maior mudança estrutural em relação ao TLS 1.2.
• ServerHello. O servidor escolhe uma versão e um conjunto de cifra e responde com o seu próprio key_share para o mesmo grupo. Os dois lados já têm o suficiente para calcular o mesmo segredo compartilhado de forma independente, sem que nenhum dos dois envie esse segredo pela rede. A RFC 8446 Seção 2 chama isso de fase de "Key Exchange" (troca de chaves).
• Certificate e CertificateVerify. Toda mensagem a partir daqui é criptografada com chaves derivadas desse segredo compartilhado. O servidor envia EncryptedExtensions, depois a sua cadeia de Certificate e uma mensagem CertificateVerify, definida na RFC 8446 Seção 4.4.3 como "uma assinatura sobre todo o handshake usando a chave privada correspondente à chave pública na mensagem Certificate". Essa assinatura prova que o servidor tem a chave privada do certificado que acabou de apresentar.
• Finished. Tanto o servidor quanto, depois dele, o cliente enviam uma mensagem Finished: um MAC sobre toda a transcrição do handshake até ali. Se um atacante tivesse alterado qualquer mensagem anterior, as transcrições de cada lado não bateriam mais e a checagem falharia. Assim que a mensagem Finished do cliente sai, a requisição de página de verdade pode começar a fluir.

Toda essa troca leva um round trip: o primeiro envio do cliente e a resposta do servidor já bastam para autenticar o servidor e iniciar o tráfego criptografado. A RFC 8446 documenta isso como o handshake padrão de "1-RTT" (um round trip).

O que o TLS 1.3 mudou em relação ao TLS 1.2?

O TLS 1.2 (RFC 5246) precisa de dois round trips para um handshake completo: ClientHello, depois um envio do servidor com ServerHello, Certificate, um ServerKeyExchange opcional e ServerHelloDone, depois um segundo envio do cliente carregando ClientKeyExchange e o Finished do cliente, antes que o próprio Finished do servidor possa sair. O TLS 1.3 junta a troca de chaves já no primeiro par de mensagens, o que é o motivo de ele descer para um round trip.

A RFC 8446 Seção 1.2 também lista o que foi removido de vez, não só reorganizado:

• Troca de chaves RSA estática e Diffie-Hellman estática. Todo conjunto de cifra agora usa uma troca de chaves efêmera, então uma chave privada de servidor roubada não consegue mais descriptografar tráfego capturado anteriormente.
• Compressão e renegociação. As duas tinham ataques conhecidos; a RFC 8446 declara claramente que "o TLS 1.3 proíbe renegociação".
• Grupos Diffie-Hellman customizados e não autenticados. Só um conjunto pequeno e nomeado de grupos bem avaliados é permitido agora.
• MD5 e SHA-1 em assinaturas, além de RC4, DES, 3DES e cifras de exportação. Todo conjunto de cifra que sobrou é uma construção AEAD (AES-GCM ou ChaCha20-Poly1305), que autentica os dados ao mesmo tempo que os criptografa, sem precisar de uma checagem de integridade separada.

O efeito prático é uma lista mais curta de coisas que um servidor pode configurar errado. Um servidor só com TLS 1.3 não consegue oferecer um conjunto de cifra fraco por acidente, porque nenhum existe para oferecer.

O que é retomada de sessão, e o que é o 0-RTT?

Rodar o handshake completo a cada conexão seria um desperdício quando os dois lados já conversaram recentemente. O TLS 1.2 resolvia isso com um session ID ou um session ticket, deixando o cliente pular direto para as mensagens Finished na próxima vez, o que reduz um handshake completo a um round trip. O TLS 1.3 substitui os dois por chaves pré-compartilhadas (PSK): depois que um handshake termina, o servidor envia um NewSessionTicket carregando uma chave derivada daquela sessão, e o cliente apresenta essa chave na próxima vez em vez de negociar do zero.

O 0-RTT vai além. A RFC 8446 descreve isso como um modo "adicionado, economizando um round trip na abertura da conexão para alguns dados de aplicação": com uma PSK válida, o cliente pode enviar a sua primeira requisição já junto com o primeiro envio, antes mesmo de ouvir qualquer resposta do servidor. O custo é real: a RFC 8446 afirma claramente que os dados do 0-RTT "não têm forward secrecy" e não têm garantia nenhuma contra repetição, então isso só serve para requisições seguras de receber duas vezes, nunca para algo que muda estado, como um pagamento.

O que é SNI, e por que hospedagem compartilhada depende disso?

Server Name Indication é uma extensão do ClientHello, definida na RFC 6066, que existe por causa de um problema de ovo e galinha: um servidor precisa saber qual certificado apresentar antes de conseguir criptografar qualquer coisa, mas o hostname que o cliente quer tradicionalmente só ficava visível dentro da requisição HTTP já criptografada que vem depois. A RFC 6066 Seção 3 coloca essa lacuna direto: "o TLS não oferece um mecanismo para um cliente dizer a um servidor o nome do servidor que está contatando", e acrescenta que isso importa "para facilitar conexões seguras a servidores que hospedam vários servidores 'virtuais' num único endereço de rede subjacente".

O SNI fecha essa lacuna fazendo o cliente enviar o hostname, em texto simples, como parte do próprio ClientHello. Um host compartilhado ou uma borda de CDN com centenas de certificados num único endereço IP lê esse campo e escolhe o certificado correspondente antes de o handshake continuar. Sem SNI, um servidor que hospeda vários domínios num único IP não tem como saber com confiança qual certificado devolver, e clientes antigos ou servidores mal configurados que pulam isso são a causa clássica de um handshake que falha num hostname que compartilha IP com outros.

Para que serve o ALPN?

Application-Layer Protocol Negotiation, definido na RFC 7301, é uma extensão separada que anda junto no mesmo ClientHello e no EncryptedExtensions do servidor. Ele deixa o cliente listar os protocolos de aplicação que sabe falar, mais comumente HTTP/2 ("h2") e HTTP/1.1, e o servidor escolhe um durante o próprio handshake. Antes do ALPN existir, essa negociação acontecia depois de o handshake terminar, como uma troca separada, o que custava tempo em cada conexão. Colocar isso dentro do handshake é uma mudança pequena com um efeito grande: é o motivo de um navegador e um servidor web moderno conseguirem combinar falar HTTP/2 sem um round trip extra para perguntar.

Tudo isso acontece entre um clique e uma página começar a renderizar, e qualquer etapa pode falhar silenciosamente: um certificado pode expirar, um intermediário pode sumir, um servidor pode deixar de suportar um conjunto de cifra que um cliente ainda precisa. Rodar um handshake real contra um host ao vivo, do jeito que a ferramenta de verificação SSL/TLS faz, é o jeito direto de ver qual etapa quebra em vez de adivinhar a partir de uma página de erro do navegador. O HostTracker monitora sites desde 2004, verifica a partir de mais de 300 pontos de verificação em 158 cidades, e pode avisar por e-mail, SMS, chamada de voz, Slack, Telegram e outros no momento em que um monitor SSL vê um handshake que falha.

Perguntas frequentes

SSL é a mesma coisa que TLS?

Não, embora os nomes sejam usados como sinônimos. O SSL é a família de protocolo mais antiga; o TLS 1.0 foi o seu sucessor direto, e toda versão desde então tem sido TLS, até o TLS 1.3 de hoje. "Handshake SSL" e "certificado SSL" sobreviveram como termos do dia a dia mesmo com o protocolo SSL em si aposentado há anos.

Por que o handshake precisa de um certificado, afinal?

Criptografia sozinha só impede um espião passivo de ler o tráfego. Sem um certificado provando quem é o servidor, nada impede um atacante de ficar no meio e rodar o mesmo handshake criptografado com os dois lados separadamente. O certificado, e a assinatura CertificateVerify provando que o servidor tem a chave privada correspondente, é o que transforma criptografia em criptografia com uma parte conhecida.

Qual é a diferença entre o handshake TLS e o mTLS?

O handshake descrito aqui autentica só o servidor; o cliente permanece anônimo na camada TLS e normalmente prova quem é depois, dentro da conexão já criptografada, com uma senha ou um token. O TLS mútuo adiciona uma segunda checagem de certificado na outra direção, então o servidor também verifica a identidade do cliente antes de o handshake terminar. Veja o que é o TLS mútuo para entender como essa etapa a mais muda o fluxo de mensagens.

Um handshake pode ter sucesso e a conexão ainda assim não ser confiável?

Sim, num caso específico: se o cliente confia numa autoridade certificadora que não deveria, por exemplo um proxy corporativo de inspeção ou um malware que instalou um certificado raiz falso, o handshake termina normalmente enquanto um terceiro lê o tráfego no meio. O handshake só garante que as duas partes que negociaram têm chaves compatíveis, não que o repositório de confiança do cliente está limpo.

O que realmente quebra quando um handshake falha?

Incompatibilidade de versão, nenhum conjunto de cifra em comum, um certificado expirado ou com hostname errado, um certificado intermediário faltando, e problemas de SNI em hospedagem compartilhada respondem por quase toda falha real. Falha no handshake SSL: causas e como diagnosticar cobre cada uma com os comandos exatos para diferenciá-las.

Um handshake mais rápido realmente importa para a velocidade da página?

Sim, especialmente numa conexão lenta ou de alta latência, já que cada round trip a mais soma um atraso de rede completo antes de o primeiro byte da página chegar. Esse é o motivo prático de a queda do TLS 1.3, de dois round trips para um, e a queda do 0-RTT para zero em visitantes recorrentes, terem contado como grandes ganhos, e não pequenas limpezas de protocolo.