Como SSL/TLS Funciona: O Handshake TLS Explicado

Toda vez que você visita um site HTTPS, seu navegador e o servidor realizam um handshake TLS — uma troca rápida que autentica o servidor, concorda nos parâmetros de criptografia e deriva uma chave secreta compartilhada. Isso acontece em 1-2 idas e voltas de rede (50-200ms) antes de qualquer conteúdo de página ser carregado.

O handshake TLS 1.3 (padrão atual)

O TLS 1.3 completa o handshake em uma única ida e volta (1-RTT):

Passo 1 — Client Hello Seu navegador envia: versões TLS suportadas, cipher suites suportados, um número aleatório e parâmetros de compartilhamento de chave (para troca de chaves Diffie-Hellman).

Passo 2 — Server Hello + Certificate + Finished O servidor responde com: cipher suite escolhido, seu certificado (provando sua identidade), seu compartilhamento de chave é uma mensagem “Finished”. No TLS 1.3, o certificado é criptografado — observadores passivos não podem ver a qual site você está se conectando.

Passo 3 — Client Finished O navegador verifica o certificado contra sua lista de CAs confiáveis, calcula a chave de sessão compartilhada a partir da troca Diffie-Hellman e envia sua mensagem “Finished”. Dados de aplicação criptografados podem fluir agora.

Total: 1 ida e volta. Conexões retomadas (onde o cliente já se conectou antes) podem usar 0-RTT — enviando dados criptografados com a primeira mensagem.

Handshake TLS 1.2 (ainda amplamente usado)

O TLS 1.2 requer 2 idas e voltas:

1. Client Hello → versões suportadas, ciphers, número aleatório
2. Server Hello → cipher escolhido, certificado, troca de chave do servidor
3. Client Key Exchange → segredo pré-master (criptografado com a chave pública do servidor ou via Diffie-Hellman)
4. Change Cipher Spec + Finished (ambos os lados)

O TLS 1.2 suporta mais cipher suites — incluindo alguns fracos. A configuração adequada importa mais do que com o TLS 1.3.

O que acontece dentro da conexão criptografada

Após o handshake, todos os dados são criptografados com a chave de sessão negociada usando um cipher simétrico (tipicamente AES-256-GCM ou ChaCha20-Poly1305):

• Confidencialidade — dados são criptografados; apenas os dois endpoints podem lê-los
• Integridade — cada mensagem inclui um MAC (código de autenticação de mensagem); qualquer adulteração é detectada
• Autenticação — o certificado do servidor prova sua identidade (e opcionalmente, a do cliente)

Cada requisição e resposta HTTP — cabeçalhos, corpo, cookies, URLs — trafega por este canal criptografado.

Forward secrecy

O TLS moderno usa troca de chaves Diffie-Hellman efêmera, o que significa que cada conexão gera uma chave de sessão única. Mesmo que a chave privada do servidor seja comprometida depois, conversas passadas não podem ser descriptografadas.

O TLS 1.3 torna o forward secrecy obrigatório. O TLS 1.2 o suporta, mas também permite troca de chaves RSA (que não fornece forward secrecy). É por isso que o TLS 1.3 é preferido.

O papel do certificado

O handshake TLS depende de o servidor ter um certificado SSL/TLS válido. O certificado fornece:

1. A chave pública do servidor — usada durante a troca de chaves
2. Nome(s) de domínio — o navegador verifica se correspondem à URL
3. Assinatura da CA — prova que uma Autoridade Certificadora confiável atesta este certificado
4. Datas de validade — o navegador rejeita certificados expirados

Sem um certificado válido, o handshake falha e o navegador mostra um aviso de segurança. Obtenha um certificado gratuito →

Desempenho

Em hardware moderno, o custo de CPU da criptografia é negligível — instruções AES-NI lidam com isso em hardware. O principal custo são as idas e voltas extras, que o TLS 1.3 minimiza.

O que se pode ver na rede

Sem HTTPS (HTTP)

Um observador na rede vê tudo:

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

Nomes de usuário, senhas, cookies, conteúdo de página — tudo em texto plano.

Com HTTPS (TLS)

O mesmo observador vê:

[Handshake TLS — certificado do servidor visível no TLS 1.2, criptografado no TLS 1.3]
[Dados de aplicação criptografados — indistinguíveis de bytes aleatórios]
[Dados de aplicação criptografados]
[Dados de aplicação criptografados]

Eles podem ver o endereço IP de destino e o hostname SNI (no TLS 1.2 — criptografado no TLS 1.3 com ECH). Não podem ver o caminho da URL, cabeçalhos, corpo ou cookies.

Como o certificado se encaixa

O handshake TLS depende de o servidor ter um certificado SSL/TLS válido:

1. A chave pública do servidor — usada durante a troca de chaves
2. Nome(s) de domínio — o navegador verifica se correspondem à URL
3. Assinatura da CA — prova que uma Autoridade Certificadora confiável atesta este certificado
4. Datas de validade — o navegador rejeita certificados expirados

Sem um certificado válido, o handshake falha e o navegador mostra um aviso de segurança. Obtenha um certificado gratuito →

Cipher suites TLS comuns em 2026

TLS 1.3 (apenas 5 cipher suites — todos seguros)

TLS_AES_256_GCM_SHA384       ← Mais comum
TLS_AES_128_GCM_SHA256       ← Amplamente usado
TLS_CHACHA20_POLY1305_SHA256 ← Melhor para mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/embarcados
TLS_AES_128_CCM_8_SHA256     ← IoT/embarcados (tag curta)

TLS 1.2 (use apenas suites AEAD)

ECDHE-ECDSA-AES256-GCM-SHA384  ← Melhor com certificado ECC
ECDHE-RSA-AES256-GCM-SHA384    ← Melhor com certificado RSA
ECDHE-ECDSA-CHACHA20-POLY1305  ← Otimizado para mobile

Evite suites não-AEAD (modo CBC) no TLS 1.2 — eles foram vulneráveis a ataques como BEAST e Lucky13.

Perguntas frequentes

O HTTPS deixa meu site mais lento?

O handshake TLS adiciona uma ida e volta (TLS 1.3) ou duas (TLS 1.2) na primeira conexão. A retomada de sessão elimina isso para visitantes que retornam. Como o HTTPS habilita HTTP/2 (multiplexação, compressão de cabeçalhos), sites HTTPS frequentemente são mais rápidos no geral.

O que é um cipher suite?

Um cipher suite é uma combinação de algoritmos usados para troca de chaves, criptografia e autenticação de mensagens. Exemplo: TLS_AES_256_GCM_SHA384 significa TLS com criptografia AES-256-GCM e SHA-384 para integridade da mensagem. O TLS 1.3 tem apenas 5 cipher suites — todos seguros. O TLS 1.2 tem 37, alguns dos quais são fracos.

Alguém pode descriptografar tráfego HTTPS depois?

Não com forward secrecy (troca de chaves efêmera). Cada sessão usa uma chave única derivada da troca Diffie-Hellman. Mesmo que a chave privada de longo prazo do servidor seja comprometida, as chaves de sessão passadas não podem ser recuperadas. O TLS 1.3 impõe isso; o TLS 1.2 o suporta quando configurado corretamente.

Como o GetHTTPS se relaciona com isso?

O GetHTTPS gera o certificado que torna o handshake TLS possível. O certificado contém a chave pública que o servidor usa durante a troca de chaves. O GetHTTPS cria este par de chaves no seu navegador usando a Web Crypto API e se conecta diretamente à API ACME da Let’s Encrypt para obter a assinatura. Como o GetHTTPS funciona →