Como HTTPS e TLS funcionam de verdade: o handshake explicado

Você digita uma URL, pressiona Enter e um cadeado aparece. Mas o que realmente acontece entre seu navegador e o servidor para tornar essa conexão segura? Muitos desenvolvedores tratam o HTTPS como uma caixa preta — até algo quebrar, como um erro de certificado ou um problema de desempenho. Este artigo revela os bastidores do TLS, o protocolo por trás do HTTPS, e explica o handshake em termos simples.

O que HTTPS realmente é

HTTPS é simplesmente HTTP sobre TLS (Transport Layer Security). O TLS fornece três garantias:

• Confidencialidade – os dados são criptografados para que bisbilhoteiros não possam lê-los.
• Integridade – os dados não podem ser modificados em trânsito sem detecção.
• Autenticação – você está falando com o servidor real, não com um impostor.

Sem TLS, o HTTP envia tudo em texto claro: senhas, cookies e dados de formulário ficam visíveis para qualquer um no caminho da rede.

O handshake TLS em linguagem simples

O handshake é a negociação que ocorre antes de qualquer dado de aplicação ser enviado. Seu objetivo: concordar com algoritmos de criptografia, verificar a identidade do servidor e estabelecer chaves secretas compartilhadas. Aqui está o fluxo do TLS 1.3, o padrão moderno:

1. Client Hello – o navegador envia uma lista de suítes de cifras suportadas, um valor aleatório e sua chave pública (para troca de chaves).
2. Server Hello – o servidor escolhe uma suíte de cifras, envia seu próprio valor aleatório e chave pública, e fornece sua cadeia de certificados.
3. Verificação do certificado – o navegador verifica o certificado contra CAs raiz confiáveis, valida o nome de domínio e checa a expiração.
4. Derivação de chaves – ambos os lados calculam o mesmo segredo compartilhado usando a troca de chaves (tipicamente ECDHE). As chaves de sessão são derivadas.
5. Finished – ambos os lados enviam um MAC sobre o transcript do handshake para confirmar que nada foi adulterado.

Depois disso, os dados de aplicação criptografados fluem. No TLS 1.3, o handshake leva um round trip (1-RTT), e a retomada pode alcançar 0-RTT.

TLS 1.2 vs TLS 1.3

O TLS 1.2 exigia dois round trips e suportava algoritmos mais fracos. O TLS 1.3 removeu cifras obsoletas, simplificou o handshake e criptografa mais do próprio handshake. Sempre prefira TLS 1.3; a maioria dos servidores e navegadores modernos o suporta.

Certificados: a âncora de confiança

Um certificado vincula uma chave pública a um nome de domínio e é assinado por uma Autoridade Certificadora (CA). Os navegadores vêm com um armazenamento de CAs raiz confiáveis. Durante a verificação, o navegador constrói uma cadeia a partir do certificado do servidor até uma raiz confiável.

Tipos comuns de certificado:

• DV (Validação de Domínio) – comprova o controle do domínio; rápido e gratuito (ex.: Let's Encrypt).
• OV (Validação de Organização) – inclui detalhes verificados da empresa.
• EV (Validação Estendida) – verificações de identidade mais rigorosas; não mostra mais a barra verde na maioria dos navegadores.

Certificados expiram. Automatize a renovação com clientes ACME como o Certbot para evitar indisponibilidades.

Troca de chaves e sigilo perfeito

O TLS moderno usa troca de chaves efêmera (ECDHE). Cada sessão gera um novo par de chaves, então mesmo se a chave privada do servidor for comprometida posteriormente, sessões passadas não podem ser descriptografadas. Essa propriedade é chamada de sigilo perfeito (forward secrecy). Evite a troca de chaves RSA estática, que não possui essa proteção.

Armadilhas comuns de HTTPS e como evitá-las

• Conteúdo misto – carregar recursos HTTP em uma página HTTPS dispara avisos do navegador. Use URLs relativas ou atualize para HTTPS.
• Certificados expirados – configure monitoramento e renovação automática.
• Suítes de cifras fracas – desative TLS 1.0/1.1 e RC4/3DES. Use uma ferramenta como o SSL Labs para testar.
• HSTS ausente – adicione o cabeçalho Strict-Transport-Security para forçar HTTPS.

Depurando problemas de TLS

Quando um handshake falha, use openssl s_client para inspecionar a conexão:

openssl s_client -connect example.com:443 -servername example.com

Isso mostra a cadeia de certificados, o protocolo negociado e a cifra. Para erros específicos do navegador, verifique o painel Segurança no DevTools.

FAQ

HTTPS é o mesmo que TLS?

HTTPS é HTTP sobre TLS. TLS é o protocolo criptográfico; HTTPS é a versão segura do protocolo de aplicação HTTP.

Preciso de um certificado separado para cada subdomínio?

Não necessariamente. Um certificado wildcard cobre todos os subdomínios de primeiro nível, e um certificado multi-domínio (SAN) pode listar vários nomes.

Como o TLS 1.3 melhora o desempenho?

O TLS 1.3 reduz o handshake a um round trip (e zero na retomada) e simplifica a negociação de cifras, diminuindo a latência.

Pronto para inspecionar a segurança do seu próprio site? Use nosso analisador de logs do Nginx para detectar erros TLS suspeitos e falhas de handshake em seus logs.