Como HTTPS e TLS realmente funcionam: guia prático

Você provavelmente já viu o ícone de cadeado no seu navegador e sabe que ele significa "seguro". Mas o que realmente acontece quando você visita um site HTTPS? Como seu navegador sabe que está falando com o servidor real e não com um impostor? E por que o TLS às vezes deixa as coisas mais lentas? Este guia explica HTTPS e TLS em termos práticos, para que você possa configurar, depurar e proteger suas aplicações web com confiança.

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: O servidor prova sua identidade usando um certificado.

Sem TLS, o HTTP envia tudo em texto simples: senhas, cookies e dados pessoais ficam visíveis para qualquer um no caminho da rede. O HTTPS resolve isso.

O handshake TLS em linguagem simples

Antes que qualquer dado criptografado flua, o cliente e o servidor realizam um handshake para concordar com as chaves de criptografia e verificar a identidade. Veja o que acontece em um handshake TLS 1.3 típico (o padrão moderno):

1. Client Hello: O navegador envia uma lista de suítes de cifras suportadas, versões TLS e um valor aleatório.
2. Server Hello: O servidor escolhe uma suíte de cifras, envia seu próprio valor aleatório e fornece sua cadeia de certificados.
3. Troca de chaves: Ambos os lados usam um algoritmo de troca de chaves (como ECDHE) para derivar um segredo compartilhado sem nunca transmiti-lo diretamente.
4. Verificação do certificado: O cliente verifica o certificado do servidor em relação às CAs raiz confiáveis, valida o nome de domínio e verifica a expiração.
5. Finished: Ambos os lados enviam um MAC para confirmar a integridade do handshake, e os dados da aplicação criptografados começam a fluir.

O TLS 1.3 reduz isso para uma única viagem de ida e volta (1-RTT) e até suporta retomada 0-RTT para visitantes recorrentes, reduzindo significativamente a latência em comparação com o TLS 1.2.

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). Navegadores e sistemas operacionais vêm com um repositório de CAs raiz confiáveis. Quando um servidor apresenta seu certificado, o cliente verifica a cadeia até uma raiz confiável.

Tipos comuns de certificado:

• DV (Domain Validated): Prova o controle do domínio; emitido rapidamente e muitas vezes gratuito (ex.: Let's Encrypt).
• OV (Organization Validated): Inclui detalhes verificados da organização; leva mais tempo para ser emitido.
• EV (Extended Validation): Nível mais alto de validação; historicamente mostrava uma barra verde, mas os navegadores modernos não o enfatizam mais.

Certificados expiram, então a automação é essencial. Ferramentas como Certbot ou clientes ACME integrados ao seu proxy reverso cuidam da renovação automaticamente.

Configurando HTTPS no seu servidor

Aqui está uma configuração mínima do Nginx que habilita HTTPS com configurações TLS modernas:

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_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    # HSTS (habilite após testar)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        proxy_pass http://localhost:3000;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Pontos-chave: use apenas TLS 1.2 e 1.3, prefira suítes de cifras ECDHE para sigilo forward secrecy e redirecione HTTP para HTTPS. O HSTS diz aos navegadores para sempre usarem HTTPS para o seu domínio, mas teste com cuidado antes de habilitá-lo com um max-age longo.

Armadilhas comuns e como evitá-las

• Conteúdo misto: Carregar recursos HTTP em uma página HTTPS quebra o cadeado. Use URLs relativas ou garanta que todos os recursos sejam HTTPS.
• Certificados expirados: Automatize a renovação e monitore a expiração. Um certificado expirado causa avisos imediatos no navegador.
• Protocolos fracos: Desabilite TLS 1.0 e 1.1; eles estão obsoletos e são vulneráveis.
• Cadeias de certificados incompletas: Os servidores devem enviar certificados intermediários; caso contrário, alguns clientes falham. Use ferramentas como SSL Labs para testar.
• Sem pré-carregamento HSTS: Para proteção máxima, envie seu domínio para a lista de pré-carregamento HSTS após garantir que todos os subdomínios suportem HTTPS.

TLS 1.2 vs TLS 1.3: o que mudou

O TLS 1.3 é mais rápido e simples, removendo algoritmos legados. A maioria dos clientes modernos o suporta, mas mantenha o TLS 1.2 para dispositivos mais antigos.

Depurando problemas de TLS

Quando o HTTPS falha, verifique estes pontos:

• Use openssl s_client -connect example.com:443 -servername example.com para inspecionar a cadeia de certificados e o handshake.
• Execute curl -vI https://example.com para ver a versão TLS e a cifra negociada.
• Verifique os logs do servidor para erros de handshake; o Nginx registra erros SSL no log de erros.
• Use testadores SSL online para obter uma avaliação abrangente e recomendações.

Se você trabalha com logs do Nginx regularmente, o Analisador de Logs Nginx pode ajudar a identificar falhas de handshake TLS e outros problemas rapidamente.

FAQ

Qual é a diferença entre HTTPS e TLS?

HTTPS é HTTP sobre TLS. TLS é o protocolo criptográfico que fornece criptografia, integridade e autenticação. HTTPS é a versão segura do HTTP que usa TLS.

Preciso de um certificado para serviços internos?

Sim, para serviços internos de produção, use certificados da sua própria CA ou de uma CA pública. Certificados autoassinados causam problemas de confiança; considere usar uma PKI privada ou ferramentas como mkcert para desenvolvimento.

Com que frequência os certificados devem ser renovados?

A prática recomendada moderna é certificados de 90 dias com renovação automatizada, como oferecido pelo Let's Encrypt. Tempos de vida mais curtos reduzem o risco se uma chave for comprometida.

Pronto para proteger seu site? Comece testando sua configuração TLS atual com um verificador SSL e depois aplique as configurações do Nginx acima. Para um mergulho mais profundo em segurança web, explore nossos outros guias sobre OWASP Top 10 e prevenção de XSS.