TLS e certificados
Como duas máquinas que nunca se viram combinam uma chave secreta e como o certificado prova a identidade do servidor.
O problema: conversar em público
Os dados de uma conexão atravessam redes que você não controla: o Wi-Fi do café, o provedor de internet, os roteadores entre data centers. Qualquer um nesse caminho pode ler o que passa, alterar o conteúdo ou se passar pelo servidor.
O TLS (Transport Layer Security) resolve os três problemas de uma vez, criando um canal protegido sobre uma conexão TCP comum:
| Garantia | Protege contra |
|---|---|
| Sigilo | Alguém no caminho lendo senhas, dados pessoais e tokens |
| Integridade | Alguém no caminho alterando a resposta, como trocar o número de uma conta bancária |
| Autenticidade | Um servidor falso fingindo ser o verdadeiro |
O HTTPS é o HTTP dentro de TLS. Mas o TLS também protege conexões com o PostgreSQL, o Redis, filas de mensagens, servidores de e-mail e qualquer serviço que fale TCP.
O desafio: combinar um segredo sem se encontrar
Cifrar dados é a parte fácil: com uma chave secreta compartilhada, algoritmos como o AES cifram e decifram rapidamente. O difícil é combinar essa chave com um servidor que você nunca viu, por uma rede em que todo mundo escuta.
O TLS resolve com duas técnicas de criptografia que trabalham juntas:
| Técnica | Para que serve no TLS | Velocidade |
|---|---|---|
| Troca de chaves (Diffie-Hellman com curvas elípticas) | Cada lado envia um valor público; os dois calculam o mesmo segredo, que nunca trafega | Lenta, usada uma vez por conexão |
| Criptografia simétrica (AES ou ChaCha20) | Cifra todo o tráfego com o segredo combinado | Rápida |
| Assinatura digital (RSA ou ECDSA) | Prova que quem está do outro lado tem a chave privada do certificado | Usada no início |
A ideia da troca de chaves é contraintuitiva: alguém que observa toda a conversa vê os dois valores públicos e, mesmo assim, não consegue calcular o segredo. Como as chaves são novas a cada conexão, quem gravar o tráfego hoje e roubar a chave privada do servidor no futuro continua sem conseguir decifrar o que gravou. Essa propriedade se chama sigilo futuro (forward secrecy).
O certificado: provar quem é
A troca de chaves combina um segredo com alguém. Mas com quem? Se um atacante interceptar a conexão e fizer a troca de chaves no lugar do servidor, o cliente combina um segredo com o atacante.
O certificado resolve isso. É um documento que diz: "a chave pública X pertence ao domínio api.loja.com.br", assinado por uma autoridade certificadora (CA). Na conexão, o servidor envia o certificado e prova, com uma assinatura, que tem a chave privada correspondente.
Um certificado contém, entre outras coisas:
Assunto: CN=api.loja.com.br
Nomes alternativos: DNS:api.loja.com.br, DNS:www.loja.com.br
Emissor: CN=Autoridade Intermediária
Válido de: 10/03/2026
Válido até: 08/06/2026
Chave pública: EC P-256 ...
Assinatura: ... feita pela chave do emissorA cadeia de confiança
O cliente não conhece o certificado de cada site. Ele conhece um conjunto pequeno de autoridades raiz, que vêm instaladas no sistema operacional ou no navegador. A confiança se propaga por uma cadeia:
Raiz (já está no sistema do cliente)
└─ assina ─▶ Intermediária
└─ assina ─▶ Certificado do servidor (api.loja.com.br)As raízes ficam guardadas offline e quase nunca assinam diretamente. Quem emite os certificados do dia a dia são as intermediárias. Por isso o servidor precisa enviar o próprio certificado e o intermediário: o cliente só tem a raiz.
O que o cliente confere
Antes de confiar na conexão, o cliente confere quatro coisas. Reproduzimos cada falha com uma autoridade de teste e o curl:
| O cliente confere | Situação testada | Resultado |
|---|---|---|
| Tudo certo | Cadeia completa, nome certo, dentro da validade | Conexão aceita |
| A cadeia chega a uma raiz confiável | O servidor enviou só o próprio certificado, sem o intermediário | unable to get local issuer certificate |
| O nome bate com o endereço acessado | Certificado de outro.loja.test servido em api.loja.test | no alternative certificate subject name matches target hostname |
| A data está dentro da validade | Certificado vencido em abril de 2024 | certificate has expired |
| O emissor é uma autoridade confiável | Certificado autoassinado | self-signed certificate |
O caso do intermediário ausente merece atenção: alguns navegadores buscam o intermediário sozinhos, e o site parece funcionar. Clientes de backend, como o curl, o Node, o Java e o Go, em geral não buscam, e a mesma chamada falha entre serviços.
O custo da negociação
A negociação do TLS acontece depois da conexão TCP e acrescenta idas e voltas pela rede antes do primeiro byte útil. Medimos com 50 milissegundos de ida e volta simulados:
| Versão | TCP | TCP + TLS | Primeiro byte da resposta |
|---|---|---|---|
| TLS 1.2 | 51 ms | 170 ms | 221 ms |
| TLS 1.3 | 51 ms | 109 ms | 161 ms |
O TLS 1.2 precisou de cerca de duas idas e voltas a mais que o TCP, e o TLS 1.3, de uma. O TLS 1.3 refez a negociação para gastar menos viagens, e é um dos motivos para preferi-lo. O outro motivo, como no tópico de TCP, é reaproveitar conexões: a negociação é paga uma vez por conexão, e não por pedido.
Por que isso importa quando a IA escreve o código
Erros de certificado aparecem com frequência em ambientes de desenvolvimento e homologação, e a sugestão mais comum de um assistente é a mais perigosa:
- Desligar a verificação de certificado para a chamada funcionar.
- Copiar uma configuração que aceita TLS 1.0 e 1.1, versões com falhas conhecidas.
- Conectar ao banco de dados sem TLS, ou com TLS sem verificação, dentro de uma rede compartilhada.
- Configurar o servidor só com o certificado final, sem o intermediário.
- Nenhum alerta antes do vencimento, até o dia em que o certificado vence e tudo para.
O próximo nível compara as formas de obter, instalar e renovar certificados e de configurar o TLS.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
TLS em cinco minutos
Explique em no máximo cinco minutos de leitura o que o TLS faz e o que é um certificado, para alguém que programa mas só conhece o cadeado do navegador. Cubra só o essencial: as três garantias do TLS, como as duas pontas combinam um segredo sem enviá-lo, o que um certificado prova, o que é a cadeia de confiança e por que desligar a verificação é perigoso. Use uma analogia simples. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
A negociação TLS passo a passo
Quero entender o que acontece numa negociação TLS 1.3, mensagem por mensagem. Aja como um mentor de segurança. Pergunte primeiro qual é a minha experiência com criptografia. Conduza assim, uma etapa por vez: 1. A mensagem inicial do cliente: versões, algoritmos, o nome do servidor (SNI) e a parte pública da troca de chaves. 2. A resposta do servidor: a parte dele da troca de chaves, o certificado e a prova de que tem a chave privada. 3. Como os dois calculam o mesmo segredo sem enviá-lo, explicado com uma analogia. 4. O que o cliente confere no certificado antes de continuar. 5. Por que o TLS 1.3 precisa de uma ida e volta a menos que o TLS 1.2. 6. O que é sigilo futuro e por que ele importa. Faça uma pergunta de verificação em cada etapa e espere a minha resposta antes de continuar.
Cadeia de confiança e o que dá errado
Quero entender a cadeia de confiança dos certificados e os erros mais comuns. Explique: 1. Raiz, intermediária e certificado final: quem assina quem e por que as raízes não assinam direto. 2. Onde as raízes ficam guardadas no cliente, e por que Node, Java e Python com requests podem usar listas diferentes das do sistema operacional. 3. Os campos de um certificado que o cliente confere: nomes alternativos, validade, uso da chave e emissor. Depois me apresente cinco mensagens de erro reais (unable to get local issuer certificate, certificate has expired, hostname mismatch, self-signed certificate, certificate signed by unknown authority) e pergunte, para cada uma, qual é a causa provável e como corrigir sem desligar a verificação. Corrija as minhas respostas.
O que o TLS protege e o que não protege
Quero entender os limites do TLS. Explique, com exemplos concretos: 1. O que alguém na mesma rede consegue ver de uma conexão TLS (endereço, nome do servidor, tamanho e horário do tráfego) e o que não consegue. 2. O que acontece se o cliente não verificar o certificado, com um exemplo de ataque no meio do caminho. 3. Por que um certificado válido não diz nada sobre a honestidade do site. 4. O que o TLS não protege: dados guardados no servidor, logs, a própria aplicação. 5. O que é um proxy de inspeção corporativo e como ele consegue ler conexões TLS. Depois me faça quatro perguntas de cenário e corrija as minhas respostas.