Lanzamiento de OpenSSL 4.0.0

 (github.com/openssl)
5 puntos por GN⁺ 15 일 전 | 2 comentarios | Compartir por WhatsApp
  • Un lanzamiento grande que incluye múltiples funciones nuevas y cambios incompatibles
  • Incluye soporte integrado para ECH (Encrypted Client Hello, RFC 9849), por lo que ya no se necesita una implementación separada para proteger la privacidad de clientes TLS
  • Se eliminó por completo el código de SSLv2 Client Hello, SSLv3 y engine, marcando una ruptura definitiva con los protocolos heredados
  • Se añadió soporte para firma SM2 basada en RFC 8998 (sm2sig_sm3), intercambio de claves (curveSM2) y el grupo poscuántico curveSM2MLKEM768
  • Se agregaron nuevas funciones criptográficas como cSHAKE (SP 800-185), el digest ML-DSA-MU, SNMP KDF y SRTP KDF
  • Soporte para negociación de intercambio de claves FFDHE basado en RFC 7919 en TLS 1.2
  • Al instalar el módulo FIPS, la opción -defer_tests permite posponer la ejecución de las autoevaluaciones FIPS
  • Modernización de la API con la adición del calificador const en múltiples firmas de funciones y la opacificación de ASN1_STRING, entre otros cambios
  • Se recomienda reemplazar funciones obsoletas como X509_cmp_time() por X509_check_certificate_times()
  • Al usar el proveedor FIPS de PKCS5_PBKDF2_HMAC, ahora se fuerza la validación de valores mínimos, y la verificación de CRL incorpora comprobaciones adicionales
  • Amplia limpieza de funciones heredadas, incluyendo métodos personalizados obsoletos de EVP_CIPHER, EVP_MD, EVP_PKEY, funciones de versión fija de SSL/TLS, el script c_rehash y BIO_f_reliable()
  • Se eliminaron objetivos de compilación antiguos de Apple como darwin-i386 y darwin-ppc
  • En Windows, ahora se admite la selección entre enlace estático o dinámico del runtime de VC
  • Este lanzamiento marca un punto de inflexión para reforzar la seguridad y la compatibilidad con estándares en OpenSSL

Lecturas relacionadas

2 comentarios

 
kaydash 12 일 전

Parece que fue ayer cuando usábamos 1.1.1
 
GN⁺ 15 일 전
Comentarios en Hacker News

  • Expresan alegría porque por fin se añadió soporte para Encrypted Client Hello (ECH)

    • Se preguntan si es una función que puede activarse ahora mismo o si habrá que esperar mucho tiempo más hasta que navegadores y servidores la soporten
    • También mencionan QUIC
    • Sin embargo, advierten que en la mayoría de las redes es muy probable que este tipo de tráfico sea bloqueado

  • Citando una entrada del blog de HAProxy sobre el estado de los stacks SSL, enfatizan que ya no se debería usar v3

    • Valoran positivamente que OpenSSL recién el año pasado empezara a ofrecer una API para que los desarrolladores pudieran implementar QUIC por su cuenta
      Antes, si usabas OpenSSL, la implementación de QUIC también quedaba forzada a usar el stack de OpenSSL
      QUIC es un protocolo que reimplementa funciones de TCP sobre UDP y sirve como base de HTTP/3
      Pero, aunque no te gustara la implementación de QUIC de OpenSSL, no había otra alternativa
      Por ejemplo, si curl estaba enlazado con OpenSSL, curl también tenía que usar automáticamente el QUIC de OpenSSL
      Sobre esto, mencionan que Daniel Stenberg de curl escribió una entrada de blog crítica

  • Ante la pregunta por el estado actual de OpenSSL, comentan que en términos de seguridad mejoró mucho desde el antiguo incidente de Heartbleed

    • Después de Heartbleed, se reforzó el sistema de gestión de seguridad de OpenSSL, y ahora se ha convertido en uno de los objetivos de seguridad más investigados de internet
      Pero también hay muchas opiniones de que la calidad del software más bien retrocedió
      Se dice que el diseño de OpenSSL 3.0 empeoró el rendimiento, y que proyectos importantes como pyca/cryptography están mostrando movimientos para reemplazar OpenSSL
    • Otro usuario evalúa OpenSSL 3 como una gran decepción en rendimiento, complejidad y experiencia para desarrolladores
      Dice que las operaciones principales de OpenSSL 3 son mucho más lentas que en 1.1.1, y cita el análisis de stacks SSL de HAProxy y la declaración del equipo de Python cryptography
      Explica que OpenSSL 3 hizo muchos elementos dinámicos y terminó abusando de los locks, y que la API también cambió al esquema OSSL_PARAM, lo que provocó pérdida de rendimiento y mayor complejidad del código

  • Mencionan que, comparado con OpenSSL 3, esta transición avanzó de forma muy fluida
    En Fedora, salvo la eliminación de “Engines”, la mayoría de las dependencias se corrigieron sin grandes problemas

  • Señalan que el procedimiento manual de opt-out se está volviendo una fuente de fricción cada vez mayor
    Critican la realidad de que la configuración predeterminada solo mejora cuando hay rechazo de la comunidad, y enfatizan que la confianza es difícil de construir y fácil de perder

  • Bromean diciendo que parece que lo lanzaron a tiempo para el “suckerpinch video”

  • Desde la perspectiva de alguien no especializado, comentan que este cambio parece una limpieza bastante ordenada, pero que romper compatibilidad siempre pesa
    Recuerdan que OpenSSL 3.x no fue precisamente muy querido

    • Por eso responden diciendo que esta vez es la versión 4

  • Les preocupa que, al ser una actualización de versión mayor, pueda volverse más lento, pero dicen que en benchmarks reales solo hubo una caída de rendimiento de alrededor del 10% en promedio
    Añaden que, visto en el contexto general de internet, no parece un gran problema

  • Celebran que en el código haya más uso de const
    En entornos embebidos muchas veces había que agregar const manualmente, y les gusta que ahora la dirección sea aplicarlo por defecto

  • Finalmente, hacen una broma imaginando los gritos de los administradores de paquetes de distribuciones Linux