Rustls 0.23.45 corrige falha de TLS 1.3 aberta desde 2024

O Rustls 0.23.45 saiu em 14 de setembro de 2026 com a correção de um bug de aperto de mão TLS 1.3 que estava em código publicado havia cerca de dois anos. Todas as versões de 0.23.13 a 0.23.44 são afetadas. Quem depende do Rustls deve verificar para qual versão a sua compilação realmente resolve. O Phoronix noticiou o lançamento, e o projeto registrou os detalhes como o aviso GHSA-2mjx-qc3c-rqvc.

O Rustls é uma biblioteca TLS escrita em Rust. TLS é o protocolo por trás do HTTPS, e uma biblioteca TLS é o que o seu programa usa para estabelecer uma conexão criptografada. O Rustls é uma escolha comum em serviços em Rust que querem evitar o OpenSSL.

O que a falha realmente permite

No meio de um aperto de mão TLS 1.3, os dois lados trocam de chaves. As mensagens enviadas após essa troca devem estar criptografadas com a chave nova. O Rustls não exigia isso sempre.

O aviso é específico quanto à condição. O Rustls aceitava mensagens de aperto de mão enviadas no nível de criptografia errado quando elas seguiam uma mensagem de troca de chaves dentro do mesmo registro. Um registro é o bloco que o protocolo de fato coloca na rede, então várias mensagens de aperto de mão podem viajar juntas.

Lido com honestidade, o alcance é mais estreito do que parece à primeira vista. "A transcrição do aperto de mão continua autenticada", diz o anúncio. Um atacante em posição de rede não pode usar isso para alterar um aperto de mão nem para concluir um que não deveria. O efeito prático é que um par podia enviar em texto claro algo que o protocolo exige criptografado, e o Rustls não rejeitava a conexão.

Portanto, é um bug de rigor, não uma verificação de autenticação quebrada. Ainda assim importa. Uma biblioteca que aceita mensagens proibidas pela especificação se desvia do RFC 8446, e é desses desvios que saem bugs de interoperabilidade e ataques posteriores.

Segurança de memória nunca foi o trabalho inteiro

O Phoronix tira a conclusão útil, e ela merece ser dita com clareza. O Rustls existe em parte porque código TLS sem segurança de memória tem um longo histórico de bugs graves, e o Rust elimina essa classe de defeito. Este bug não é dessa classe.

Nada no Rust impede que uma máquina de estados de protocolo aceite uma mensagem que deveria ter recusado. Esse é um erro de lógica, e erros de lógica sobrevivem a qualquer escolha de linguagem. Reescrever em uma linguagem segura livra você de estouros de buffer e de uso após liberação, não de ler mal uma especificação.

Este site já fez o mesmo ponto pelo outro lado: um pacote Rust foi o veículo de um ataque de cadeia de suprimentos em tempo de compilação contra o arrayref. A linguagem é uma camada de defesa, e apenas uma.

Quais versões verificar

Versão	Situação
0.23.13 a 0.23.44	Afetada
0.23.45	Corrigida
Anterior a 0.23.13	Antecede a mudança que introduziu o bug, segundo o aviso

O bug foi introduzido em setembro de 2024, e é por isso que a faixa afetada começa em 0.23.13 e não no início. O problema também é rastreado como GO-2026-4340.

O que isso significa para desenvolvedores

Atualize e depois descubra o que você estava realmente rodando. São duas tarefas separadas, e a segunda é a que as pessoas pulam.

Rode cargo update -p rustls e confirme que você chega em 0.23.45 ou posterior. Depois rode cargo tree -i rustls para ver o que o trouxe. O Rustls costuma ser uma dependência indireta, chegando por um cliente HTTP ou um framework de servidor. A versão que você recebe é decidida pelas faixas que esses crates permitem. Uma fixação transitiva em uma biblioteca que você não controla é o motivo comum para uma atualização parecer não fazer nada.

Se você entrega um binário e não um serviço, verifique o arquivo de lock a partir do qual realmente compilou, não o que está hoje na sua máquina. Ligar o cargo audit na integração contínua vale a pena, afete este bug você ou não, e ele sinalizará o aviso assim que o banco de dados o trouxer.

Mesmo assim, não gaste a tarde em resposta a incidente por causa disso. Não há indício de exploração em nenhuma das duas fontes, e o próprio aviso diz que a transcrição permanece autenticada, o que descarta a leitura mais assustadora. Trate como uma subida de dependência rotineira com um prazo real, não como uma emergência.

A lição mais ampla é sobre quanto tempo um bug silencioso de protocolo pode viver. Este ficou dois anos em versões lançadas, em uma biblioteca escolhida justamente pelas suas propriedades de segurança, e foi encontrado por revisão e não por um incidente. É o sistema funcionando. E também é um lembrete de que "escrito em Rust" é uma afirmação sobre uma categoria de bug, e sobre nada mais.