A Rustls, biblioteca de TLS escrita em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) → e projetada para ser memory-safe, completou dez anos e publicou uma retrospectiva com números de desempenho e o roadmap até a primeira API estável. Iniciada em maio de 2016, chegou à versão 0.1.0 ainda naquele ano e, uma década depois, virou a alternativa nativa em Rust ao onipresente OpenSSL, aquele mesmo cuja base em C carrega o histórico de vulnerabilidades de memória (Heartbleed sendo o caso mais lembrado).
Para quem constrói e opera software no Brasil, essa não é uma curiosidade de nicho. TLS está no caminho de praticamente toda requisição HTTPS que sua aplicação faz ou recebe. Trocar a stack de criptografia por uma implementação com segurança de memória garantida pelo compilador tem impacto direto na superfície de ataque de qualquer serviço em produção, e agora vem acompanhada de números que colocam a Rustls na frente em throughput e handshakes.
De projeto de garagem a base financiada
A Rustls nasceu como esforço voluntário, tocado por contribuidores independentes como Brian Smith e Dirkjan Ochtman. O que mudou o jogo foi o financiamento sustentado: a iniciativa Prossimo, da Internet Security Research Group (ISRG, a mesma organização por trás do Let's Encrypt), a Amazon Web Services↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → e auditorias de terceiros pela Cure53 bancadas pela CNCF permitiram trabalho em tempo integral.
Esse dinheiro se traduziu em recursos que importam para quem tem requisitos de conformidade: certificação FIPS, criptografia pós-quântica e Encrypted ClientHello entraram no projeto graças a mantenedores dedicados. Também bancou refatoração de arquitetura e trabalho de robustez, coisas que raramente sobrevivem em projeto mantido só por boa vontade.
Os benchmarks: Rustls na frente
A retrospectiva traz comparações da Rustls 0.23.37 contra OpenSSL 3.6.1 e BoringSSL em arquitetura x86_64. Os números são medidos por núcleo, o que ajuda a raciocinar sobre custo em ambientes com escala horizontal.
| Métrica (por core) | Rustls 0.23.37 | OpenSSL 3.6.1 | BoringSSL |
|---|---|---|---|
| Handshakes completos/s | 2.357 | 1.713 (1,38x mais lento) | 1.302 (1,82x mais lento) |
| Handshakes retomados/s | 7.249 | 3.780 (1,92x mais lento) | 5.687 (1,28x mais lento) |
| Throughput recebido (MB/s) | 7.333 | 6.238 (1,18x mais lento) | 6.218 (1,18x mais lento) |
| Throughput enviado (MB/s) | 7.421 | 5.844 (1,27x mais lento) | 7.565 (1,02x mais rápido) |
A Rustls lidera em três das quatro métricas. O único ponto em que perde é no throughput de envio, onde o BoringSSL fica marginalmente à frente (1,02x). A vantagem mais expressiva aparece nos handshakes retomados, quase o dobro da velocidade do OpenSSL, o que é relevante para serviços com alto volume de conexões de curta duração.
O detalhe prático: derrubar o mito de que segurança de memória cobra pedágio de performance. Aqui a implementação em Rust não só empata como supera bibliotecas em C consagradas na maioria dos cenários medidos.
A disciplina de API da linha 0.23
Parte da reputação da Rustls vem da estabilidade da linha 0.23, que sustentou dezenas de atualizações sem quebra de compatibilidade. Em discussões no Reddit e no Hacker News, adotantes citaram justamente essa consistência como sinal de gestão madura de API, algo que quem já sofreu com migração forçada em dependência crítica sabe valorizar.
O que vem na 0.24
A próxima versão promete mudanças de arquitetura com foco em performance e integração de ecossistema:
- Buffer externo via trait
TlsInputBuffer: em vez de rotear tudo pelos traits padrão de I/O, a entrada passa por esse mecanismo e a saída é anexada a vetores fornecidos pelo usuário. Isso habilita descriptografia in-place e elimina cópias redundantes de memória. - Suporte a assíncrono via session types: os estados do handshake passam a ser modelados sequencialmente, permitindo rodar handshakes em estilo blocking, async ou completion-based, um alívio para quem trabalha com runtimes assíncronos.
- Split mode: recurso pedido pela comunidade lá em 2019. Hoje um único objeto de conexão cuida de enviar e receber. No split mode, o tráfego pós-handshake é separado em objetos
SendTrafficeReceiveTraffic, ambos implementandoSend. Como podem operar de forma independente em threads diferentes, com um back-channel interno de baixa contenção, aplicações com tráfego full-duplex podem efetivamente dobrar o throughput. - Crypto providers desacoplados em crates separadas (
rustls-aws-lc-rserustls-ring), removendo os panics de unificação de build-feature e permitindo configurar o provider global externamente.
Esse último ponto merece atenção de quem já apanhou com o sistema de features do Cargo: a unificação de features entre dependências transitivas costuma gerar comportamento inesperado, e desacoplar os providers em crates dedicadas ataca exatamente essa dor.
O caminho até a 1.0
Depois de estabilizar a 0.24, os mantenedores planejam avançar para uma API estável 1.0, projetada para manutenção de longo prazo. Para times brasileiros que evitam adotar biblioteca de criptografia ainda em versão 0.x por receio de breaking changes, esse é o sinal que faltava: a Rustls está deixando de ser aposta de early adopter para virar candidata a dependência de produção com garantias de estabilidade.
O que ainda fica em aberto é o cronograma. A retrospectiva não fixa datas para a 0.24 nem para a 1.0, e a maturidade do ecossistema em torno de bindings para outras linguagens (a Rustls já tem interface C via rustls-ffi) continua sendo o gargalo para quem quer o benefício de segurança de memória sem reescrever a aplicação inteira em Rust. Para quem já está no ecossistema Rust, porém, os números e o roadmap deixam claro que a troca do OpenSSL deixou de ser sacrifício de performance.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Baeta. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
Comentários
Ninguém comentou ainda. Começa a conversa?