Como HTTPS e TLS realmente funcionam: guia prático

Por que o HTTPS é importante (e por que você deve entendê-lo)

Você provavelmente já viu o ícone de cadeado no navegador e sabe que o HTTPS criptografa o tráfego. Mas quando aparece um erro de certificado ou uma chamada de API falha com um erro de TLS, você sabe exatamente o que está acontecendo? Muitos desenvolvedores tratam o HTTPS como uma caixa preta — até algo quebrar. Este guia desvenda como o HTTPS e o TLS realmente funcionam, do handshake à cadeia de certificados, para que você possa depurar problemas com confiança.

O básico: HTTPS = HTTP + TLS

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

• Criptografia: Os dados são embaralhados para que bisbilhoteiros não possam lê-los.
• Autenticação: Você está falando com o servidor real, não com um impostor.
• Integridade: Os dados não podem ser modificados em trânsito sem detecção.

Antes do TLS 1.3, o protocolo era chamado SSL (Secure Sockets Layer), mas o SSL está obsoleto. Hoje, TLS 1.2 e 1.3 são os padrões.

O handshake TLS: passo a passo

O handshake é onde a mágica acontece. É uma conversa que estabelece um canal seguro antes que qualquer dado HTTP seja enviado. Aqui está uma versão simplificada para TLS 1.2 (TLS 1.3 é mais rápido, mas similar em conceito):

1. Client Hello: O cliente envia as versões de TLS suportadas, suítes de cifras e um valor aleatório (Client Random).
2. Server Hello: O servidor escolhe uma versão de TLS e uma suíte de cifras, envia seu próprio valor aleatório (Server Random) e apresenta seu certificado.
3. Verificação do certificado: O cliente verifica o certificado em relação às CAs raiz confiáveis, expiração e nome de domínio.
4. Troca de chaves: Usando algoritmos como ECDHE, ambas as partes derivam um segredo compartilhado (pre-master secret) sem nunca enviá-lo pela rede.
5. Finished: Ambos os lados verificam a integridade do handshake e mudam para comunicação criptografada usando chaves simétricas derivadas do segredo compartilhado.

No TLS 1.3, o handshake é reduzido a uma ida e volta (1-RTT) e ainda suporta 0-RTT para sessões retomadas, melhorando a latência.

Por que a criptografia assimétrica é usada apenas inicialmente

A criptografia assimétrica (como RSA ou ECDSA) é lenta e computacionalmente cara. O TLS a usa apenas para trocar com segurança uma chave de sessão simétrica, que é então usada para criptografia em massa (por exemplo, AES-GCM ou ChaCha20-Poly1305). Essa abordagem híbrida equilibra segurança e desempenho.

Certificados e a cadeia de confiança

Um certificado vincula uma chave pública a um nome de domínio e é assinado por uma Autoridade Certificadora (CA). Navegadores e sistemas operacionais vêm com um repositório de CAs raiz confiáveis. Quando um servidor apresenta seu certificado, o cliente constrói uma cadeia do certificado do servidor até uma CA intermediária e, finalmente, até uma raiz confiável.

Erros comuns de certificado incluem:

• Certificado expirado: O período de validade do certificado terminou.
• Nome de host incompatível: O Subject Alternative Name (SAN) do certificado não corresponde ao domínio solicitado.
• Emissor não confiável: A CA raiz não está no repositório de confiança do cliente (por exemplo, certificados autoassinados).
• Cadeia incompleta: O servidor não enviou os certificados intermediários, então o cliente não consegue construir um caminho até uma raiz confiável.

Ferramentas como openssl s_client ou verificadores SSL online ajudam a diagnosticar esses problemas.

Depurando conexões HTTPS

Quando o HTTPS falha, você precisa inspecionar o handshake. Aqui estão comandos práticos:

# Verificar detalhes do certificado e cadeia
openssl s_client -connect example.com:443 -servername example.com -showcerts

# Verificar versão TLS e cifra
openssl s_client -connect example.com:443 -tls1_3

# Testar expiração do certificado
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Nos navegadores, o painel Segurança das Ferramentas de Desenvolvedor mostra detalhes da conexão, e curl -v https://example.com revela as etapas do handshake.

Configurações incorretas comuns de TLS

Mesmo com o HTTPS habilitado, configurações incorretas podem enfraquecer a segurança ou quebrar a compatibilidade:

Como inspecionar o TLS na prática

Se você está depurando um servidor web, comece verificando a cadeia de certificados e a suíte de cifras. Para Nginx, certifique-se de que sua configuração inclua a cadeia completa:

ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

Use ferramentas online como o SSL Labs para um relatório abrangente, mas sempre verifique com ferramentas de linha de comando para checagens rápidas.

Perguntas frequentes

Qual é a diferença entre TLS e SSL?

SSL é o predecessor do TLS. As versões SSL 2.0 e 3.0 estão obsoletas devido a vulnerabilidades de segurança. TLS 1.2 e 1.3 são os protocolos seguros atuais.

Por que meu navegador mostra um aviso de certificado mesmo que o certificado seja válido?

Causas comuns incluem uma cadeia de certificados incompleta, um nome de host incompatível ou o certificado ter sido emitido por uma CA não confiável pelo seu sistema. Verifique o SAN do certificado e certifique-se de que os intermediários sejam servidos.

Como posso verificar qual versão TLS meu servidor suporta?

Use openssl s_client -connect seudominio.com:443 -tls1_3 (ou -tls1_2) e procure o protocolo na saída. Ferramentas online como o SSL Labs também fornecem relatórios detalhados.

Quando você precisar inspecionar ou formatar rapidamente dados JSON de respostas de API durante a depuração, o JSON Formatter pode ajudar a visualizar e validar a estrutura.