Origens: o problema do carrinho de compras

Em 1994, a Netscape precisava que as pessoas digitassem o número do cartão no navegador, e a web não tinha confidencialidade nenhuma. O SSL 1.0 nunca chegou a ser lançado; o SSL 2.0 saiu em 1995 com falhas tão graves que, um ano depois, o SSL 3.0 tomou o lugar dele, como um protocolo redesenhado, e não como uma correção.

Com a padronização, o protocolo saiu das mãos de uma empresa e foi para o , e a numeração de versão recomeçou, para não parecer produto de um fabricante: o TLS 1.0 ( 2246, 1999) se identifica nos pacotes como SSL 3.1. Essa herança importa porque continua visível nos números de versão que trafegam na rede: um registro TLS 1.2 anuncia 0x0303, que corresponde ao SSL 3.3 na numeração original.

Cada geração que veio depois tirou alguma coisa, em vez de acrescentar:

  • TLS 1.0 (1999) e TLS 1.1 (RFC 4346, 2006): a segunda versão passou a usar vetores de inicialização explícitos, depois dos ataques contra os implícitos. Hoje, na prática, as duas estão proibidas.
  • TLS 1.2 (RFC 5246, 2008): trouxe a criptografia autenticada e o e eliminou a construção fixa que combinava e SHA-1. Foi a versão que sustentou a web por uma década.
  • TLS 1.3 (RFC 8446, 2018): levou cinco anos e uns trinta drafts, porque o objetivo do projeto era tirar coisas: saíram a renegociação, a compressão, a troca de chaves com estático e toda cipher suite (suíte de cifra) sem criptografia autenticada. A maioria dos ataques históricos ao TLS explora opções que o 1.3 simplesmente não tem.
  • 1.2 (RFC 6347) e DTLS 1.3 (RFC 9147): o mesmo handshake (o aperto de mão que abre a sessão), adaptado para o transporte por datagramas.
  • QUIC (RFC 9000, com a integração do TLS na RFC 9001, 2021): o handshake passou para dentro de um protocolo de transporte novo.

Vale a pena dar nome aos ataques que levaram a essas remoções, porque cada um deles derrubou um recurso: e contra o modo das versões antigas, e contra a compressão, contra o padding (preenchimento) do SSL 3.0, contra uma implementação, e não contra o protocolo, e e contra a criptografia de exportação (export-grade), que continuou habilitada por uma década depois de deixar de ser exigida por lei.

Uma família, quatro formatos

TLS é a sigla de Transport Layer Security, segurança da camada de transporte: é o protocolo que dá a dois endpoints (as duas pontas da comunicação) um canal criptografado e autenticado e que, de quebra, prova ao cliente quem é o servidor. Quase tudo o que se chama de "seguro" na internet é uma aplicação rodando sobre algum membro dessa família: o HTTPS, o envio seguro de e-mail, o (Lightweight Directory Access Protocol) sobre TLS, conhecido como , e a maioria dos canais de controle de (rede privada virtual). Os quatro nomes do título não são quatro invenções concorrentes. São um mesmo projeto adaptado a quatro situações: o TLS 1.2 e o TLS 1.3 protegem um fluxo de bytes confiável sobre TCP (Transmission Control Protocol); o DTLS oferece as mesmas garantias sobre datagramas não confiáveis; e o QUIC é um protocolo de transporte completo, que incorporou o handshake inteiro do TLS 1.3 e fez dele o jeito de o próprio transporte obter as suas chaves.

Cada um é definido numa RFC, sigla de Request for Comments: a série numerada de documentos em que o IETF (Internet Engineering Task Force) publica os padrões da internet. Saber qual RFC está em vigor faz diferença, porque duas dessas especificações foram substituídas ou revisadas há pouco tempo, em 2022 e em 2025.

TLS 1.2: o veterano que sustentou a web

O TLS 1.2 foi publicado em agosto de 2008, na RFC 5246. O handshake dele leva duas idas e voltas (round trips; o RTT, de round-trip time, é o tempo de uma mensagem sair e a resposta voltar) antes que os dados da aplicação possam passar, e o nome de cada cipher suite junta quatro decisões numa única string: a troca de chaves, a autenticação, a cifra dos dados e o MAC (message authentication code, o código de autenticação de mensagem). É essa anatomia que o artigo Anatomia de uma suíte de cifra TLS desmonta peça por peça.

Essa flexibilidade também é o ponto fraco dele. O TLS 1.2 permite a troca de chaves com RSA estático, em que o cliente criptografa o segredo da sessão com a chave de longo prazo do servidor; assim, quem conseguir essa chave mais tarde consegue descriptografar o tráfego que gravou, o contrário de forward secrecy (sigilo futuro). Ele também permite cifras antigas no modo CBC (Cipher Block Chaining), cujo tratamento do padding deu origem a uma família inteira de ataques, e recursos legados como a renegociação e a compressão, cada um com os seus próprios CVEs. Um TLS 1.2 bem configurado evita tudo isso e continua defensável hoje, e é exatamente por isso que o protocolo durou tanto: tudo o que ele tem de perigoso é opcional.

TLS 1.3: menos opções, padrões melhores

O TLS 1.3 chegou uma década depois, em agosto de 2018, na RFC 8446. Em dezembro de 2025, o IETF publicou uma edição revisada da mesma versão do protocolo, a RFC 9846, que agora torna obsoleta a RFC 8446 (e, de quebra, a RFC 5246). A versão que trafega na rede continua sendo a 1.3; o texto em vigor é o da 9846.

As mudanças em relação ao 1.2 são mais cortes do que acréscimos. O handshake cai para uma ida e volta, e tudo o que vem depois do ServerHello já vai criptografado, então os certificados não atravessam mais a rede em texto claro. A troca de chaves com RSA estático acabou: todo handshake TLS 1.3 usa uma troca efêmera (de curva elíptica), então forward secrecy deixou de ser uma opção de configuração e virou uma propriedade do protocolo. Só sobraram as cifras (authenticated encryption with associated data, criptografia autenticada com dados associados, em que criptografar e garantir a integridade são uma operação só), o que eliminou de uma vez toda a classe de problemas do padding no CBC. A lista de cipher suites encolheu de centenas de combinações para cinco, porque agora a suite nomeia apenas a cifra AEAD e o hash do handshake; o artigo Suítes de cifra do TLS 1.3: o que mudou detalha essa redução. O TLS 1.3 também traz a retomada 0-RTT, que deixa um cliente que já conhece o servidor enviar dados logo no primeiro pacote, com uma ressalva documentada: os dados 0-RTT podem ser reenviados por um atacante (replay), por isso ficam reservados para requisições que podem ser repetidas sem risco.

DTLS: as mesmas garantias, sem um fluxo ordenado por baixo

DTLS é a sigla de Datagram Transport Layer Security, o TLS para datagramas, e ele existe porque o TLS conta, sem dizer, com uma coisa que o UDP (User Datagram Protocol) não oferece: um fluxo confiável e ordenado. Os registros do TLS dependem da ordem (se um registro se perde, o estado de descriptografia de tudo o que vem depois fica errado), e o handshake do TLS simplesmente supõe que as mensagens chegam. Coloque o TLS direto sobre UDP e um único pacote perdido trava a conexão.

O DTLS é o TLS com essa suposição retirada de forma cirúrgica. Os registros levam números explícitos de época (epoch) e de sequência, para que cada datagrama possa ser descriptografado de forma independente e para que duplicatas e pacotes fora de ordem sejam tolerados; o handshake ganha os seus próprios timers de retransmissão e a sua própria fragmentação, já que não há TCP por baixo para cuidar disso; e uma troca de cookie sem estado (stateless) permite que o servidor confirme o endereço do cliente antes de ter qualquer trabalho de verdade, o que tira a força dos ataques de amplificação com origem forjada. O DTLS 1.2 é a RFC 6347 (janeiro de 2012), e o DTLS 1.3, que acompanha o redesenho do TLS 1.3, é a RFC 9147 (abril de 2022). O DTLS aparece onde tráfego em tempo real ou sem conexão precisa de uma proteção do nível do TLS: o WebRTC usa um handshake DTLS para gerar as chaves dos seus fluxos de mídia, vários canais de dados de VPN rodam sobre ele para fugir dos travamentos de TCP sobre TCP, e protocolos de IoT para dispositivos com poucos recursos, como o CoAP, usam o DTLS para se proteger.

QUIC: o handshake dentro do transporte

O QUIC nasceu no Google por volta de 2012, onde o nome foi explicado depois como sigla de "Quick UDP Internet Connections" (um backronym); o padrão do IETF, a RFC 9000 (maio de 2021), diz com todas as letras que QUIC é só um nome, não uma sigla. Seja como for, o QUIC é a maior mudança estrutural dessa família, porque ele não é uma camada de segurança colocada sobre um transporte: ele é o próprio transporte.

O QUIC roda sobre UDP e entrega sozinho o que antes a pilha TCP mais TLS entregava: confiabilidade, controle de congestionamento e criptografia. Ele leva muitos streams (fluxos) independentes dentro de uma mesma conexão e, como a recuperação de perdas é feita por stream, um pacote perdido só trava o stream a que pertencia. Com isso acaba o head-of-line blocking (o bloqueio de cabeça de fila: um segmento perdido segurando todos os bytes que vêm atrás dele) que o TCP impõe, no nível do transporte, a tudo o que roda por cima. O handshake do QUIC é o handshake do TLS 1.3, embutido por meio da RFC 9001 de forma que as chaves negociadas pelo TLS protejam os pacotes do próprio transporte; a preparação do transporte e a da criptografia terminam juntas, em uma ida e volta, com 0-RTT disponível na retomada. Quase o pacote inteiro vai criptografado, inclusive os headers (cabeçalhos), e as conexões são identificadas por connection IDs, e não pela quádrupla de endereços e portas, então um celular pode passar do para a rede celular sem que a conexão caia. O uso mais visível do QUIC é o , que é exatamente o HTTP mapeado sobre streams QUIC, o último capítulo de HTTP/0.9 a HTTP/3.

Os handshakes lado a lado

O TLS 1.2 custa duas idas e voltas antes dos dados da aplicação. O cliente oferece as cipher suites; o servidor escolhe uma e manda o certificado; as chaves são trocadas; os dois lados confirmam. A negociação é ampla, e foi daí que vieram os problemas: um ataque de downgrade (rebaixamento) é possível sempre que a opção mais fraca oferecida ainda for aceita.

O TLS 1.3 custa uma ida e volta, porque o cliente tenta adivinhar o grupo da troca de chaves e já manda a sua parte (o key share) logo de cara. Se errar, o servidor pede de novo, uma vez, com um HelloRetryRequest. São cinco suites AEAD, e não dezenas de combinações; a troca de chaves é efêmera por construção, então forward secrecy não é opcional; e a maior parte do handshake depois do ServerHello vai criptografada, então muito menos coisa fica visível na rede, inclusive o certificado.

O 0-RTT permite que um cliente que está voltando mande dados já na primeira leva de mensagens, com um custo assumido: esses primeiros bytes podem ser reenviados (replay), então só são seguros para requisições idempotentes. Esse custo está escrito no próprio padrão, e não escondido.

O DTLS mantém o mesmo projeto sobre UDP e acrescenta o que o datagrama não tem: números de sequência explícitos, retransmissão das levas de mensagens do handshake e uma troca de cookie sem estado, para que o servidor não reserve estado para um endereço de origem forjado. É o mesmo raciocínio contra amplificação de qualquer defesa contra reflexão. É o DTLS que protege a mídia do WebRTC e boa parte do mundo dos dispositivos com recursos limitados.

O QUIC junta o handshake do transporte e o da criptografia numa troca só, sobre UDP, então uma conexão chega aos dados da aplicação em uma ida e volta e, ao se reconectar a um servidor conhecido, em zero. Além disso, ele criptografa a própria camada de transporte, inclusive os números de sequência e as confirmações, elimina o head-of-line blocking entre streams e torna estruturalmente mais difícil a interferência de middleboxes (os equipamentos no meio do caminho). Como usa identificadores de conexão, e não tuplas de endereços, a sessão sobrevive a uma troca de rede.

O que isso muda na operação

Visibilidade. O TLS 1.3 criptografa o certificado e a maior parte das extensões do handshake, então a inspeção passiva enxerga bem menos; o no ClientHello inicial continua sendo o principal sinal em texto claro, e o Encrypted Client Hello acaba até com isso onde já foi implantado. Arquiteturas de inspeção que dependem de ler os handshakes precisam ser repensadas, e não apenas reconfiguradas.

Middleboxes. Tanto equipamento tratava mal os handshakes que não conhecia que o TLS 1.3, de propósito, se apresenta na rede como uma retomada de sessão do TLS 1.2. Esse modo de compatibilidade é um monumento permanente ao software instalado por aí que inspeciona o que não entende.

O QUIC na rede. É UDP na porta 443, opaco para a inspeção, e tantas redes o bloqueiam ou limitam que os navegadores mantêm um fallback para TCP. O planejamento de capacidade também muda: o processamento por pacote custa mais do que no TCP para a mesma vazão, e o trabalho passa para o espaço de usuário (userspace).

O que conferir na prática. Desligue o TLS 1.0 e o 1.1 e todas as suites sem AEAD; exija no mínimo o TLS 1.2 e prefira o 1.3; mantenha a automação de certificados independente da questão da versão; e verifique o que a sua própria pilha de inspeção faz com um fluxo TLS 1.3 ou QUIC antes que um incidente torne essa resposta urgente.

Implementações, por categoria

  • OpenSSL: a biblioteca padrão em quase todo lugar, com a maior cobertura de algoritmos e o histórico mais longo, tanto de uso quanto de escrutínio.
  • BoringSSL e LibreSSL: forks deliberados, com superfície menor; a BoringSSL está por baixo do Chrome e de boa parte da infraestrutura do Google, e a LibreSSL nasceu no OpenBSD depois do Heartbleed.
  • Pilhas das plataformas: Schannel no Windows, Secure Transport e os seus sucessores nos sistemas da Apple, NSS no Firefox. O comportamento segue a política do sistema operacional, não a da aplicação.
  • Implementações memory-safe (com segurança de memória): rustls e similares, cada vez mais usadas onde a classe histórica de bugs pesa mais do que a amplitude do suporte a legado.
  • Bibliotecas QUIC: quiche, msquic, ngtcp2, quic-go e outras, além das pilhas embutidas nos navegadores e nas redes de entrega de conteúdo; é um espaço mais novo e menos consolidado que o do TLS.

A interoperabilidade em geral é boa, porque os padrões são precisos e a superfície de teste é enorme. O atrito está na política, não no protocolo: um sistema operacional que não oferece TLS 1.3, um middlebox que estraga o handshake, ou uma rede de entrega que termina a conexão e abre outra, para a origem, com algo mais antigo.

Qual deles aparece na captura?

Uma orientação rápida para capturas e configurações. Um navegador abrindo uma página fala TLS 1.3 (ou 1.2) sobre TCP na porta 443, ou HTTP/3 sobre QUIC em UDP 443, e muitas vezes as duas coisas com o mesmo site, com o QUIC anunciado e tentado depois de uma primeira visita por TCP. Uma chamada de vídeo no navegador gera as chaves da mídia com DTLS. Um load balancer (balanceador de carga) de datacenter que termina "SSL" está, quase sempre, terminando TLS 1.2 e 1.3 sobre TCP. E uma captura cheia de UDP 443 criptografado, em que você não consegue ler nem a maior parte dos headers dos pacotes, é o QUIC funcionando como foi projetado: a resistência dele à inspeção por middleboxes é uma característica do protocolo, e não um acidente do seu filtro de captura.

Veja os bytes de uma conexão real

O jeito mais rápido de deixar os quatro concretos é ler uma conexão real anotada, byte a byte. A série Illustrated, de Michael Driscoll, faz exatamente isso, uma página por protocolo: The Illustrated TLS 1.2 Connection, The Illustrated TLS 1.3 Connection, The Illustrated DTLS Connection e The Illustrated QUIC Connection. Cada registro de um handshake real aparece com todos os campos explicados, a companhia ideal para a leitura das próprias especificações.

Esta série, em ordem

Este artigo abre a série TLS e as cipher suites. Ele mapeia os quatro formatos que o handshake tem hoje; as partes seguintes aprofundam cada pedaço, nesta ordem: o nome que todo mundo ainda usa, a troca de chaves e o sigilo que ela garante, a cipher suite lida peça por peça e família por família, o veredito de configuração, os ataques com nome próprio que moldaram o protocolo e os dois pontos em que um proxy entra na sessão.

  1. Por que dizemos SSL quando queremos dizer TLS?. O SSL da Netscape, a mudança de nome para TLS em 1999 e por que o mercado ainda vende certificados SSL.
  2. Diffie-Hellman explicado sem matemática. Dois desconhecidos combinam um segredo numa sala em que todo mundo escuta: a troca de chaves, sem a matemática.
  3. Forward secrecy e a troca de chaves. O que a forward secrecy garante, por que o transporte de chave com RSA estático não oferece essa garantia e como o e o oferecem.
  4. Anatomia de uma suíte de cifra TLS. O que uma cipher suite nomeia, lida peça por peça, e o code point de dois bytes por trás de cada nome.
  5. Como ler nomes de suítes de cifra: IANA, OpenSSL e GnuTLS. A mesma suite com os nomes da , do OpenSSL e do GnuTLS, e o que significa a coluna Recommended.
  6. Famílias de cifras: o mapa de trabalho. Bloco e fluxo, e ChaCha20, RSA, curvas elípticas e (EC)DHE: as famílias com que uma suite é montada.
  7. AEAD vs CBC: por que o modo de operação faz diferença. O AES- contra o CBC com separado, os padding oracles que acabaram com o MAC-then-encrypt e a contrapartida que o AEAD mantém.
  8. Suítes de cifra do TLS 1.3: o que mudou. Por que uma suite do TLS 1.3 nomeia apenas uma cifra e um hash, e para onde foram a troca de chaves e a autenticação.
  9. Quais palavras-chave de cifra TLS são seguras e quais não são. A lista curta de palavras-chave que decide se uma cipher string é endurecida (hardened) ou perigosa.
  10. Quais suítes de cifras usar: o livro-razão de veredictos. O veredito, nível por nível: o que usar hoje, o que sobrevive em nichos e o que é proibido, e por qual RFC.
  11. Os ataques nomeados ao TLS, 2011-2023: o que cada um quebrou, e o que o protocolo removeu por causa dele. Do BEAST ao : o que cada ataque com nome próprio quebrou entre 2011 e 2023 e o que o protocolo removeu por causa dele.
  12. TLS de entrada: offload, bridging e passthrough no reverse proxy. Offload, bridging e passthrough: as três maneiras de um reverse proxy tratar uma sessão de entrada, e o que cada uma sacrifica.
  13. SSL forward proxy: como funciona a interceptação de TLS de saída e o que a faz falhar. O controlado da inspeção de saída: o certificado forjado, a privada e o que quebra a interceptação.