Como HTTPS e TLS realmente funcionam: guia prático

Security2026-10-26TryQuickToolBox

O problema: HTTPS está em todo lugar, mas como funciona de verdade?

Você vê o ícone de cadeado no navegador e assume que sua conexão é segura. Mas quando algo dá errado—um erro de certificado, um aviso de conteúdo misto ou um handshake TLS lento—você precisa entender o que está acontecendo nos bastidores. Este guia divide HTTPS e TLS em partes práticas e digeríveis para que você possa depurar e otimizar conexões seguras.

HTTPS é simplesmente HTTP sobre TLS (Transport Layer Security). O TLS fornece criptografia, autenticação e integridade. Vamos ver como funciona, passo a passo.

O que o TLS realmente faz

O TLS resolve três problemas centrais:

Criptografia: Impede que bisbilhoteiros leiam os dados trocados entre cliente e servidor.
Autenticação: Prova a identidade do servidor (e opcionalmente a do cliente) usando certificados.
Integridade: Garante que os dados não foram adulterados durante o trânsito.

Sem TLS, o tráfego HTTP é texto simples—qualquer um no caminho da rede pode lê-lo ou modificá-lo. O TLS envolve o HTTP em um túnel criptografado.

O handshake TLS: passo a passo

Antes que qualquer dado HTTP flua, o cliente e o servidor realizam um handshake para concordar com os parâmetros de criptografia. Aqui está o fluxo típico para TLS 1.2 (TLS 1.3 é mais rápido, mas similar em conceito):

Client Hello: O cliente envia versões suportadas de TLS, suítes de cifras e um valor aleatório.
Server Hello: O servidor escolhe uma versão TLS e suíte de cifras, e envia seu próprio valor aleatório.
Certificado: O servidor envia sua cadeia de certificados, incluindo sua chave pública e prova de identidade.
Troca de chaves: Usando o certificado, o cliente e o servidor concordam com segurança sobre um segredo compartilhado (pre-master secret) usando algoritmos como ECDHE.
Finished: Ambos os lados verificam o handshake e mudam para comunicação criptografada usando chaves simétricas derivadas do segredo compartilhado.

TLS 1.3 reduz isso para uma única ida e volta (1-RTT) e até suporta 0-RTT para sessões retomadas, tornando as conexões mais rápidas.

Certificados: a âncora de confiança

Um certificado vincula uma chave pública a uma identidade (como um nome de domínio). Ele é assinado por uma Autoridade Certificadora (CA) na qual o cliente confia. Quando seu navegador se conecta a https://example.com, ele verifica:

O certificado é válido para o domínio.
É assinado por uma CA confiável.
Não expirou.
Não foi revogado (via OCSP ou CRL).

Se qualquer verificação falhar, você recebe um aviso. Para desenvolvimento, você pode usar certificados autoassinados, mas os navegadores os sinalizarão, a menos que você explicitamente confie neles.

Erros comuns de certificado e correções

Erro	Causa provável	Correção
NET::ERR_CERT_COMMON_NAME_INVALID	O certificado não corresponde ao domínio	Reemitir o certificado com os Subject Alternative Names (SANs) corretos
NET::ERR_CERT_AUTHORITY_INVALID	Autoassinado ou CA não confiável	Use uma CA confiável ou instale a CA no repositório de confiança
NET::ERR_CERT_DATE_INVALID	Expirado ou ainda não válido	Renove o certificado e verifique o relógio do sistema

Criptografia na prática: simétrica vs assimétrica

O TLS usa ambos os tipos de criptografia:

Criptografia assimétrica (chave pública): Usada durante o handshake para trocar um segredo compartilhado com segurança. Lenta, mas resolve a distribuição de chaves.
Criptografia simétrica: Usada para dados em massa após o handshake. Algoritmos rápidos como AES-GCM ou ChaCha20-Poly1305 criptografam o tráfego HTTP real.

O segredo compartilhado do handshake é usado para derivar chaves de sessão simétricas. Essa abordagem híbrida oferece segurança e desempenho.

Depurando conexões TLS

Quando o HTTPS se comporta mal, você precisa inspecionar o handshake. Aqui estão comandos e técnicas práticas:

1. Inspecione detalhes do certificado com OpenSSL

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

Isso imprime a cadeia de certificados, a suíte de cifras e os detalhes do handshake. Procure por Verify return code: 0 (ok) para confirmar a confiança.

2. Teste versões TLS e cifras

nmap --script ssl-enum-ciphers -p 443 example.com

Isso lista as versões TLS e suítes de cifras suportadas, ajudando a identificar configurações fracas.

3. Verifique cabeçalhos de segurança HTTP

Use o DevTools do navegador (aba Segurança) para ver se a página está totalmente segura. Conteúdo misto (recursos HTTP em uma página HTTPS) dispara avisos e pode quebrar funcionalidades.

4. Analise logs do servidor para erros TLS

Se você usa Nginx, falhas de handshake TLS aparecem nos logs de erro. Por exemplo:

2025/01/01 12:00:00 [error] 1234#0: *5 SSL_do_handshake() failed (SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown) while SSL handshaking, client: 203.0.113.1, server: 0.0.0.0:443

Isso indica que o cliente rejeitou o certificado. Verifique sua cadeia de certificados e configuração.

Otimizando TLS para desempenho

O TLS adiciona latência, mas você pode minimizá-la:

Habilite TLS 1.3: Handshake mais rápido e segurança aprimorada.
Use retomada de sessão: IDs de sessão ou tickets reduzem a sobrecarga do handshake para clientes que retornam.
Habilite OCSP stapling: O servidor inclui o status de revogação no handshake, evitando uma requisição separada do cliente.
Escolha suítes de cifras eficientes: Prefira AES-GCM com aceleração de hardware ou ChaCha20-Poly1305 em dispositivos móveis.
Mantenha certificados pequenos: Minimize o comprimento da cadeia e use certificados ECDSA para chaves menores.

Armadilhas comuns e como evitá-las

Certificados expirados: Automatize a renovação com Let's Encrypt e configure monitoramento.
Cadeias de certificados incompletas: Sempre inclua certificados intermediários; intermediários ausentes causam erros de confiança em alguns clientes.
Protocolos fracos: Desabilite TLS 1.0 e 1.1; use TLS 1.2+ com cifras fortes.
Conteúdo misto: Garanta que todos os sub-recursos (imagens, scripts, estilos) usem HTTPS.
Configuração incorreta de HSTS: Use o cabeçalho Strict-Transport-Security com cuidado; comece com um max-age curto.

Perguntas frequentes

Qual é a diferença entre HTTPS e TLS?

HTTPS é HTTP sobre TLS. TLS é o protocolo que fornece criptografia e autenticação. Portanto, HTTPS é a versão segura do HTTP, alimentada pelo TLS.

Como o TLS 1.3 melhora em relação ao TLS 1.2?

O TLS 1.3 reduz o handshake para uma ida e volta (1-RTT) e suporta 0-RTT para sessões retomadas. Ele também remove algoritmos criptográficos obsoletos e fracos, simplificando a configuração e melhorando a segurança.

Por que recebo erros de certificado em desenvolvimento?

Servidores de desenvolvimento frequentemente usam certificados autoassinados, que os navegadores não confiam por padrão. Você pode adicionar o certificado ao seu repositório de confiança ou usar uma ferramenta como mkcert para gerar certificados confiáveis localmente.

Precisa inspecionar ou depurar rapidamente logs do servidor para erros TLS? Experimente nosso Analisador de Logs Nginx para analisar e filtrar entradas de log no seu navegador.