Uma das grandes coisas sobre código aberto é a disponibilidade de diversas abordagens. Este artigo examina a importância crítica da escalabilidade de desempenho em bibliotecas SSL/TLS, usando mudanças recentes no ecossistema OpenSSL como estudo de caso. Somos gratos pelos projetos de código aberto e suas contribuições para o mundo
Diretor de Marketing Técnico da HAProxy Technologies.
OpenSSL, a biblioteca SSL mais usada em sistemas operacionaisexperimentou uma grave regressão de desempenho com sua versão 3.0. Projetado para melhorar segurança e modularidade, a nova arquitetura introduziu regressões significativas de desempenho em ambientes multithread.
Especificamente, o desempenho se estabiliza em torno de 24 threads, sem poder aproveitar mais threads.
É importante observar que uma nova versão 3.5 LTS corrige muitos dos problemas de desempenho da 3.0. No entanto, embora a versão 3.5 tenha um desempenho muito melhor que a versão 3.0, ainda não é tão rápida quanto a 1.1.1.
A situação se estabilizou, com os atuais níveis de desempenho representando uma nova linha de base para o OpenSSL, embora sejam esperados desenvolvimentos contínuos. Vamos ficar de olho no 3.6, que será lançado em outubro (ainda não testamos).
Apesar destes desafios de desempenho, o OpenSSL continua a ser uma pedra angular das comunicações seguras na Internet e a sua evolução reflete as complexas compensações inerentes aos projetos de código aberto em grande escala.
No entanto, isso é realmente maior que o OpenSSL. A realidade é que os problemas de desempenho observados no OpenSSL 3.x destacam um risco potencial nas ferramentas que usamos para conectar o mundo digital.
Isto representa um desafio tangível para a indústria, uma vez que esta “ameaça silenciosa à escalabilidade” pode permanecer sem ser detectada até projetos tentativa de expansão, resultando em gargalos imprevistos e aumento drástico nas despesas de infraestrutura.
Compreender esse problema (e como resolvê-lo) é vital para o sucesso de qualquer projeto que precise atender mais do que níveis básicos de tráfego.
O papel da camada SSL/TLS
Considere o quão onipresente é o SSL (Secure Sockets Layer), ou mais precisamente o TLS (Transport Layer Security), hoje. É um protocolo de segurança que estabelece um link criptografado entre uma web servidor e um navegador. É a base das comunicações seguras na Internet e um componente crítico da maioria das solicitações da Internet.
Esse link garante que todos os dados transmitidos permaneçam privados e seguros, e é por isso que um problema significativo de desempenho com SSL/TLS pode afetar quase tudo online.
Ao selecionar uma biblioteca SSL/TLS, as organizações devem considerar vários aspectos importantes:
Requisitos funcionais: A biblioteca deve implementar corretamente protocolos criptográficos modernos e seguros.
Requisitos de manutenção: A biblioteca precisa de um ciclo de suporte previsível, especialmente para versões de suporte de longo prazo (LTS), que são cruciais para implantações estáveis e de longo prazo.
Considerações de desempenho: Além da velocidade bruta, um indicador-chave de desempenho é a capacidade da biblioteca de escalar com poder de processamento adicional. Em sistemas multi-core modernos, espera-se que o desempenho aumente à medida que mais processadores ou núcleos são adicionados.
Problemas de desempenho em bibliotecas SSL/TLS podem forçar as organizações a uma situação difícil: priorizar a segurança adotando a versão mais recente, mas com desempenho prejudicado, ou manter o desempenho com a versão mais antiga, agora sem suporte, arriscando vulnerabilidades críticas de segurança.
Esta situação é ainda mais preocupante porque é uma questão sistémica. SSL/TLS não é apenas mais um software; é a espinha dorsal da comunicação segura para a maioria dos sistemas conectados à Internet.
De servidores web a dispositivos IoT, SSL/TLS está em toda parte. Portanto, quaisquer problemas de desempenho nestas bibliotecas não são incidentes isolados, mas sim uma ameaça à estabilidade e segurança da Internet em geral. infraestrutura.
Na verdade, as mudanças no OpenSSL oferecem uma grande oportunidade para examinar essa parte da pilha e entender como as escolhas arquitetônicas geralmente envolvem compensações. Ao compreender a situação de há 4 anos e como o projecto se adaptou, podemos compreender como nos adaptar às mudanças na paisagem.
Um estudo de caso em dimensionamento de desempenho
O lançamento do OpenSSL 3.0, a biblioteca SSL mais utilizada em sistemas operacionais, introduziu um desafio tangível para a indústria. A versão 3.x foi projetada para ser mais dinâmica e flexível, beneficiando os desenvolvedores e muitos dos casos de uso padrão que ela emprega.
No entanto, este novo design teve uma consequência não intencional no desempenho, tornando-o menos adequado para cargas de trabalho críticas para o desempenho. Esse impacto no desempenho tem sérias consequências no mundo real. Os sistemas que costumavam lidar com milhares de solicitações por segundo estavam enfrentando dificuldades.
Algumas organizações precisam de até 42 vezes mais hardware apenas para manter o mesmo nível de serviço. Este foi um grande golpe para quem depende de ambientes multithread.
Cenários de teste, incluindo handshakes TLS completos em modo servidor e conexões ponta a ponta com retomada de sessão, revelaram uma queda significativa de desempenho em comparação com seu antecessor, a versão 1.1.1. A questão central não era apenas uma desaceleração, mas uma falha na escalabilidade eficaz
Em alguns casos, a lentidão piora à medida que você adiciona mais poder de processamento. Isso é o oposto do que você esperaria dos sistemas multi-core modernos.
Esse comportamento decorre de alterações fundamentais no design, incluindo pesquisas em tempo de execução, mecanismos de bloqueio excessivos e uma dependência excessiva de operações atômicas, que criaram gargalos de desempenho significativos.
Conforme observado acima, o OpenSSL respondeu melhorando o desempenho na versão 3.x, com a versão atual 3.5 LTS apresentando muitas melhorias.
Não queremos insistir em problemas do passado. Na verdade, para muitas pessoas, o OpenSSL continua a ser uma ótima opção que atende às suas necessidades, com seu design dinâmico oferecendo vantagens em relação às versões anteriores. Na verdade, este é frequentemente o caso quando a escolha de optimizar uma área (neste caso, flexibilidade) pode muitas vezes levar a compromissos noutra área.
No entanto, este é um estudo de caso importante sobre como é fácil tornar-se complacente com componentes amplamente utilizados e padronizados em nossa pilha de tecnologia. É também um lembrete de que um ecossistema mais diversificado é normalmente mais seguro e melhor para todos.
Navegando no ecossistema da biblioteca SSL
Novos desafios de desempenho colocam as organizações em uma situação difícil. Um caminho é aceitar a penalidade de desempenho, o que pode levar ao provisionamento excessivo de hardware. Para muitos, esta não é uma estratégia viável a longo prazo.
Isto leva a um caminho alternativo: encontrar um substituto. A ideia de trocar as principais bibliotecas criptográficas é assustadora e é verdade que nenhuma alternativa oferece uma solução totalmente integrada e integrada. No entanto, existem alternativas fortes como wolfSSL e AWS-LC, cada uma com pontos fortes.
Essas bibliotecas podem exigir testes cuidadosos para serem integradas, mas geralmente oferecem vantagens atraentes de desempenho. Na verdade, o AWS-LC alcançou desempenho multithread ainda maior do que o OpenSSL 1.1.1, que há muito tempo é o padrão ouro.
O desafio não reside na falta de opções viáveis, mas no esforço necessário para fazer a transição de um padrão profundamente enraizado. No entanto, estas situações podem, na verdade, levar a um melhor desempenho, a um ecossistema mais diversificado e à consciência de opções alternativas que podem ser mais adequadas para cenários específicos.
O caminho a seguir: foco nas necessidades futuras
O desempenho de uma biblioteca SSL/TLS é um fator crítico que pode permanecer despercebido até que um projeto tente escalar, resultando em gargalos imprevistos e aumento de despesas com infraestrutura. À medida que a indústria enfrenta esse desafio, os projetos devem permanecer proativos em relação às implicações de desempenho da biblioteca SSL escolhida.
O caminho mais promissor a seguir envolve uma consideração mais ampla das ferramentas disponíveis. As organizações são incentivadas a se familiarizarem com alternativas que não sejam necessariamente substitutas para todos os casos de uso, mas opções viáveis para cenários específicos e sensíveis ao desempenho.
Você deve se familiarizar com as alternativas para ajudar a decidir quando e se será necessário substituir o OpenSSL. Podemos mitigar esses riscos ativamente monitoramento desempenho, considerando bibliotecas alternativas e envolvendo-se com a comunidade de código aberto.
Acima de tudo, devemos lembrar-nos de não nos tornarmos complacentes com a nossa pilha de tecnologia. As mudanças podem trazer benefícios ou problemas, mas muitas vezes também são oportunidades.
Para uma análise abrangente do desempenho do OpenSSL 3.x, incluindo benchmarks detalhados, resultados de criação de perfil e uma comparação de bibliotecas alternativas, consulte a postagem detalhada do blog “The State of SSL Stacks”. Observe que isso vem de testes internos de um ano atrás e tem cobertura limitada de versões mais recentes.
Apresentamos o melhor computador empresarial.
Este artigo foi produzido como parte do canal Expert Insights da TechRadarPro, onde apresentamos as melhores e mais brilhantes mentes do setor de tecnologia atualmente. As opiniões expressas aqui são de responsabilidade do autor e não são necessariamente da TechRadarPro ou Future plc. Se você estiver interessado em contribuir saiba mais aqui: https://www.techradar.com/news/submit-your-story-to-techradar-pro