TLS e HTTPS

Uma negociação antes da conversa

Antes de a primeira letra do seu GET /minha-conta existir, navegador e servidor já trocaram meia dúzia de mensagens. Nelas eles combinam qual versão do protocolo e qual cifra usar, derivam uma chave secreta que ninguém escutando consegue calcular, e o servidor prova ser quem diz ser. Só quando tudo isso termina o HTTP entra em cena — trafegando dentro de um túnel já pronto.

A parte elegante é que o TLS não conhece HTTP. Ele é uma camada genérica entre TCP e o aplicativo: os mesmos passos protegem e-mail (SMTP, IMAP), bancos de dados, MQTT em dispositivos IoT e VPNs. HTTPS é apenas "HTTP dentro de TLS" — o S não muda nada no HTTP em si.

O handshake, mensagem por mensagem

Avance pelos sete passos e acompanhe o momento exato em que a chave de sessão passa a existir e o tráfego deixa de ser legível. Marque a caixa "ver como quem está escutando a rede" para comparar o que você vê com o que a espiã obtém.

O handshake TLS 1.3

# O handshake TLS 1.3 completo — uma ida e volta.

# → ClientHello                              (em texto claro)
#     versões suportadas: 1.3
#     cifras: AES-128-GCM, ChaCha20-Poly1305
#     key_share: chave pública EFÊMERA do cliente  ← já na 1ª msg
#     server_name: exemplo.com.br                  ← ⚠ visível!

# ← ServerHello                              (em texto claro)
#     cifra escolhida, key_share do servidor
#
#  ⚡ neste ponto os dois lados derivam a MESMA chave de sessão,
#     por Diffie-Hellman. Tudo daqui em diante vai cifrado.

# ← Certificate                              🔒 já cifrado
#     o certificado do site + a CA intermediária
# ← CertificateVerify                        🔒
#     assinatura de TODO o handshake, com a chave privada do site
#     ← este é o passo que mata o man-in-the-middle
# ← Finished                                 🔒
#     MAC de todo o handshake (detecta downgrade)

# → Finished                                 🔒
# → GET /minha-conta                         🔒 só agora o HTTP

# TLS 1.2 precisava de DUAS idas e voltas; o 1.3 faz em UMA,
# porque o cliente já chuta a chave efêmera na primeira mensagem.
# Numa conexão intercontinental (~150 ms de RTT), isso é a
# diferença entre 300 ms e 150 ms antes do primeiro byte útil.

Por que cada peça está ali

# Por que cada peça está ali — e o que quebra sem ela.
#
# DIFFIE-HELLMAN EFÊMERO  → confidencialidade + sigilo futuro
#   sem ele: a chave da sessão viria cifrada com a chave do
#   certificado, e quem gravasse o tráfego hoje poderia decifrar
#   tudo no dia em que essa chave vazasse.
#
# CERTIFICADO             → identidade
#   sem ele: você teria um canal perfeitamente cifrado... com o
#   atacante.
#
# CertificateVerify       → prova de POSSE da chave privada
#   sem ele: o certificado é público, qualquer um copia. Assinar
#   dados que só existem NESTA conexão é o que prova que o
#   servidor é mesmo o dono.
#
# Finished (MAC)          → integridade do próprio handshake
#   sem ele: um atacante alteraria o ClientHello para remover as
#   cifras fortes e forçar uma fraca — o ataque de DOWNGRADE.
#
# AES-GCM                 → confidencialidade + integridade dos dados

# SIGILO FUTURO (forward secrecy), explicado:
#   As chaves DH desta conexão são efêmeras — geradas agora,
#   descartadas ao final, nunca gravadas em disco.
#   A chave privada do certificado serve apenas para ASSINAR.
#   Se ela vazar amanhã, o tráfego gravado hoje continua ilegível.
#   O TLS 1.3 removeu de vez os modos sem essa propriedade.

O que o HTTPS não esconde

# O que o HTTPS NÃO esconde de quem observa a rede:
#
#  ✗ o endereço IP do servidor
#  ✗ o nome do domínio — vai em claro no SNI do ClientHello e
#    também na consulta DNS anterior
#  ✗ o TAMANHO e o RITMO dos pacotes (análise de tráfego consegue
#    inferir muita coisa: qual vídeo você está assistindo, qual
#    página de um site você abriu)
#  ✗ o horário e a duração da conexão
#
#  ✓ escondidos: a URL completa, cabeçalhos, cookies, corpo,
#    resposta — tudo que vem depois do handshake

# É por isso que provedores e firewalls corporativos conseguem
# bloquear sites específicos mesmo sob HTTPS: basta olhar o SNI.
# As respostas em andamento: ECH (Encrypted Client Hello), que
# cifra o SNI, e DNS sobre HTTPS/TLS, que fecha o vazamento do DNS.

# HSTS — fechando a janela do primeiro acesso
#   Ao digitar "banco.com", o navegador tenta HTTP antes do
#   redirecionamento. Um atacante na rede pode sequestrar esse
#   primeiro pedido (ataque SSL stripping).
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
#   Com isso o navegador PROMETE nunca mais usar HTTP nesse
#   domínio. Com "preload", a promessa já vem embutida no
#   navegador — antes mesmo do primeiro acesso.

Configuração na prática

# Configurar TLS na prática: o que importa

#  1. TLS 1.2 e 1.3 apenas. Desligue SSLv3, TLS 1.0 e 1.1.
#  2. Só cifras com sigilo futuro e AEAD (ECDHE + AES-GCM/ChaCha20).
#  3. HSTS ligado, com preload.
#  4. Certificados renovados automaticamente (ACME/certbot) —
#     a causa nº 1 de queda por TLS é certificado vencido.
#  5. Cadeia completa servida (site + intermediárias). Esquecer a
#     intermediária funciona no seu navegador, que a tem em cache,
#     e falha no celular de outra pessoa — um bug clássico.

# Ferramentas para conferir em vez de supor:
#   ssllabs.com/ssltest        — nota A+ a F, com o porquê
#   testssl.sh                 — o mesmo, localmente
openssl s_client -connect exemplo.com.br:443 -tls1_3

# mTLS (TLS mútuo): o CLIENTE também apresenta certificado.
# Usado entre microsserviços e em redes zero-trust — a identidade
# do serviço deixa de ser "está dentro da VPN" e passa a ser
# criptográfica. É o que malhas de serviço como o Istio automatizam.

Experimentando

Mini projeto: capture um handshake real com o Wireshark. Filtre por tls, acesse um site e identifique cada mensagem da visualização acima nos pacotes de verdade. Repare no que você consegue ler — o SNI, em texto claro, dizendo qual site você acessou — e no ponto exato em que tudo vira Application Data ilegível. Depois compare uma conexão TLS 1.2 com uma 1.3 e conte as idas e voltas.

Projeto principal: suba um servidor HTTPS local com um certificado que você mesmo emitiu (aproveite a mini-PKI da lição anterior) e escreva um cliente em Python que se conecte a ele. Depois provoque cada falha propositalmente: certificado expirado, nome de domínio errado, CA não instalada. Observe as exceções exatas que a biblioteca levanta. Por fim, desligue a verificação com verify=False e reflita sobre o que você acabou de desativar — é a linha que aparece em incontáveis tutoriais e transforma HTTPS em teatro.

Desafio extra: monte um proxy TLS interceptador na sua própria máquina, com mitmproxy. Instale a raiz dele no seu navegador e observe todo o seu tráfego HTTPS em texto claro. Depois tente interceptar um app de celular que use certificate pinning e veja a conexão falhar — o app exige uma chave específica e ignora a loja de raízes do sistema. Esse exercício ensina de uma vez o poder de quem controla a loja de certificados e o motivo de o pinning existir.

Teste sua intuição

Onde você encontra isso