Como HTTPS e TLS realmente funcionam: handshake explicado

Você digitou https:// na frente de uma URL, viu o cadeado e seguiu em frente. Mas quando um certificado expira às 2 da manhã, um aviso de conteúdo misto quebra sua página de checkout, ou um cliente pergunta por que a chamada de API dele falha com um erro TLS, "o cadeado significa que é seguro" deixa de ser uma resposta útil. Este artigo explica o que realmente acontece na rede durante uma conexão HTTPS e como configurá-la sem adivinhação.

O que o HTTPS adiciona ao HTTP

HTTPS é o HTTP comum transportado dentro de uma sessão TLS (Transport Layer Security). O TLS fornece três garantias concretas:

• Confidencialidade — o tráfego é criptografado, então intermediários não podem lê-lo.
• Integridade — adulterações em trânsito são detectadas e a conexão falha.
• Autenticação — o servidor prova que controla a chave privada do certificado apresentado.

Observe o que não está nessa lista: HTTPS não diz nada sobre se o servidor é confiável, se a aplicação tem vulnerabilidades ou se os dados estão seguros em repouso. Ele protege o canal, não os endpoints.

O handshake TLS, passo a passo

O handshake é a negociação que acontece antes de qualquer byte HTTP fluir. No TLS 1.3, ele leva uma única ida e volta; o TLS 1.2 precisa de duas. Aqui está o fluxo do TLS 1.3 em termos simples:

1. ClientHello — o cliente envia as versões TLS suportadas, uma lista de cipher suites, um nonce aleatório e uma chave compartilhada para uma troca de chaves Diffie-Hellman (tipicamente X25519).
2. ServerHello — o servidor escolhe uma versão e cipher suite, retorna sua própria chave compartilhada e envia sua cadeia de certificados mais uma assinatura sobre o transcript do handshake.
3. Derivação de chaves — ambos os lados calculam o segredo compartilhado a partir da troca Diffie-Hellman. Chaves efêmeras significam que a chave de sessão é única e a forward secrecy é mantida: comprometer a chave de longo prazo do servidor depois não descriptografa o tráfego gravado.
4. Finished — ambos os lados enviam um MAC sobre o transcript. Se algo foi alterado, o handshake é abortado.
5. Dados da aplicação — requisições e respostas HTTP são criptografadas com chaves simétricas derivadas do segredo compartilhado.

O certificado é onde a autenticação reside. O servidor assina o handshake com sua chave privada; o cliente verifica essa assinatura usando a chave pública no certificado, depois verifica o próprio certificado contra uma CA raiz confiável, checando o hostname, as datas de validade e o status de revogação.

Simétrico vs Assimétrico: por que ambos são usados

Criptografia assimétrica (RSA ou ECDSA) é lenta, mas resolve a distribuição de chaves. Cifras simétricas (AES-GCM, ChaCha20-Poly1305) são rápidas, mas exigem uma chave compartilhada. O TLS usa criptografia assimétrica apenas durante o handshake para estabelecer uma chave de sessão simétrica, depois criptografa os dados em massa com essa chave. É por isso que uma conexão TLS 1.3 moderna é rápida: uma ida e volta, depois AES ou ChaCha20 barato para todo o resto.

Cipher suites e o que realmente importa

Uma cipher suite é um pacote nomeado de algoritmos. No TLS 1.3, a lista é curta e todas as opções são consideradas seguras; no TLS 1.2, você precisa escolher com cuidado. Uma comparação rápida:

Conclusão prática: habilite apenas TLS 1.2 e 1.3, desabilite TLS 1.0/1.1 e prefira certificados ECDSA para menor custo de handshake. Deixe seu servidor ou proxy reverso escolher a ordem das suites; a maioria dos padrões é sensata em softwares da era de 2024.

Como inspecionar uma conexão real

Você não precisa confiar na documentação — verifique seus próprios endpoints. O openssl s_client mostra a versão negociada, a cifra e a cadeia de certificados:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Olhe as linhas Protocol e Cipher, depois verifique a saída da cadeia de certificados para expiração e entradas SAN. Se a cadeia estiver incompleta, alguns clientes falharão enquanto os navegadores terão sucesso, o que é uma fonte clássica de bugs do tipo "funciona no Chrome mas não no curl".

Erros comuns de configuração HTTPS

• Certificado intermediário ausente — o servidor envia apenas seu certificado folha. Navegadores podem buscar o intermediário, mas clientes de API frequentemente não o farão.
• Conteúdo misto — uma página HTTPS carrega um script ou imagem via HTTP; os navegadores bloqueiam ou rebaixam. Audite com o console do navegador.
• Sem HSTS — sem Strict-Transport-Security, uma primeira requisição via HTTP pode ser interceptada antes do redirecionamento acontecer.
• Versões de protocolo fracas ou desatualizadas — deixar TLS 1.0 habilitado para um cliente legado enfraquece silenciosamente todas as conexões.
• Expiração de certificado — automatize a renovação; um lembrete manual no calendário não é uma estratégia.

Uma configuração de servidor razoável

Para Nginx, um bloco moderno mínimo fica assim:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

O arquivo fullchain.pem é o que previne o problema do intermediário ausente. Mantenha o redirecionamento da porta 80 em um bloco de servidor separado para que o HTTP ainda funcione para desafios ACME.

O que o HTTPS não protege

Uma vez que a requisição chega ao seu servidor, o TLS acabou. Falhas de injeção, controle de acesso quebrado, segredos vazados em logs e CORS mal configurado vivem todos acima da camada de transporte. Trate o TLS como a linha de base, não como o programa de segurança. Se você está depurando um incidente, separe problemas de transporte (falhas de handshake, certificados expirados) de problemas de aplicação (erros 500, payloads ruins) desde cedo — eles têm correções completamente diferentes.

FAQ

O HTTPS criptografa o caminho da URL e a query string?

Sim. No HTTPS, toda a requisição HTTP, incluindo o caminho e a query string, está dentro do registro TLS criptografado. No entanto, o hostname (SNI) e o IP de destino são visíveis durante o handshake, a menos que o Encrypted Client Hello esteja em uso.

O TLS 1.3 é sempre mais rápido que o TLS 1.2?

Geralmente sim, porque economiza uma ida e volta e suporta retomada 0-RTT. Em conexões de alta latência a diferença é perceptível; em uma rede local é mínima. O maior ganho é que o TLS 1.3 remove completamente as opções de cifras legadas.

Ainda preciso de HSTS se eu redireciono HTTP para HTTPS?

Sim. Um redirecionamento só ajuda depois que o navegador alcançou seu servidor. O HSTS diz ao navegador para pular o HTTP completamente em requisições futuras, fechando a janela em que uma primeira requisição poderia ser interceptada.

Quando você está auditando uma implantação e precisa verificar detalhes de certificado ou decodificar um handshake capturado rapidamente, mantenha um fluxo de trabalho baseado em terminal à mão — e se você estiver documentando as descobertas para uma equipe, o Markdown editor é uma maneira rápida de transformar a saída bruta do openssl em um relatório legível.