Lançamento do OpenSSL 4.0.0

• Um grande lançamento com muitos novos recursos e mudanças incompatíveis
• Suporte embutido a ECH (Encrypted Client Hello, RFC 9849), eliminando a necessidade de implementação separada para proteger a privacidade de clientes TLS
• O código de SSLv2 Client Hello, SSLv3 e engine foi completamente removido, confirmando o rompimento com protocolos legados
• Adicionado suporte a assinatura SM2 (sm2sig_sm3), troca de chaves (curveSM2) com base na RFC 8998, e ao grupo pós-quântico curveSM2MLKEM768
• Novos recursos criptográficos adicionados, como cSHAKE (SP 800-185), digest ML-DSA-MU, SNMP KDF e SRTP KDF
• Suporte à negociação de troca de chaves FFDHE baseada na RFC 7919 no TLS 1.2
• Ao instalar o módulo FIPS, a opção -defer_tests permite adiar a execução dos autotestes FIPS
• Modernização da API com adição do qualificador const em várias assinaturas de funções e opacificação de ASN1_STRING
• Recomenda-se substituir funções obsoletas como X509_cmp_time() por X509_check_certificate_times()
• Ao usar o provedor FIPS em PKCS5_PBKDF2_HMAC, passa a ser obrigatória a verificação de valor mínimo, e a validação de CRL recebeu verificações adicionais
• Grande limpeza de recursos legados, incluindo métodos customizados obsoletos de EVP_CIPHER, EVP_MD, EVP_PKEY, funções de versão fixa de SSL/TLS, script c_rehash, BIO_f_reliable() e outros
• Removidos alvos antigos de build da Apple como darwin-i386 e darwin-ppc
• Suporte, no Windows, à escolha entre linkagem estática e dinâmica do runtime VC
• Este lançamento marca um ponto de virada para reforçar a segurança e a conformidade com padrões do OpenSSL

[kaydash]

Parece que era ontem quando eu usava a 1.1.1

[GN⁺]

Comentários do Hacker News

• Comemoram que finalmente foi adicionado suporte a Encrypted Client Hello (ECH)

  • Perguntam se isso já é algo que pode ser ativado agora mesmo, ou se ainda vai levar muito tempo até que navegadores e servidores deem suporte
  • E também mencionam QUIC
  • Mas alertam que, na maioria das redes, há grande chance de esse tipo de tráfego ser bloqueado

• Citando um post do blog da HAProxy sobre o estado das stacks SSL, enfatizam que agora não se deve mais usar a v3

  • Avaliam positivamente o fato de que só no ano passado o OpenSSL começou a fornecer APIs para que desenvolvedores pudessem implementar QUIC diretamente
    Antes, ao usar OpenSSL, a implementação de QUIC também era obrigada a usar a stack do próprio OpenSSL
    QUIC é um protocolo que reimplementa funções do TCP sobre UDP e serve como base do HTTP/3
    Mas, mesmo que a implementação de QUIC do OpenSSL não agradasse, não havia outra alternativa
    Por exemplo, se o curl estivesse linkado ao OpenSSL, o curl também teria de usar automaticamente o QUIC do OpenSSL
    Mencionam que Daniel Stenberg, do curl, escreveu um post crítico no blog sobre isso

• Em resposta a uma pergunta sobre o estado atual do OpenSSL, comentam que, desde o antigo incidente Heartbleed, a segurança melhorou bastante

  • Depois do Heartbleed, a estrutura de governança de segurança do OpenSSL foi reforçada, e hoje ele se tornou um dos alvos de segurança mais estudados da internet
    Mas há muitas avaliações de que a qualidade do software piorou
    O design do OpenSSL 3.0 representou um retrocesso em desempenho, e projetos importantes como o pyca/cryptography vêm mostrando movimentos para substituir o OpenSSL
  • Outro usuário avalia que o OpenSSL 3 foi uma grande decepção em desempenho, complexidade e experiência de desenvolvimento
    As operações centrais do OpenSSL 3 são muito mais lentas que as da 1.1.1, e ele cita a análise das stacks SSL da HAProxy e a declaração da equipe do Python cryptography
    Explica que o OpenSSL 3 tornou muitos elementos dinâmicos, o que levou a um uso excessivo de locks, e que a API também mudou para o modelo OSSL_PARAM, causando queda de desempenho e maior complexidade no código

• Comentam que, em comparação com o OpenSSL 3, esta transição foi muito tranquila
  No Fedora, fora a remoção de “Engines”, a maioria das dependências foi ajustada sem grandes problemas

• Apontam que o procedimento manual de opt-out está se tornando uma fonte cada vez maior de atrito
  Criticam a realidade em que as configurações padrão só melhoram quando há reação da comunidade, e enfatizam que confiança é difícil de construir e fácil de perder

• Reagem em tom de piada dizendo que parece ter sido lançado no timing do “suckerpinch video”

• Como não especialista, alguém comenta que esta mudança parece uma arrumação bem limpa, mas que quebras de compatibilidade sempre pesam
  Também lembram que o OpenSSL 3.x não foi muito querido

  • E por isso respondem: por isso é a versão 4

• Há preocupação de que, por ser um upgrade de versão principal, ele fique mais lento, mas dizem que nos benchmarks reais houve em média apenas cerca de 10% de perda de desempenho
  Acrescentam que, olhando para o ambiente da internet como um todo, isso não parece um grande problema

• Recebem bem o uso mais amplo de const no código
  Em ambientes embarcados, muitas vezes era preciso adicionar const manualmente, e gostam da direção de isso passar a valer por padrão

• Por fim, fazem piada imaginando os gritos dos gerenciadores de pacotes das distribuições Linux