---
title: "Rustls completa dez anos com criptografia pós-quântica no roteiro do projeto aberto"
author: "Gabriela P. Torres"
date: "2026-09-14 08:30:00-03"
category: "Tecnologia & Desenvolvimento"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/14/rustls-completa-dez-anos-com-criptografia-pos-quantica-no-roteiro-do-projeto-aberto/md"
---

## Resumo
- Rustls completou dez anos em 2026, após iniciar como um esforço independente em maio de 2016.
- O projeto recebeu apoio da ISRG, por meio da iniciativa Prossimo, da AWS e passou por auditorias do CNCF via Cure53.
- A linha 0.23 começou em fevereiro de 2024 e acumulou 43 atualizações não disruptivas.
- Entre os recursos da 0.23 estão criptografia pós-quântica, certificação FIPS e Encrypted ClientHello.
- O Rustls 0.23.37 superou OpenSSL 3.6.1 e BoringSSL na maioria das situações testadas em x86_64.
- A versão 0.24 prevê external buffering, session types, split mode e provedores criptográficos em crates separadas.
- Após a consolidação da 0.24, o roteiro aponta para uma API estável 1.0.

---

O **Rustls** completou dez anos em 2026 como uma biblioteca de TLS, tecnologia usada para proteger comunicações em rede, escrita em Rust e orientada à segurança de memória. O aniversário, por si só, seria apenas uma marca de calendário; o dado que interessa é a sequência de decisões técnicas que levou o projeto de um esforço independente a uma iniciativa de código aberto sustentada, com melhorias de segurança, desempenho e arquitetura previstas para a próxima versão. A linha 0.23 já funciona como prova de maturidade, enquanto a 0.24 concentra mudanças internas e a futura 1.0 promete uma API estável para manutenção de longo prazo. A pergunta, portanto, não é apenas quando o Rustls nasceu, mas quais evidências sustentam a ideia de que ele está pronto para uma nova etapa.

## De um primeiro commit a um projeto sustentado

A cronologia começa com um **commit em 2 de maio de 2016**, segundo o registro histórico reunido pela LWN, e avança rapidamente: o projeto alcançou interoperabilidade com a web em um mês e publicou sua primeira versão, a 0.1.0, em agosto daquele ano. Interoperabilidade, neste caso, significa conseguir funcionar de maneira compatível com os sistemas e serviços da web, um teste prático bem diferente de existir apenas como código experimental. O material da [InfoQ sobre a década do Rustls](https://www.infoq.com/news/2026/09/rustls-one-decade) situa o início em maio de 2016 e confirma a primeira release em agosto. A distância entre esse ponto de partida e a atual linha 0.23 ajuda a medir o trabalho de refinamento que veio depois.

Esse começo independente não permaneceu sem apoio institucional. O **Rustls** evoluiu para um projeto de código aberto sustentado com apoio da ISRG, por meio da iniciativa Prossimo, e também da AWS, o que alterou a escala de continuidade disponível para seu desenvolvimento. A informação não autoriza concluir que todo o projeto passou a depender de uma única empresa, nem que cada decisão técnica tenha sido tomada por essas organizações; ela mostra que a biblioteca deixou de ser descrita apenas como um esforço isolado. Para uma ferramenta encarregada de implementar TLS, essa sustentação se conecta diretamente à necessidade de revisar interfaces, testar mudanças e manter versões ao longo do tempo. A história de financiamento e apoio, portanto, precisa ser lida junto com os sinais técnicos de estabilidade.

Outro sinal dessa transição aparece nas **auditorias do CNCF realizadas via Cure53**, mencionadas no balanço do projeto. Uma auditoria não substitui o uso real nem transforma uma biblioteca em código imune a falhas, mas acrescenta uma avaliação externa ao processo de desenvolvimento, algo especialmente relevante quando a promessa central envolve segurança de memória. A documentação também registra que o Rustls atravessou oito anos de refinamento de API até chegar à maturidade da versão 0.23. API é a interface que os programas utilizam para configurar e chamar a biblioteca; refiná-la significa ajustar essa superfície para que o uso seja mais previsível antes de declarar estabilidade de longo prazo. É nesse ponto que a versão 0.23 deixa de ser apenas um número de release e passa a funcionar como a base do próximo salto.

## O que a linha 0.23 já entrega

A maturidade citada no histórico pode ser observada na própria linha de lançamento: a **versão 0.23 começou em fevereiro de 2024** e acumulou 43 atualizações não disruptivas. A expressão descreve mudanças feitas sem romper a linha de estabilidade que vinha sendo construída, aspecto diferente de uma sequência de versões que exige reescrever a integração a cada alteração. Esse ritmo permite separar duas perguntas que costumam ser misturadas em anúncios de software: o que já foi incorporado a uma versão existente e o que ainda está no roteiro. No caso do Rustls, a resposta para a primeira pergunta inclui recursos de segurança modernos e resultados de desempenho mensurados, enquanto a resposta para a segunda aponta para uma reorganização interna na 0.24.

Entre os recursos incorporados está a **criptografia pós-quântica**, expressão usada para técnicas criptográficas projetadas para lidar com ameaças associadas a computadores quânticos. O material não afirma que todos os riscos futuros estejam resolvidos, nem que a biblioteca tenha abandonado os mecanismos anteriores; afirma que a linha 0.23 introduziu esse recurso. A diferença é relevante porque impede transformar uma característica técnica em uma promessa ilimitada: o fato verificável é a inclusão da capacidade no projeto, não a garantia de segurança absoluta contra qualquer ameaça. Para quem acompanha bibliotecas de proteção de conexões, esse detalhe ajuda a entender por que uma atualização de manutenção pode trazer mudanças com impacto de longo prazo sem abandonar a estabilidade da API, e prepara a análise das demais entregas da mesma linha.

Na mesma linha de segurança, a versão 0.23 introduziu a **certificação FIPS** e o Encrypted ClientHello, conhecido pela sigla ECH. FIPS aparece na fonte como uma certificação, isto é, uma forma documentada de conformidade com requisitos técnicos; já o ECH é apresentado como um recurso do projeto, sem que o balanço forneça uma promessa mais ampla sobre todos os ambientes de implantação. Essa distinção é o antídoto para o press release automático: três palavras técnicas não bastam para concluir que qualquer aplicação será imediatamente compatível com qualquer exigência regulatória ou operacional. O que os dados permitem dizer é mais preciso: a linha 0.23 ampliou o conjunto de recursos de segurança e de privacidade oferecidos pelo Rustls, enquanto a comparação de desempenho fornece outra camada de verificação.

Essa verificação foi feita em máquinas com arquitetura **x86_64**. Nos testes citados pela InfoQ, o Rustls 0.23.37 superou o OpenSSL 3.6.1 na maioria das situações avaliadas, tanto em handshakes quanto em throughput. Handshake é a etapa em que os participantes estabelecem os parâmetros de uma conexão protegida; throughput é a quantidade de dados processada em determinado intervalo. A formulação da fonte importa: ela fala em maioria das situações testadas, não em vitória universal sobre qualquer implementação, hardware ou configuração. Logo, a conclusão responsável é que o resultado oferece evidência comparativa favorável para aquele conjunto de testes, mas não autoriza apagar as condições da medição. A comparação com a outra biblioteca citada segue a mesma regra de leitura.

Na comparação com o **BoringSSL**, o Rustls 0.23.37 também ficou à frente na maioria das situações de benchmark descritas, considerando handshakes e throughput em x86_64. O resultado coloca a biblioteca em uma posição competitiva nos dois tipos de medida apresentados, mas não elimina a necessidade de observar qual operação está sendo medida e em que ambiente. Se o handshake pesa mais em uma aplicação, a primeira métrica merece atenção; se o sistema mantém tráfego contínuo, o throughput se torna mais representativo. A fonte não fornece uma tabela detalhada para cada configuração no material consolidado, então a afirmação deve permanecer no limite que os dados suportam: vantagem na maioria das situações testadas, sem transformar o benchmark em uma sentença sobre todos os usos possíveis.

## O que muda na arquitetura da versão 0.24

A próxima etapa deixa de concentrar a discussão apenas no resultado final e passa a mexer no caminho percorrido pelos dados. Segundo o texto de Joe Birr-Pixton publicado pela [Rust Foundation](https://rustfoundation.org/media/guest-post-a-decade-of-rustls/), a versão 0.24 introduzirá external buffering por meio do trait TlsInputBuffer para reduzir cópias de memória. External buffering significa manter o armazenamento dos dados de entrada fora do fluxo interno que normalmente os recebe, enquanto trait é uma interface que define comportamentos que um tipo pode oferecer em Rust. O objetivo informado é direto: evitar cópias desnecessárias durante o processamento. Se os dados podem ser reaproveitados sem duplicação, então existe uma possibilidade concreta de reduzir trabalho de memória; senão, o ganho prometido por essa mudança não aparece nessa etapa específica.

A mesma versão também prevê um sistema de **session types** para lidar com os estados do handshake em três formas de operação: async, blocking e completion-based. O ponto técnico é que o handshake não é tratado como uma ação única e indistinta; ele passa por estados, e a nova organização pretende representar esses estados de modo compatível com diferentes estilos de entrada e saída. Async descreve operações assíncronas, que não precisam bloquear a execução enquanto aguardam o próximo evento; blocking indica a espera direta; completion-based organiza o fluxo a partir da conclusão de operações. A fonte apresenta esse sistema como uma forma de atender esses modelos, não como uma afirmação de que toda aplicação terá o mesmo ganho. A arquitetura, portanto, tenta acomodar usos diferentes sem exigir que a biblioteca escolha um único modo de funcionamento.

O terceiro movimento arquitetural é o **split mode**, que permite separar o tráfego de envio e recebimento em threads distintas. Em uma carga full-duplex, isto é, uma carga em que envio e recebimento ocorrem simultaneamente, o texto técnico prevê que essa separação dobre o throughput. A lógica é verificável e tem duas condições explícitas: o trabalho precisa ser full-duplex e a separação precisa aproveitar threads diferentes; sem essas condições, não se pode transportar o número para qualquer aplicação. O anúncio não promete dobrar toda operação de rede, e sim o throughput em workloads full-duplex. Essa precisão faz diferença porque o ganho está associado ao modo de uso, não estampado como propriedade automática da versão.

Há ainda uma mudança na forma de configurar provedores criptográficos. Na versão 0.24, essa configuração será feita por **crates separadas**, em vez de ficar concentrada em uma combinação de recursos que pode gerar conflitos de feature unification. Crate é o pacote de código distribuído no ecossistema Rust, enquanto feature unification descreve a combinação de recursos ativados por dependências que compartilham o mesmo pacote. Ao separar os provedores, o projeto busca eliminar esse tipo de conflito na configuração. A fonte apresenta a mudança como decisão de arquitetura para o próximo release, portanto o texto deve ser lido como roteiro técnico, não como confirmação de que todos os problemas de integração já foram resolvidos em uma versão disponível.

Os exemplos fornecidos para essa separação são **rustls-aws-lc-rs** e **rustls-ring**, apresentados como crates independentes para provedores criptográficos. A consequência descrita é a eliminação de conflitos de feature unification, o que torna mais explícita a escolha do componente criptográfico usado na configuração. O detalhe é pequeno no nome e grande na manutenção: se a seleção fica distribuída em pacotes próprios, a configuração deixa de depender de uma disputa silenciosa entre recursos ativados por dependências. Ainda assim, o verbo adequado é será, porque a descrição pertence ao plano da versão 0.24. A distinção entre o que a 0.23 já demonstrou e o que a 0.24 pretende reorganizar é a parte mais importante dessa leitura.

## Do release 0.24 à promessa de estabilidade

Depois da consolidação da **versão 0.24**, o roteiro aponta para uma API estável 1.0 voltada à manutenção de longo prazo. A sequência é relevante: primeiro vêm as mudanças de buffering, estados de handshake, separação de tráfego e configuração dos provedores; depois, a promessa de estabilizar a interface que os usuários integram às próprias aplicações. A LWN descreve esse caminho como a consolidação da 0.24 seguida pelo lançamento de uma API estável 1.0. Como não há no material uma data para a 1.0, qualquer calendário mais específico seria invenção. O fato disponível é a ordem das etapas, e ela mostra que o projeto ainda trata a estabilidade definitiva como um marco posterior à reorganização arquitetural.

Essa ordem também permite desmontar uma interpretação apressada. Se o Rustls já acumulou oito anos de refinamento de API até a 0.23, então a passagem para a 1.0 não aparece como consequência automática de completar dez anos; ela depende da consolidação da 0.24 e da decisão posterior de estabilizar a interface. Para quem avalia a biblioteca, a leitura prática é separar desempenho medido, recursos já incorporados e melhorias anunciadas. Os benchmarks da 0.23.37 pertencem a uma versão identificada e a testes em x86_64; o external buffering e o split mode pertencem ao roteiro da 0.24; a API de longo prazo ainda está associada à futura 1.0. Misturar essas três camadas produz exatamente o tipo de promessa que os dados não autorizam.

## A caixa de ferramentas para ler o anúncio

O primeiro instrumento é a linha do tempo: **maio de 2016** marca o início, agosto de 2016 registra a release 0.1.0, fevereiro de 2024 inaugura a linha 0.23 e 2026 marca a década do projeto. O segundo é a separação entre sustentação e resultado: o Rustls recebeu apoio da ISRG e da AWS, além de auditorias do CNCF via Cure53, mas os dados técnicos precisam ser examinados por conta própria. O terceiro é o recorte dos benchmarks: a vantagem sobre OpenSSL 3.6.1 e BoringSSL foi observada na maioria das situações testadas, em x86_64, com foco em handshakes e throughput. Esses filtros transformam um aniversário em informação verificável, em vez de aceitar a narrativa pronta sem conferir suas condições.

O próximo passo anunciado é a **versão 0.24**, com external buffering, session types, split mode e provedores criptográficos em crates separadas; depois dela, o roteiro prevê a API estável 1.0. Até que essas etapas sejam consolidadas, a conclusão mais precisa é esta: o Rustls já tem uma década de evolução documentada, a linha 0.23 reúne recursos modernos e benchmarks favoráveis nas condições informadas, e a versão 0.24 ainda precisa transformar suas propostas arquiteturais em uma implementação consolidada. Se a promessa for estabilidade de longo prazo, então o marco decisivo não é o número de anos completados, mas a passagem verificável da 0.24 para uma API 1.0.