Como HTTPS e TLS realmente funcionam: nos bastidores

Você digita uma URL, pressiona Enter e vê o cadeado. Mas o que realmente acontece entre o seu navegador e o servidor para tornar essa conexão segura? Muitos desenvolvedores tratam o HTTPS como uma caixa preta—até que algo quebra, como um erro de certificado ou um problema de desempenho. Este artigo revela os bastidores do HTTPS e do TLS, explicando o handshake, a criptografia e a validação de certificados de forma prática.

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: Você está falando com o servidor real, não com um impostor.

O TLS evoluiu do SSL (Secure Sockets Layer). As versões modernas (TLS 1.2 e 1.3) são as que você deve usar; o SSL está obsoleto.

O handshake TLS: passo a passo

Antes que qualquer dado HTTP flua, o cliente e o servidor realizam um handshake para concordar com as chaves de criptografia. Veja o que acontece em um handshake TLS 1.3 típico (simplificado):

1. Client Hello: O navegador envia uma lista de suítes de cifras suportadas, um valor aleatório e sua chave pública para troca de chaves.
2. Server Hello: O servidor escolhe uma suíte de cifras, envia seu próprio valor aleatório e chave pública, e apresenta seu certificado.
3. Derivação de chaves: Ambos os lados calculam o mesmo segredo compartilhado usando troca de chaves Diffie-Hellman. A partir disso, derivam chaves de sessão para criptografia simétrica.
4. Finished: Ambas as partes enviam um MAC (Message Authentication Code) para verificar a integridade do handshake. Dados de aplicação criptografados agora podem fluir.

O TLS 1.3 reduziu o handshake para uma única ida e volta (1-RTT) e até suporta 0-RTT para sessões retomadas, melhorando a latência.

Troca de chaves: Diffie-Hellman

A magia do TLS moderno é que o cliente e o servidor podem concordar com um segredo compartilhado sem nunca transmiti-lo. O Diffie-Hellman (especificamente ECDHE para curvas elípticas) permite isso. Mesmo que um atacante registre todo o handshake, ele não consegue derivar a chave de sessão—essa propriedade é chamada de forward secrecy (sigilo persistente).

Criptografia simétrica: AES ou ChaCha20

Uma vez estabelecido o segredo compartilhado, o TLS muda para criptografia simétrica (como AES-GCM ou ChaCha20-Poly1305) porque é muito mais rápida que a criptografia assimétrica. As chaves de sessão são usadas para criptografar todos os dados da aplicação.

Validação de certificados: confie, mas verifique

O certificado do servidor é central para a autenticação. Ele contém a chave pública do servidor e é assinado por uma Autoridade Certificadora (CA). Veja como o navegador o valida:

• Cadeia de confiança: O certificado deve encadear até uma CA raiz confiável que esteja pré-instalada no navegador ou no sistema operacional.
• Correspondência de nome de host: O certificado deve ser válido para o domínio que você está visitando (via Subject Alternative Names).
• Período de validade: O certificado não deve estar expirado ou ainda não válido.
• Revogação: O navegador pode verificar OCSP ou CRL para garantir que o certificado não foi revogado.

Se qualquer verificação falhar, você recebe um aviso—como "Sua conexão não é particular".

Configurações incorretas comuns de TLS

Mesmo com o HTTPS habilitado, erros podem enfraquecer a segurança:

• Protocolos obsoletos: Suportar TLS 1.0/1.1 ou SSLv3 expõe você a ataques conhecidos.
• Suítes de cifras fracas: Permitir cifras RC4 ou em modo CBC sem mitigações.
• HSTS ausente: Sem HTTP Strict Transport Security, os usuários podem ser rebaixados para HTTP.
• Gerenciamento inadequado de certificados: Certificados expirados ou configuração de cadeia imprópria.

Use ferramentas como o SSL Test do SSL Labs para verificar sua configuração.

Exemplo prático: habilitando HTTPS com Nginx

Aqui está uma configuração mínima do Nginx para um servidor HTTPS seguro:

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;

    add_header Strict-Transport-Security "max-age=63072000" always;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Esta configuração usa certificados Let's Encrypt, habilita apenas TLS 1.2 e 1.3, e define HSTS.

Perguntas frequentes

Qual é a diferença entre TLS e SSL?

TLS é o sucessor do SSL. As versões do SSL (2.0, 3.0) estão obsoletas devido a falhas de segurança. Quando as pessoas dizem "certificado SSL", geralmente querem dizer um certificado TLS.

O HTTPS deixa meu site lento?

O TLS moderno (1.3) adiciona latência mínima—muitas vezes apenas alguns milissegundos. Com retomada de sessão e HTTP/2, o HTTPS pode ser tão rápido ou mais rápido que o HTTP.

Como obtenho um certificado TLS gratuito?

O Let's Encrypt fornece certificados gratuitos e automatizados. Ferramentas como o Certbot podem obtê-los e renová-los para você.

Conclusão

HTTPS e TLS não são mágica—são protocolos bem projetados que combinam criptografia de chave pública para autenticação com criptografia simétrica para velocidade. Entender o handshake e a validação de certificados ajuda você a depurar problemas e configurar seus servidores com segurança. Sempre use TLS 1.2 ou 1.3, mantenha os certificados atualizados e habilite o HSTS.

Para analisar logs de servidor e identificar erros de TLS ou problemas de desempenho, experimente nosso Analisador de Logs Nginx.