Como HTTPS e TLS Realmente Funcionam: Handshake e Certificados

Security2026-10-30TryQuickToolBox

Por que HTTPS é importante (e por que é mal compreendido)

Você provavelmente já viu o ícone de cadeado no navegador e assumiu que o site é "seguro". Mas o que isso realmente significa? HTTPS não se trata apenas de criptografia; trata-se de identidade, integridade e confiança. Muitos desenvolvedores tratam o TLS como uma caixa preta—configuram uma vez e esquecem. Isso leva a configurações incorretas, certificados expirados e conjuntos de cifras vulneráveis.

Neste artigo, vamos detalhar como HTTPS e TLS realmente funcionam, desde o handshake até a validação de certificados, e mostrar como configurá-los corretamente. Sem enrolação, apenas conhecimento prático que você pode aplicar hoje.

O Handshake TLS: O que acontece antes do primeiro byte

Quando um cliente (navegador) se conecta a um servidor via HTTPS, eles realizam um handshake TLS. Isso estabelece um canal seguro. Aqui está uma versão simplificada (TLS 1.3):

  1. Client Hello: O cliente envia os conjuntos de cifras suportados, um valor aleatório e um compartilhamento de chave (para troca de chaves).
  2. Server Hello: O servidor escolhe um conjunto de cifras, envia seu próprio valor aleatório e compartilhamento de chave, e apresenta sua cadeia de certificados.
  3. Autenticação: O cliente verifica o certificado do servidor contra CAs confiáveis e verifica o nome do host.
  4. Derivação de Chave: Ambos os lados calculam o segredo compartilhado usando ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).
  5. Finished: Ambos enviam mensagens "Finished" criptografadas para confirmar o handshake.

Após isso, os dados da aplicação são criptografados com chaves simétricas. O TLS 1.3 reduz as viagens de ida e volta para uma, melhorando a latência.

Troca de Chaves: ECDHE vs RSA

Versões mais antigas do TLS usavam troca de chaves RSA, que não possui sigilo direto (forward secrecy). Se a chave privada do servidor for comprometida, o tráfego passado pode ser descriptografado. Configurações modernas usam ECDHE, que fornece sigilo direto—cada sessão tem chaves únicas.

# Exemplo: Verificar algoritmos de troca de chaves suportados
openssl s_client -connect example.com:443 -cipher 'ECDHE'

Certificados: As âncoras de confiança

Um certificado vincula uma chave pública a uma identidade (nome de domínio). Ele é assinado por uma Autoridade Certificadora (CA) na qual o cliente confia. Os navegadores vêm com um armazenamento de CAs raiz confiáveis.

Quando você visita um site, o servidor envia uma cadeia: certificado folha (para seu domínio) → CA intermediária → CA raiz. O cliente verifica cada assinatura até uma raiz confiável.

Tipos de Certificados

Etapas de Validação do Certificado

Os navegadores verificam:

Se qualquer verificação falhar, você recebe um aviso. Nunca ignore esses avisos em produção.

Configurando HTTPS no seu servidor

Vamos ver uma configuração típica do Nginx para HTTPS com configurações modernas de TLS.

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:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # HSTS (use com cautela)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

Notas:

Obtendo Certificados com Let's Encrypt

Let's Encrypt fornece certificados DV gratuitos. Use o Certbot para automatizar a emissão e renovação:

sudo certbot --nginx -d example.com -d www.example.com

O Certbot modifica sua configuração do Nginx e configura um cron job para renovação. Sempre teste a renovação com --dry-run.

Armadilhas comuns e como evitá-las

Testando sua configuração HTTPS

Use ferramentas online como SSL Labs ou ferramentas de linha de comando para verificar sua configuração.

# Verificar detalhes do certificado
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -text

# Testar suporte a TLS 1.3
openssl s_client -connect example.com:443 -tls1_3

Procure por:

FAQ

Qual é a diferença entre TLS e SSL?

SSL é o predecessor do TLS. O TLS 1.0 era essencialmente o SSL 3.1. Hoje, "SSL" é frequentemente usado coloquialmente, mas você deve sempre usar TLS 1.2 ou 1.3.

Preciso de um certificado pago para HTTPS?

Não. Certificados DV gratuitos do Let's Encrypt são confiáveis por todos os principais navegadores e fornecem a mesma criptografia que os pagos. Certificados pagos oferecem garantias e suporte, mas a criptografia é idêntica.

Como o HTTPS afeta o desempenho?

O TLS adiciona latência devido ao handshake, mas o TLS 1.3 reduz para uma viagem de ida e volta. Com retomada de sessão e HTTP/2, a sobrecarga é mínima. Os custos de criptografia/descriptografia são baixos em CPUs modernas.

Pronto para inspecionar a configuração TLS do seu servidor? Use nosso Analisador de Logs Nginx para identificar padrões de tráfego incomuns e garantir que sua configuração HTTPS está funcionando como esperado.