O que é TLS? Como o HTTPS protege o tráfego

#A resposta curta

TLS (Transport Layer Security) é um protocolo que envolve uma conexão de rede com criptografia. HTTPS é HTTP comum enviado por dentro de uma conexão TLS. Quando o navegador mostra o cadeado, ele fez três coisas. Criptografou os dados. Verificou que ninguém os alterou no caminho. E confirmou que o servidor provou ter um certificado confiável para o nome que você digitou.

O terceiro ponto é o que as pessoas costumam entender mal. HTTPS informa com qual servidor você está falando. Não diz se esse servidor é confiável, honesto ou bem administrado.

#Por que HTTP puro não basta

Em Como o HTTP funciona, requisições e respostas são mensagens de texto, e o HTTP não faz nada para escondê-las. Todo dispositivo entre você e o servidor pode lê-las: o roteador de casa, o ponto de acesso de uma cafeteria, o provedor de internet e as redes intermediárias.

Um observador passivo consegue ler um formulário de login enviado por HTTP puro. Um atacante ativo no caminho pode fazer mais. Pode alterar uma página antes de ela chegar até você, inserir um script ou trocar um download por um arquivo modificado. O TLS foi projetado para barrar as duas ameaças. Ele também dá ao cliente um jeito de verificar quem está respondendo, algo que o HTTP puro nunca faz.

#O que o TLS 1.3 oferece

A versão atual é o TLS 1.3, definido na RFC 8446. TLS 1.0 e 1.1 estão descontinuados, como explica a RFC 8996, e o TLS 1.2 ainda é muito usado. A versão 1.3 removeu muitas opções antigas, então há menos maneiras de configurar o handshake de forma errada.

O TLS 1.3 oferece três propriedades.

#Confidencialidade

Os dados da aplicação são criptografados com chaves de sessão que só as duas pontas conhecem. Um observador vê texto cifrado. O tamanho e o momento do tráfego continuam visíveis, mas o conteúdo não.

Um handshake completo do TLS 1.3 usa troca de chaves efêmera. Os dois lados criam valores temporários para a sessão e os descartam depois. Isso dá sigilo perfeito para a frente (forward secrecy): se a chave privada do certificado vazar anos depois, as sessões antigas gravadas devem continuar ilegíveis. Uma chave vazada ainda permite que um atacante se passe pelo servidor daquele momento em diante. Ou seja, o sigilo perfeito protege o passado, não o futuro.

#Integridade

Cada registro carrega uma tag de autenticação de uma cifra AEAD, como AES-GCM ou ChaCha20-Poly1305. O TLS 1.3 permite apenas esse tipo de cifra. Se um atacante alterar um bit em trânsito, a verificação da tag falha e o registro é rejeitado.

#Autenticação do servidor

O servidor prova que tem a chave privada correspondente ao seu certificado. O certificado liga essa chave pública a um nome, como example.com. O cliente verifica o certificado e a cadeia de confiança por trás dele, depois confere o nome. Boa parte do restante deste artigo trata dessa parte.

#O handshake, passo a passo

O handshake combina as chaves e prova identidades antes de qualquer dado HTTP circular. No TLS 1.3, o handshake comum leva uma ida e volta. Os passos abaixo seguem a RFC 8446 em linhas gerais.

#Passo 1: o ClientHello

O seu cliente envia um ClientHello. Ele lista as versões de TLS e as suites de cifra que suporta, e inclui um key share, o valor público temporário do cliente para a troca de chaves. A mensagem também leva o server name indication (SNI), o nome de host que você pediu, em texto puro. Servidores que hospedam muitos sites precisam desse nome para escolher o certificado certo.

#Passo 2: o ServerHello

O servidor escolhe a versão e a suite de cifra e envia o próprio key share. Cada lado combina o seu valor privado com o valor público do outro e chega ao mesmo segredo compartilhado. Um observador que viu os dois valores públicos não consegue calcular esse segredo. Daqui em diante, o handshake já está criptografado.

#Passo 3: o certificado e a prova

O servidor envia o certificado. No TLS 1.2, o certificado era visível na rede. No TLS 1.3, ele viaja dentro da parte criptografada do handshake.

Em seguida, o servidor envia uma mensagem CertificateVerify, uma assinatura sobre a transcrição do handshake feita com a chave privada do certificado. Isso prova que o servidor tem a chave nesta mesma conversa. Um certificado copiado sozinho não serve de nada para um atacante. Uma mensagem Finished, um MAC sobre a transcrição, encerra a parte do servidor.

#Passo 4: o cliente verifica e conclui

O seu cliente confere a cadeia de certificados, as datas de validade, o nome no certificado comparado ao host pedido e a assinatura do CertificateVerify. Se todas as verificações passarem, o cliente envia a própria mensagem Finished, e os dados da aplicação podem circular.

Se uma verificação falhar, o cliente para. Um navegador mostra um aviso de certificado, e o curl encerra com erro. Essas mensagens são a parte mais útil do TLS para quem está começando, porque dizem qual verificação falhou.

#Certificados e cadeias de confiança

Um certificado é uma estrutura X.509, e a RFC 5280 define o perfil usado na internet. Os campos mais importantes aqui são estes.

Clientes modernos ignoram o Common Name (CN) do subject na verificação do nome de host e usam a lista SAN. Quem lê só o CN pode interpretar mal um certificado.

#Como a cadeia é verificada

Um servidor raramente apresenta um certificado que o cliente consegue verificar diretamente. Normalmente, o certificado folha, que cobre o nome de host, é assinado por uma CA intermediária, e a intermediária é assinada por uma CA raiz. O cliente confia em um conjunto de raízes que vem com o sistema operacional ou com o navegador.

O cliente monta um caminho da folha até uma raiz confiável. Em cada elo, verifica a assinatura, confere as datas de validade e confirma que o emissor pode assinar certificados. Depois confere o nome de host. As duas verificações precisam passar.

Qualquer raiz confiável pode, em tese, emitir um certificado para qualquer nome. Por isso a confiança depende das práticas das autoridades do repositório. É por isso que fornecedores removem autoridades que emitem certificados de forma incorreta.

#Revogação

Um certificado pode ser revogado antes de expirar, por exemplo depois que a chave é comprometida. Os clientes podem verificar a revogação por listas (CRL) ou pelo OCSP, mas essas checagens funcionam de forma irregular. Uma conexão sem erro não prova que o certificado nunca foi revogado.

#O que o TLS não protege

#O servidor

O TLS autentica a identidade do servidor. Ele não avalia o comportamento do servidor. Um site de phishing pode obter um certificado válido para um domínio parecido que ele controla. O cadeado então mostra que a conexão chega ao dono da chave desse domínio, não que o domínio pertence ao seu banco. Leia o nome de host na barra de endereço antes de confiar na página. Um servidor corretamente certificado ainda pode ser invadido ou mal administrado.

#Metadados

O TLS esconde o conteúdo, não todos os fatos sobre a conexão. Quem está no caminho ainda vê os endereços IP das duas pontas, a porta, o tamanho e o tempo aproximados do tráfego e o nome do servidor no ClientHello, porque o SNI vai em texto puro. O Encrypted Client Hello é um esforço do IETF para esconder o SNI, mas verifique o quanto ele está implantado antes de supor que um site o usa. As consultas DNS são um protocolo separado e revelam os nomes que você resolve, a menos que use DNS criptografado.

#As pontas

O TLS protege os dados enquanto eles se movem entre duas pontas. Ele não protege as pontas. Um malware no seu computador pode ler dados já descriptografados, e uma extensão do navegador pode ler cada página que você abre. Uma empresa também pode instalar uma raiz confiável própria na sua máquina e descriptografar seu tráfego por meio de um proxy de inspeção. Nesse caso, a decisão de confiança pertence a quem controla essa raiz.

#Laboratório prático: inspecione o HTTPS de example.com

O example.com é um dos nomes que a IANA reserva para documentação e exemplos. Todos os comandos abaixo se conectam apenas ao example.com. O laboratório não altera nada no servidor e não exige conta. Você precisa de um terminal com curl e openssl. Os comandos de openssl foram executados com OpenSSL 3.2.4.

Sua saída será diferente da mostrada aqui. Endereços IP mudam, certificados são renovados e as datas avançam.

#Passo 1: leia a troca com o curl

curl -vI https://example.com

A opção -v mostra os detalhes da conexão, e -I envia uma requisição HEAD, que pede apenas cabeçalhos. Na máquina usada para este artigo (Windows 11 com Git Bash, curl 8.12.1, executado em 8 de novembro de 2026), as linhas relevantes apareceram assim:

* Host example.com:443 was resolved.
* IPv4: 172.66.147.243, 104.20.23.154
* Connected to example.com (172.66.147.243) port 443
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: example.com
< HTTP/1.1 200 OK

Este build do curl usa o Schannel, a biblioteca TLS do Windows, e a saída detalhada dele é diferente da de um curl compilado com OpenSSL. Aqui, o curl não mostrou a versão TLS, a cifra nem as linhas do certificado que este laboratório pede. Em um curl baseado em OpenSSL, procure a linha com a versão TLS e a cifra, e o bloco do certificado com subject, issuer e data de expiração. Os próximos passos trazem os mesmos dados pelo openssl.

O 200 OK significa que o servidor respondeu dentro da conexão TLS. Os cabeçalhos viajam criptografados, e o curl os descriptografa localmente.

#Passo 2: obtenha um resumo curto com o openssl

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

Saída:

Connecting to 172.66.147.243
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits
DONE

Leia linha por linha:

• Protocol version: a versão de TLS negociada para esta conexão.
• Ciphersuite: AES-256-GCM protege os registros, e SHA-384 entra no key schedule.
• Signature type: ECDSA, o algoritmo da chave do certificado.
• Verification: OK, ou seja, a cadeia foi validada contra o repositório de confiança desta build do openssl.
• Server Temp Key: X25519, a troca de chaves efêmera que dá o sigilo perfeito para a frente.

A opção -servername define o SNI. Sem ela, um servidor que hospeda vários sites pode devolver um certificado padrão que não corresponde ao nome que você queria. O redirecionamento </dev/null fecha a entrada padrão, então o comando termina.

#Passo 3: leia os campos do certificado

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Saída:

subject=CN=example.com
issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

O subject tem apenas um CN. O issuer é uma CA intermediária, não a raiz. A janela de validade estava aberta no dia do laboratório e se fecha em 25 de dezembro de 2026. Compare o notAfter com a data do seu sistema, porque um certificado vencido falha mesmo com a cadeia em ordem.

O subject não lista os nomes cobertos, então peça a lista SAN:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Saída:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com

O curinga cobre nomes como www.example.com. O cliente compara esta lista com o host da sua URL.

#Passo 4: liste a cadeia enviada pelo servidor

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'

Saída:

 0 s:CN=example.com
   i:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
 1 s:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
   i:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
 2 s:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
   i:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
 3 s:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services

Cada linha s: é um subject, e cada linha i: é o issuer dele. A entrada 0 é a folha, e cada entrada é emitida pela seguinte. Certificados podem ter assinatura cruzada, então uma cadeia pode chegar a uma raiz por mais de um caminho. O cliente precisa de um caminho válido que termine em uma raiz do próprio repositório.

#Passo 5: confirme que a cadeia valida

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep 'Verify return code'

Saída:

Verify return code: 0 (ok)

Zero significa que o repositório de confiança desta build do openssl aceitou a cadeia. Outros valores apontam uma falha específica, como um certificado expirado.

#Passo 6: force uma falha na verificação de nome

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

Saída, resumida:

depth=0 CN=example.com
verify error:num=62:hostname mismatch
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Verification error: hostname mismatch

O comando continua conectando apenas ao example.com. A opção -verify_hostname pede ao openssl que compare o certificado com example.org, que o certificado não cobre. Um navegador mostra o mesmo tipo de falha. Essa verificação impede que um servidor com certificado válido para um domínio se passe por outro.

#O que levar do laboratório

A conexão negociou TLS 1.3, e o cliente aceitou a cadeia para example.com ao mesmo tempo em que rejeitou o mesmo certificado para example.org. Nenhum desses resultados diz se a empresa por trás do example.com é confiável. O laboratório mostra que o seu cliente chegou ao dono da chave do example.com, e nada mais.

#Erros comuns

• Ler o cadeado como uma nota de confiança. Ele significa que o canal está criptografado e que o certificado foi validado. Não avalia o site.
• Verificar só o CN. Clientes modernos comparam o nome de host com a lista SAN.
• Clicar em um aviso de certificado sem olhar. O aviso significa que uma verificação falhou. Descubra qual antes de continuar.
• Adicionar -k ou --insecure ao curl para fazer um erro sumir. Isso desliga as verificações que você acabou de ler. Use só contra um servidor de teste descartável, nunca com credenciais reais.
• Escrever código com a verificação desligada, como verify=False em um cliente HTTP do Python. Os dados continuam criptografados, mas chegam a quem respondeu.

#Como ir além

Leia as seções de visão geral e de handshake da RFC 8446, depois veja os campos do certificado na RFC 5280. Leia o guia de TLS para servidores da Mozilla e rode uma verificação de configuração em um servidor que você administra.

O próximo artigo da série trata de chaves públicas e privadas, a matemática por trás do certificado. Se a etapa de resolução de nomes é nova para você, leia primeiro O que é DNS?, porque o resultado dela define para qual endereço o handshake vai.

#Fontes

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• Mozilla: Security/Server Side TLS
• Documentação OpenSSL: openssl-s_client
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• IANA: Example domains