# Os ataques nomeados ao TLS, 2011-2023: o que cada um quebrou, e o que o protocolo removeu por causa dele > BEAST, CRIME, Lucky13, Heartbleed, POODLE, FREAK, Logjam, DROWN, SWEET32, SLOTH, ROBOT, ROCA, Raccoon, ALPACA, Terrapin. Quatorze nomes, doze anos, um padrão: cada ataque achou uma funcionalidade que o protocolo nunca deveria ter mantido, e o TLS 1.3 é a lista do que foi retirado. Este é o guia para ler um relatório de cipher suites como história. Source: https://ronutz.com/pt-BR/learn/the-named-tls-attacks Updated: 2026-09-07 --- ## Por que os nomes existem Até mais ou menos 2011, um ataque ao TLS (Transport Layer Security), o protocolo debaixo do HTTPS (Hypertext Transfer Protocol Secure), era um artigo com um número. Depois de 2011 virou um logotipo, um site e um nome que cabe num slide de conferência, e a prática foi ridicularizada por isso. A zombaria erra o ponto. Um nome é como um operador que não é criptógrafo consegue perguntar se um balanceador de carga está exposto a uma coisa, e as ferramentas deste site que checam cipher suites e certificados reportam seus achados exatamente sob esses nomes. Este artigo é o que está por trás de cada um: o que quebrou, quem achou, e o que o protocolo removeu em resposta. Lidos juntos, eles são a razão de o TLS 1.3 ter a cara que tem. Toda funcionalidade que ele descartou está nesta lista. ## 2011-2014: os anos da cifra de bloco **BEAST**, setembro de 2011. Juliano Rizzo e Thai Duong demonstraram na conferência Ekoparty, em Buenos Aires - o mesmo circuito latino-americano que o [artigo sobre conferências](https://ronutz.com/pt-BR/learn/latin-american-security-conferences) descreve - que uma fraqueza do modo CBC (cipher block chaining), conhecida na teoria havia anos e tida como impraticável, podia ser usada a partir de um navegador. No SSL (Secure Sockets Layer) 3.0 e no TLS 1.0, o IV (vetor de inicialização) de cada registro era o último bloco de texto cifrado do registro anterior, de modo que um atacante capaz de injetar texto claro escolhido numa sessão podia adivinhar um byte de cada vez. O conserto já existia: o TLS 1.1 usava IVs explícitos desde 2006, e ninguém o tinha implantado. Os navegadores contornaram a falha dividindo registros, e por um tempo a mitigação recomendada foi preferir o RC4 - que é a origem do problema seguinte. **CRIME**, setembro de 2012, pelos mesmos dois pesquisadores na mesma conferência: se o TLS comprime os dados antes de cifrá-los, o tamanho do texto cifrado vaza se um palpite bateu com o segredo na requisição, e um cookie de sessão pode ser recuperado um caractere por vez. A compressão do TLS foi desligada em todo lugar em meses. O **BREACH**, em 2013, fez a mesma observação sobre a compressão HTTP do corpo da resposta, que não podia simplesmente ser desligada, e continua sendo uma restrição de projeto para qualquer página que reflita entrada do usuário ao lado de um segredo. **Lucky Thirteen**, fevereiro de 2013. Nadhem AlFardan e Kenny Paterson, da Royal Holloway, mostraram que a ordem de operações do TLS - autenticar o texto claro, preencher, depois cifrar - permitia que o tempo de resposta do servidor revelasse se o preenchimento era válido, e que um oráculo de preenchimento decifra. O conserto nas implementações foi código de tempo constante, notoriamente difícil de escrever; o conserto no protocolo foi parar de usar CBC. No mesmo ano, novos ataques ao RC4 mostraram que a alternativa ao BEAST era pior que a doença, e o RC4 começou o processo de dois anos até ser removido. **Heartbleed**, abril de 2014, é o diferente da turma: não uma falha de projeto, mas um bug, o CVE-2014-0160 na implementação da extensão heartbeat do OpenSSL, que deixava qualquer um ler até 64 quilobytes da memória de um servidor por requisição, sem limite de repetição e sem rastro nos logs. Chaves, senhas e cookies de sessão estavam nessa memória. É a razão de existir a prática de rotacionar certificados depois de um incidente, e está nesta lista porque um relatório que diz "Heartbleed" significa um servidor que nunca foi corrigido, o que é um achado sobre o operador e não sobre o protocolo. **POODLE**, outubro de 2014. Bodo Möller, Thai Duong e Krzysztof Kotowicz, do Google, combinaram uma falha de preenchimento específica do SSL 3.0 com um rebaixamento: um atacante no meio quebra o handshake TLS até o cliente cair para o SSL 3.0, e então recupera cookies pelo oráculo de preenchimento. O SSL 3.0 tinha dezoito anos e sobrevivia só por compatibilidade. O POODLE acabou com ele - a Internet Engineering Task Force o descontinuou formalmente na RFC 7568 no ano seguinte - e produziu o sinal TLS_FALLBACK_SCSV (RFC 7507) para que um cliente ao rebaixar pudesse dizer ao servidor que o estava fazendo. ## 2015-2016: os anos das cifras de exportação O grupo seguinte tem uma única causa, e o [artigo da EFF](https://ronutz.com/pt-BR/learn/electronic-frontier-foundation) a explica: nos anos 1990 os Estados Unidos limitaram a criptografia exportada a chaves quebráveis, e o protocolo manteve cipher suites "de exportação" para negociá-las. Vinte anos depois elas ainda estavam lá. **FREAK**, março de 2015 (CVE-2015-0204): um atacante no meio podia fazer um servidor que ainda suportasse troca de chaves RSA (Rivest-Shamir-Adleman) de exportação usar uma chave de 512 bits, e RSA de 512 bits era fatorável havia anos. **Logjam**, maio de 2015 (CVE-2015-4000): o mesmo truque com a troca de chaves Diffie-Hellman (DH), rebaixando para grupos de 512 bits - com a descoberta adicional de que, como a maioria dos servidores usava os mesmos poucos grupos padrão, um adversário bem financiado que pré-computasse contra um grupo de 1024 bits poderia ler uma fração grande do tráfego DH da internet. Essa descoberta é geralmente lida como a explicação de como uma agência estatal podia fazer o que os documentos de Snowden descreviam. **DROWN**, março de 2016 (CVE-2016-0800): um servidor que ainda respondesse SSL 2.0 - um protocolo de 1995 que ninguém usava - podia servir de oráculo para decifrar sessões TLS de qualquer outro servidor que compartilhasse o mesmo certificado, inclusive os modernos. A lição é a que a lista inteira não para de ensinar: um protocolo velho deixado ligado numa porta é um buraco no protocolo novo em outra. **SWEET32**, agosto de 2016 (CVE-2016-2183): cifras com bloco de 64 bits, Triple DES e Blowfish entre elas, vazam depois de dados suficientes por causa do limite de aniversário - uns 32 gigabytes numa conexão bastavam para recuperar algo. O Triple DES sobrevivera pela força do nome; é a cifra que o [quebrador de DES](https://ronutz.com/pt-BR/learn/electronic-frontier-foundation) da EFF tornara necessária em 1998, e em 2016 ele mesmo era um achado. **SLOTH**, no mesmo ano, de Karthikeyan Bhargavan e Gaëtan Leurent, do INRIA: o TLS 1.2 ainda permitia MD5 para assinaturas do handshake, e um ataque de colisão sobre a transcrição do handshake podia quebrar a autenticação. O MD5 era considerado quebrado desde 2004; o protocolo o mantivera por mais doze anos. ## 2017-2020: o retorno dos ataques antigos **ROBOT**, dezembro de 2017. Em 1998 Daniel Bleichenbacher mostrara que as mensagens de erro diferentes de um servidor para textos cifrados RSA mal preenchidos formavam um oráculo que deixava um atacante decifrar com a chave privada do servidor, e contramedidas estavam especificadas havia dezenove anos. Hanno Böck, Juraj Somorovsky e Craig Young fizeram a primeira varredura em larga escala pelo oráculo e o encontraram ainda presente em quase um terço dos cem maiores domínios, e em produtos de nove fabricantes - entre eles F5, Citrix, Radware, Palo Alto Networks, Cisco e IBM. Assinaram uma mensagem com a chave privada do certificado do Facebook para provar o ponto. Para quem lê este site o registro relevante é o da própria F5: K21905460, CVE-2017-6168, afetando BIG-IP 11.6.0 a 11.6.2, 12.0.0 a 12.1.2 HF1 e 13.0.0 a 13.0.0 HF2, um servidor virtual com perfil Client SSL exposto à recuperação de texto claro. O conserto foi um hotfix; a lição foi que a troca de chaves RSA - ao contrário das assinaturas RSA - não podia ser tornada segura, e o TLS 1.3 a removeu. **ROCA**, outubro de 2017 (CVE-2017-15361), não é um ataque ao TLS, mas pertence aos outros porque é o que um relatório de cipher suites não consegue ver. Matúš Nemec, Marek Sýs e colegas da Universidade Masaryk descobriram que a biblioteca de geração de chaves RSA da Infineon produzia primos com uma estrutura que tornava chaves de 1024 e 2048 bits fatoráveis a partir só da chave pública - sem nenhum acesso ao dispositivo. A biblioteca estava em smart cards, tokens de segurança e TPMs (trusted platform modules) certificados FIPS 140-2 e Common Criteria EAL5+ desde 2012; a Estônia teve de suspender 750 mil carteiras de identidade nacionais semanas antes de uma eleição que as usava para votar. A avaliação de Daniel Bernstein na época foi que as chaves eram visivelmente não aleatórias desde um artigo de 2016 e que atacantes sérios provavelmente tinham achado a falha anos antes. Um certificado pode estar perfeitamente configurado e apoiar-se numa chave que nasceu quebrada. **Raccoon**, setembro de 2020 (CVE-2020-1968), de Robert Merget, Marcus Brinkmann e colegas: o TLS 1.2 e anteriores removem os bytes zero à esquerda de um segredo compartilhado Diffie-Hellman antes de derivar chaves, o que faz a derivação levar um tempo mensuravelmente diferente, o que vaza os bits mais significativos do segredo, o que pode ser montado no segredo inteiro quando um servidor reutiliza sua parte DH. Os pesquisadores rastrearam a remoção dos zeros até um relatório de bug antigo: os implementadores tinham lido errado a especificação do SSL 3, e quando o TLS 1.0 foi escrito o erro foi mantido de propósito, para evitar confusão. Uma leitura errada de vinte anos, explorável só contra servidores com DH estático ou reutilizando chaves efêmeras, e por isso classificada como difícil de explorar - e por isso o conserto foi parar de reutilizar chaves. ## 2021-2023: as bordas do protocolo **ALPACA**, junho de 2021 (CVE-2021-3618), dos grupos de Bochum, Münster e Paderborn: o TLS autentica o nome de um servidor, não o protocolo de aplicação atrás dele. Onde um certificado curinga ou multidomínio serve HTTPS num host e FTP ou SMTP em outro, um atacante no meio pode redirecionar a conexão TLS de um navegador para o servidor de correio ou de arquivos, que apresenta um certificado válido e então obedece, no próprio protocolo, ao texto do atacante embutido na requisição - vazando cookies ou refletindo script. A primeira versão do truque fora descrita duas décadas antes; o ALPACA a tornou geral. O remédio é a extensão de negociação de protocolo de aplicação e a disciplina, relevante a quem usa as [ferramentas de certificado](https://ronutz.com/pt-BR/learn/certificate-validation) deste site, de não compartilhar um certificado entre serviços que falam protocolos diferentes. **Terrapin**, dezembro de 2023 (CVE-2023-48795), é o que não é TLS de jeito nenhum. Fabian Bäumer, Marcus Brinkmann e Jörg Schwenk mostraram que o protocolo de pacotes binários do SSH (Secure Shell) deixara de ser um canal seguro à medida que novos modos de cifragem foram acrescentados: com ChaCha20-Poly1305, ou qualquer modo encrypt-then-MAC, um atacante no meio podia manipular números de sequência para apagar mensagens do início do canal sem que nenhum dos lados notasse, e usar isso para remover a negociação de extensões que protege contra rebaixamento - desligando, por exemplo, a contramedida de tempo de digitação que o OpenSSH acabara de introduzir. Uma varredura em outubro de 2023 achou a maioria dos servidores SSH da internet vulnerável e uns onze milhões ainda expostos em janeiro. O conserto, a "troca de chaves estrita", só funciona quando as duas pontas o têm, o que os pesquisadores esperavam levar anos. ## O que o protocolo removeu Ponha a lista ao lado do TLS 1.3, publicado em 2018, e a correspondência é exata. O modo CBC se foi: BEAST, Lucky Thirteen, POODLE. A compressão se foi: CRIME. O RC4 se foi. A troca de chaves RSA se foi: ROBOT, e o FREAK com ele. O Diffie-Hellman estático se foi e os grupos de exportação com ele: Logjam, Raccoon. As assinaturas MD5 e SHA-1 se foram: SLOTH. A renegociação se foi. O SSL 2.0 e o 3.0 não estão só descontinuados, mas impossíveis de negociar: DROWN, POODLE. As únicas cipher suites que restam são cinco construções de cifragem autenticada com sigilo futuro, e não há caminho de rebaixamento porque o handshake é assinado de ponta a ponta. Essa é a leitura prática de um relatório de cipher suites. Um achado com o nome de um desses ataques não é uma fraqueza abstrata. É uma falha específica, datada, cuja possibilidade de configuração os projetistas do protocolo removeram, e um servidor que ainda a reporta foi configurado, por alguém, para manter uma opção que dez anos de pesquisa publicada argumentaram que não deveria existir. As ferramentas deste site nomeiam o ataque para que quem lê o relatório encontre a história - e a história, toda vez, termina com a mesma frase: o protocolo tirou aquilo de lá. ## Fontes - [NCC Group, levantamento de ataques ao SSL/TLS: CRIME demonstrado por Rizzo e Duong na Ekoparty em setembro de 2012 após notificar os fabricantes, CVE-2012-4929; BREACH como a variante de compressão de resposta; Lucky Thirteen por AlFardan e Paterson, da Royal Holloway](https://www.nccgroup.com/media/1nqor5lm/_ssl_attacks_survey.pdf) - [Gaurav Kansal, cronologia do SSL/TLS: o exploit de compressão de Duong e Rizzo fez a compressão TLS ser revertida quando os navegadores a adotavam; Lucky 13 sobre suites CBC; os ataques ao RC4 de 2013 que começaram sua remoção](https://blog.gauravkansal.in/2024/08/tlsTimeline.html) - [Microsoft, Taming the BEAST: Rizzo e Duong demonstraram o BEAST na Ekoparty no fim de setembro de 2011; a falha é o IV implícito do modo CBC no SSL 3.0 e TLS 1.0, tratada por IVs explícitos no TLS 1.1 e 1.2](https://learn.microsoft.com/tr-tr/archive/blogs/kaushal/taming-the-beast-browser-exploit-against-ssltls) - [HackerTarget: o POODLE, de Möller, Duong e Kotowicz, do Google, combina a falha de preenchimento CBC do SSL 3.0 com rebaixamento de protocolo, acabou com o SSL 3.0 e foi formalizado pela RFC 7568; o Heartbleed lia até 64 KB de memória do servidor por requisição sem rastro](https://hackertarget.com/ssl-check/) - [Secure by default, the case of TLS (arXiv): os identificadores CVE de Heartbleed (2014-0160), CRIME (2012-4929), BREACH (2013-3587), POODLE (2014-3566), SWEET32 (2016-2183), FREAK (2015-0204), DROWN (2016-0800), Logjam (2015-4000), BEAST (2011-3389), Lucky13 (2013-0169) e RC4](https://arxiv.org/pdf/1708.07569) - [robotattack.org: ROBOT por Böck, Somorovsky e Young, publicado na USENIX Security e premiado com um Pwnie; o retorno do ataque adaptativo de texto cifrado escolhido de Bleichenbacher, de 1998, sobre o preenchimento PKCS #1 v1.5](https://robotattack.org/) - [USENIX Security 2018, ROBOT: a primeira avaliação em larga escala achou a vulnerabilidade em quase um terço dos 100 maiores domínios, inclusive Facebook e PayPal, e em produtos de nove fabricantes, entre eles F5, Citrix, Radware, Palo Alto Networks, IBM e Cisco](https://www.usenix.org/conference/usenixsecurity18/presentation/bock) - [F5 DevCentral, Return of Bleichenbacher: a pilha SSL/TLS da F5 estava entre as vulneráveis; artigo de base de conhecimento K21905460 emitido em novembro de 2017](https://devcentral.f5.com/s/articles/return-of-bleichenbacher-the-robot-attack-cve-2017-6168-29119) - [Tenable, K21905460: BIG-IP 11.6.0-11.6.2, 12.0.0-12.1.2 HF1 e 13.0.0-13.0.0 HF2 com perfil Client SSL vulneráveis ao ataque adaptativo de texto cifrado escolhido, CVE-2017-6168](https://www.tenable.com/plugins/nessus/104687) - [CRoCS, Universidade Masaryk: ROCA, CVE-2017-15361, falha na geração de chaves RSA da Infineon presente em dispositivos certificados FIPS 140-2 e CC EAL5+ desde 2012, tornando chaves de 1024 e 2048 bits fatoráveis só pela chave pública](https://crocs.fi.muni.cz/public/papers/rsa_ccs17) - [Daniel Bernstein, Reconstructing ROCA: as chaves da Infineon eram visivelmente não aleatórias desde um artigo de agosto de 2016; a melhor hipótese é que atacantes sérios acharam a vulnerabilidade anos antes; as 750 mil carteiras estonianas](https://blog.cr.yp.to/20171105-infineon.html) - [Examining security certification practice (arXiv): o governo estoniano só recebeu a informação do ROCA em setembro de 2017, perto de eleições municipais que usavam as carteiras para voto eletrônico](https://arxiv.org/pdf/2311.17603) - [raccoon-attack.com: a remoção dos zeros à esquerda rastreada até uma leitura errada da especificação do SSL 3 pelos implementadores, mantida de propósito no TLS 1.0; o ataque exige servidor reutilizando sua parte Diffie-Hellman](https://raccoon-attack.com/) - [USENIX Security 2021, Raccoon: um canal lateral de tempo em todas as suites TLS-DH(E) até o TLS 1.2 vaza os bits mais significativos do segredo compartilhado porque a norma incentiva processamento em tempo não constante](https://www.usenix.org/conference/usenixsecurity21/presentation/merget) - [The Register, junho de 2021: ALPACA, de Bochum, Münster e Paderborn - o TLS não vincula uma conexão a um protocolo de aplicação, então certificados curinga e multidomínio permitem redirecionamento a um servidor FTP ou de correio; o primeiro ataque do tipo fora descrito duas décadas antes](https://www.theregister.com/2021/06/10/alpaca_tls_protection/) - [CVE-2021-3618: o ALPACA explora servidores TLS que implementam protocolos diferentes com certificados compatíveis](https://explore.alas.aws.amazon.com/CVE-2021-3618.html) - [Springer, Attacks on SSL and TLS: citações do ALPACA (Brinkmann et al., USENIX Security 2021) e dos ataques de colisão de transcrição de Bhargavan e Leurent quebrando a autenticação em TLS, IKE e SSH (NDSS 2016)](https://link.springer.com/content/pdf/10.1007/978-3-031-19439-9_12) - [terrapin-attack.com: truncamento de prefixo por manipulação de números de sequência; comunicado ao OpenSSH em outubro de 2023; a contramedida de troca de chaves estrita precisa de cliente e servidor](https://terrapin-attack.com/) - [USENIX Security 2024, Terrapin: a integridade do canal SSH quebrada para três modos de cifragem amplamente usados; o ataque remove a negociação de extensões e pode desligar a contramedida de tempo de digitação do OpenSSH 9.5](https://www.usenix.org/conference/usenixsecurity24/presentation/b%C3%A4umer) - [Wikipedia, Terrapin: CVE-2023-48795, descoberto em 19 de dezembro de 2023 por Bäumer, Brinkmann e Schwenk; a maioria das implementações SSH vulnerável na descoberta e cerca de 11 milhões de servidores ainda expostos em janeiro de 2024](https://en.wikipedia.org/wiki/Terrapin_attack)