O que é TLS? Como o HTTPS protege suas conexões

Toda vez que você vê o cadeado na barra do navegador, há um protocolo trabalhando nos bastidores para que ninguém leia ou altere o que trafega entre você e o servidor. Esse protocolo é o TLS. Neste artigo você vai entender o que ele faz, como funciona o handshake que estabelece a conexão segura, o papel dos certificados, o que é forward secrecy e por que tudo isso importa para quem desenvolve.

O que é TLS

TLS (Transport Layer Security) é o protocolo de criptografia que protege a comunicação na internet. Ele é o sucessor do SSL — termo antigo que ainda aparece por aí, embora as versões SSL estejam todas obsoletas e inseguras. Quando alguém diz "certificado SSL", quase sempre está se referindo, tecnicamente, a TLS.

O TLS oferece três garantias fundamentais a uma conexão:

Essas três propriedades são exatamente as defesas contra um atacante que esteja "no meio" da conexão (ataque man-in-the-middle). Sem TLS, qualquer pessoa na mesma rede poderia ler suas senhas e modificar as páginas que você recebe.

Onde o TLS vive na pilha de redes

O nome "Transport Layer Security" entrega a localização: o TLS opera logo acima da camada de transporte (TCP), abaixo dos protocolos de aplicação como HTTP. Essa posição é estratégica. Ela significa que o TLS pode proteger qualquer protocolo que rode sobre TCP — não só HTTP, mas também e-mail (SMTP, IMAP), transferência de arquivos e bancos de dados. Você "embrulha" a conexão em TLS e o protocolo de cima nem precisa saber dos detalhes da criptografia.

TLS e HTTPS: qual a relação

Há uma confusão comum entre os termos. HTTP é o protocolo de aplicação que carrega as páginas web. TLS é o protocolo de segurança que cria um túnel cifrado. HTTPS é simplesmente HTTP rodando dentro de um túnel TLS.

Se você quer revisar o protocolo de base — o que é HTTP, seus métodos, status e como a web conversa — vale a pena, porque o HTTPS não muda nada na semântica do HTTP: os mesmos métodos GET e POST, os mesmos códigos de status. O que muda é que tudo passa cifrado. Por isso, entender o que é HTTPS, a versão segura do HTTP é, na prática, entender o que o TLS adiciona por baixo.

Vale notar uma consequência importante: como o TLS cifra todo o conteúdo HTTP, um observador na rede consegue ver com quem você está falando (o endereço IP e, em muitos casos, o nome do domínio durante o handshake), mas não consegue ver o que você está falando — nem as URLs específicas, nem os dados dos formulários, nem os cookies. A privacidade do conteúdo é garantida; a do metadado de conexão, não totalmente.

Os blocos de criptografia que o TLS usa

O TLS é, na verdade, uma orquestração inteligente de várias primitivas criptográficas. Para acompanhar o handshake, ajuda ter clareza sobre o que é criptografia — simétrica, assimétrica e hashing, porque o TLS usa as três:

A genialidade do design é combinar o melhor de cada mundo: usa a criptografia assimétrica, mais lenta, apenas para o momento crítico de combinar uma chave; e usa a simétrica, mais veloz, para o grosso do tráfego. Essa combinação é chamada de criptografia híbrida.

O que é uma cipher suite

Durante o handshake, cliente e servidor precisam concordar sobre quais algoritmos exatos vão usar. Esse conjunto de escolhas é a cipher suite. Ela define, por exemplo, qual algoritmo de troca de chaves usar, qual algoritmo simétrico vai cifrar os dados e qual função de hash garante a integridade. No TLS 1.3, as cipher suites foram drasticamente simplificadas e as opções inseguras foram removidas — uma das razões pelas quais a versão 1.3 é mais segura por padrão. Você não precisa decorar nomes de cipher suites, mas precisa saber que escolher versões modernas significa, automaticamente, usar combinações que já foram auditadas e consideradas seguras.

A ideia que tornou tudo possível

O coração do handshake é o problema de duas partes combinarem uma chave secreta através de um canal que pode estar sendo espionado. A resposta veio de Whitfield Diffie e Martin Hellman (1976), no artigo seminal "New Directions in Cryptography", que introduziu a troca de chaves que leva seus nomes. O Diffie-Hellman permite que cliente e servidor cheguem, cada um por seu lado, a um mesmo segredo compartilhado sem nunca transmiti-lo pela rede — um observador que vê toda a conversa ainda assim não consegue deduzir a chave.

Esse insight, com quase cinquenta anos, é o que sustenta a privacidade da web até hoje. As versões modernas do TLS usam variações de Diffie-Hellman para garantir, inclusive, forward secrecy: mesmo que a chave privada do servidor vaze no futuro, as sessões antigas permanecem protegidas.

Forward secrecy explicada

Forward secrecy (ou perfect forward secrecy) merece um parágrafo próprio porque é uma das propriedades mais valiosas do TLS moderno. A ideia é simples: cada sessão usa uma chave temporária, gerada na hora e descartada depois. Mesmo que um atacante grave todo o seu tráfego cifrado hoje e, anos depois, roube a chave privada do servidor, ele ainda não conseguirá decifrar as conversas antigas — porque as chaves de sessão daquele tráfego foram destruídas e nunca derivaram diretamente da chave privada de longo prazo. Sem forward secrecy, roubar a chave privada do servidor permitiria decifrar retroativamente todo o histórico capturado. É por isso que o TLS 1.3 tornou a forward secrecy obrigatória.

O handshake passo a passo

O handshake é a negociação inicial que estabelece a conexão segura. No TLS 1.3, definido por Eric Rescorla (2018) na RFC 8446, esse processo foi enxugado para apenas uma ida e volta (1-RTT), tornando-o mais rápido e mais seguro que nas versões anteriores. De forma simplificada:

Cliente                                  Servidor
   | ---------- ClientHello ------------>  |
   | <--- ServerHello + Certificado -----  |
   |        (cálculo do segredo)           |
   | <======= túnel cifrado ============>  |

O resultado é que, em uma fração de segundo, as duas pontas passam de uma conexão aberta para um canal cifrado e autenticado.

Por que o TLS 1.3 é mais rápido

Nas versões anteriores (TLS 1.2 e antes), o handshake exigia duas idas e voltas completas antes de qualquer dado útil trafegar. Em redes com latência alta — uma conexão móvel, por exemplo — esse atraso era perceptível. O TLS 1.3 cortou isso pela metade, para 1-RTT, ao reorganizar a negociação: o cliente já manda no ClientHello os palpites de parâmetros, e na maioria dos casos o servidor consegue aceitar de imediato. Existe ainda o modo 0-RTT, que permite enviar dados já na primeira mensagem em reconexões — ganho de velocidade considerável, embora com ressalvas de segurança (vulnerabilidade a replay) que exigem cuidado.

Certificados: provando quem você é

A troca de chaves protege contra espionagem, mas não basta. E se o servidor com quem você combinou a chave for um impostor? É aí que entram os certificados digitais.

Um certificado TLS é um documento que associa uma identidade (um domínio, como exemplo.com) a uma chave pública, e é assinado por uma Autoridade Certificadora (CA) em quem o navegador confia. Quando o servidor apresenta seu certificado, o navegador verifica:

Se qualquer verificação falhar, o navegador exibe aquele aviso vermelho de "conexão não segura". A confiança, no fim, repousa em um conjunto de CAs que vêm pré-instaladas no sistema e nos navegadores.

A cadeia de confiança

Na prática, o certificado do seu site raramente é assinado diretamente pela CA raiz. Existe uma cadeia: a CA raiz (cuja chave está pré-instalada no sistema operacional e nos navegadores) assina certificados intermediários, e esses intermediários é que assinam o certificado do seu domínio. O navegador percorre essa cadeia para cima até encontrar uma raiz em que confia. Um erro comum em produção é o servidor não enviar os certificados intermediários junto com o seu — alguns clientes conseguem completar a cadeia sozinhos, outros não, e o resultado é um erro de confiança intermitente e difícil de diagnosticar.

Tipos de validação

Nem todo certificado prova a mesma coisa. Há três níveis de validação:

Para a esmagadora maioria dos sites, um certificado DV gratuito e renovado automaticamente é suficiente — ele oferece exatamente a mesma criptografia que um certificado caro. A diferença está só no nível de verificação de identidade, não na força da proteção.

O que isso significa para o desenvolvedor

Você raramente vai implementar TLS na mão, mas as decisões em torno dele aparecem o tempo todo:

Em APIs, o TLS é a primeira linha de defesa, mas não a única. Garantir a segurança de APIs e proteger seus endpoints significa somar ao TLS controles de autenticação, autorização e validação — o túnel cifrado protege os dados em trânsito, mas não substitui as verificações que acontecem quando a requisição chega.

Terminação de TLS e o problema do "último salto"

A terminação de TLS é onde o túnel cifrado "termina" e o tráfego volta a ser texto claro. Em arquiteturas reais, isso costuma acontecer no balanceador de carga ou em um proxy reverso na borda. O perigo está no que vem depois: se entre o proxy e os seus serviços internos o tráfego trafega sem criptografia, um atacante que comprometa a rede interna lê tudo. A boa prática moderna, especialmente em ambientes com múltiplos serviços, é cifrar também o tráfego interno (modelo zero trust), em vez de assumir que a rede interna é confiável por natureza.

O papel do HSTS

Forçar HTTPS com um redirecionamento de HTTP para HTTPS resolve o caso comum, mas deixa uma brecha: a primeira requisição ainda sai em HTTP claro e pode ser interceptada e desviada (ataque de downgrade). O cabeçalho HSTS (Strict-Transport-Security) fecha essa brecha instruindo o navegador a nunca usar HTTP para aquele domínio por um período definido. Depois da primeira visita bem-sucedida, o navegador já força HTTPS sozinho, sem nem tentar o HTTP. É um cabeçalho de uma linha que elimina toda uma classe de ataque.

Erros comuns em produção

Alguns problemas com TLS aparecem com tanta frequência que vale enumerá-los:

Perguntas frequentes

TLS e SSL são a mesma coisa? Tecnicamente não. SSL é o protocolo antigo e obsoleto; TLS é o sucessor. Mas no uso cotidiano, "certificado SSL" virou sinônimo de certificado TLS.

O cadeado garante que o site é confiável? Não. O cadeado garante que a conexão é cifrada e que você está falando com o dono daquele domínio — não que o dono é honesto. Um site de phishing pode ter cadeado.

Preciso pagar por um certificado? Para a maioria dos casos, não. Certificados DV gratuitos oferecem a mesma criptografia que os pagos. Você só paga por níveis mais altos de validação de identidade.

TLS deixa o site mais lento? O custo do handshake é mínimo e, com TLS 1.3 e HTTP/2, sites em HTTPS muitas vezes ficam mais rápidos do que em HTTP antigo, por causa de recursos que só funcionam sobre conexão segura.

Onde devo terminar o TLS? Depende da arquitetura. Terminar na borda (proxy/load balancer) é comum, mas garanta que o tráfego do último salto até seus serviços também esteja protegido.

Conclusão

TLS é a tecnologia invisível que torna a web segura: combina criptografia assimétrica para autenticar e combinar chaves, simétrica para cifrar o tráfego com eficiência, e certificados para garantir que você fala com quem pensa que fala. No centro de tudo está uma ideia de 1976 — a troca de chaves de Diffie-Hellman — que permite combinar um segredo mesmo sob observação, e que hoje, com forward secrecy, protege até as conversas do passado. Para o desenvolvedor, o trabalho não é reinventar o protocolo, mas configurá-lo corretamente: versões modernas, certificados válidos, cadeia completa e HTTPS obrigatório com HSTS. Faça isso, e o cadeado deixa de ser um detalhe da barra de endereço para virar uma garantia real para os seus usuários.

Referências