stringtranslate.com

OpenSSL

OpenSSL es una biblioteca de software para aplicaciones que proporcionan comunicaciones seguras a través de redes informáticas contra escuchas no autorizadas e identifican a la parte que se encuentra en el otro extremo. Es ampliamente utilizada por servidores de Internet , incluida la mayoría de sitios web HTTPS .

OpenSSL contiene una implementación de código abierto de los protocolos SSL y TLS . La biblioteca principal , escrita en el lenguaje de programación C , implementa funciones criptográficas básicas y proporciona varias funciones de utilidad. Hay disponibles envoltorios que permiten el uso de la biblioteca OpenSSL en una variedad de lenguajes informáticos.

La OpenSSL Software Foundation (OSF) representa al proyecto OpenSSL en la mayoría de las funciones legales, incluidos los acuerdos de licencia de los colaboradores, la gestión de donaciones, etc. OpenSSL Software Services (OSS) también representa al proyecto OpenSSL en los contratos de soporte.

OpenSSL está disponible para la mayoría de los sistemas operativos tipo Unix (incluidos Linux , macOS y BSD ), Microsoft Windows y OpenVMS .

Historial del proyecto

El proyecto OpenSSL fue fundado en 1998 para proporcionar un conjunto gratuito de herramientas de cifrado para el código utilizado en Internet. Se basa en una bifurcación de SSLeay de Eric Andrew Young y Tim Hudson, cuyo desarrollo finalizó de manera no oficial el 17 de diciembre de 1998, cuando Young y Hudson pasaron a trabajar para RSA Security . Los miembros fundadores iniciales fueron Mark Cox, Ralf Engelschall, Stephen Henson, Ben Laurie y Paul Sutton. [4]

En 2018, la numeración de versiones de OpenSSL pasó de 1.1.1 a 3.0.0, omitiendo el 2 como número de versión principal para evitar un conflicto con uno de los módulos de OpenSSL. La versión 3.0.0 fue la primera en utilizar la licencia Apache .

En mayo de 2019 , [5] el comité de gestión de OpenSSL estaba formado por siete personas [6] y hay diecisiete desarrolladores [7] con acceso de confirmación (muchos de los cuales también forman parte del comité de gestión de OpenSSL). Solo hay dos empleados a tiempo completo (fellows) y el resto son voluntarios.

El proyecto tiene un presupuesto de menos de un millón de dólares al año y depende principalmente de donaciones. El desarrollo de TLS 1.3 fue patrocinado por Akamai . [8]

Lanzamientos de versiones principales

Algoritmos

OpenSSL admite varios algoritmos criptográficos diferentes:

Cifras
AES , Blowfish , Camelia , ChaCha20 , Poly1305 , SEMILLA , CAST-128 , DES , IDEA , RC2 , RC4 , RC5 , Triple DES , GOST 28147-89 , [38] SM4
Funciones hash criptográficas
MD5 , MD4 , MD2 , SHA-1 , SHA-2 , SHA-3 , RIPEMD-160 , MDC-2 , GOST R 34.11-94 , [38] BLAKE2 , Whirlpool , [39] SM3
Criptografía de clave pública
RSA , DSA , intercambio de claves Diffie-Hellman , curva elíptica , X25519 , Ed25519 , X448 , Ed448 , GOST R 34.10-2001, [38] SM2

( El secreto directo perfecto se admite mediante el uso de la curva elíptica Diffie-Hellman desde la versión 1.0. [40] )

Validación FIPS 140

FIPS 140 es un programa federal de los EE. UU. para la prueba y certificación de módulos criptográficos. Un certificado FIPS 140-1 temprano para FOM 1.0 de OpenSSL fue revocado en julio de 2006 "cuando surgieron preguntas sobre la interacción del módulo validado con software externo". El módulo fue recertificado en febrero de 2007 antes de dar paso a FIPS 140-2. [41] OpenSSL 1.0.2 admitía el uso del Módulo de objetos FIPS (FOM) de OpenSSL, que se creó para ofrecer algoritmos aprobados por FIPS en un entorno validado por FIPS 140-2. [42] [43] OpenSSL decidió de manera controvertida categorizar la arquitectura 1.0.2 como "fin de vida" o "EOL", a partir del 31 de diciembre de 2019, a pesar de las objeciones de que era la única versión de OpenSSL que estaba actualmente disponible con soporte para el modo FIPS. [44] Como resultado del EOL, muchos usuarios no pudieron implementar correctamente el FOM 2.0 y dejaron de cumplir con las normas porque no consiguieron soporte extendido para la arquitectura 1.0.2, aunque el FOM en sí permaneció validado durante ocho meses más.

El módulo de objeto FIPS 2.0 siguió estando validado según FIPS 140-2 en varios formatos hasta el 1 de septiembre de 2020, cuando el NIST desaprobó el uso de FIPS 186-2 para el estándar de firma digital y designó todos los módulos no compatibles como "históricos". Esta designación incluye una advertencia a las agencias federales de que no deben incluir el módulo en ninguna nueva adquisición. Las tres validaciones de OpenSSL se incluyeron en la desaprobacion: el módulo de objeto FIPS de OpenSSL (certificado n.° 1747), [45] el módulo de objeto FIPS de OpenSSL SE (certificado n.° 2398), [46] y el módulo de objeto FIPS de OpenSSL RE (certificado n.° 2473). [47] Muchas validaciones y clones basados ​​en OpenSSL de "etiqueta privada" creados por consultores también se trasladaron a la lista histórica, aunque algunos módulos validados por FIPS con compatibilidad de reemplazo evitaron la desaprobacion, como BoringCrypto de Google [48] y CryptoComply de SafeLogic. [49]

El Comité de Gestión de OpenSSL anunció un cambio en el esquema de versiones.

Debido a este cambio, el número mayor de la próxima versión mayor se habría duplicado, ya que el módulo OpenSSL FIPS ya ocupaba este número. Por lo tanto, se tomó la decisión de omitir el número de versión de OpenSSL 2.0 y continuar con OpenSSL 3.0.

OpenSSL 3.0 restauró el modo FIPS y se sometió a pruebas FIPS 140-2, pero con retrasos significativos: el esfuerzo se inició por primera vez en 2016 con el apoyo de SafeLogic [50] [51] [52] y apoyo adicional de Oracle en 2017, [53] [54] pero el proceso ha sido desafiante. [55]

El 20 de octubre de 2020, el proveedor OpenSSL FIPS 3.0 se agregó a la lista de implementación bajo prueba de CMVP, lo que reflejó un compromiso oficial con un laboratorio de pruebas para proceder con una validación FIPS 140-2. Esto dio como resultado una serie de certificaciones en los meses siguientes. [56]

Licencias

OpenSSL tenía licencia dual bajo la Licencia OpenSSL y la Licencia SSLeay, lo que significa que se pueden usar los términos de cualquiera de las dos licencias. [57] La ​​Licencia OpenSSL es la Licencia Apache 1.0 y la Licencia SSLeay tiene cierta similitud con una Licencia BSD de 4 cláusulas . Como la Licencia OpenSSL era la Licencia Apache 1.0, pero no la Licencia Apache 2.0, requiere que la frase "este producto incluye software desarrollado por el Proyecto OpenSSL para su uso en el Kit de herramientas OpenSSL" aparezca en el material publicitario y en cualquier redistribución (Secciones 3 y 6 de la Licencia OpenSSL). Debido a esta restricción, la Licencia OpenSSL y la Licencia Apache 1.0 son incompatibles con la GPL de GNU . [58] Algunos desarrolladores de GPL han agregado una excepción OpenSSL a sus licencias que permite específicamente usar OpenSSL con su sistema. GNU Wget y climm usan dichas excepciones. [59] [60] Algunos paquetes (como Deluge ) modifican explícitamente la licencia GPL agregando una sección adicional al comienzo de la licencia que documenta la excepción. [61] Otros paquetes usan GnuTLS con licencia LGPL , Botan con licencia BSD o NSS con licencia MPL , que realizan la misma tarea.

OpenSSL anunció en agosto de 2015 que requeriría que la mayoría de los colaboradores firmaran un Acuerdo de Licencia de Colaborador (CLA), y que OpenSSL eventualmente sería re-licenciado bajo los términos de la Licencia Apache 2.0 . [62] Este proceso comenzó en marzo de 2017, [63] y se completó en 2018. [64]

El 7 de septiembre de 2021, se lanzó OpenSSL 3.0.0 bajo la licencia Apache 2.0. [65]

Vulnerabilidades notables

Denegación de servicio: análisis de ASN.1

OpenSSL 0.9.6k tiene un error en el que ciertas secuencias ASN.1 activaban una gran cantidad de recursiones en máquinas Windows, descubierto el 4 de noviembre de 2003. Windows no podía manejar grandes recursiones correctamente, por lo que OpenSSL se bloqueaba como resultado. Poder enviar una cantidad arbitrariamente grande de secuencias ASN.1 causaba que OpenSSL se bloqueara como resultado.

Vulnerabilidad de grapado de OCSP

Al crear un protocolo de enlace, el cliente podría enviar un mensaje ClientHello con formato incorrecto, lo que provocaría que OpenSSL analizara más que el final del mensaje. Asignado con el identificador CVE - 2011-0014 por el proyecto CVE, esto afectó a todas las versiones de OpenSSL 0.9.8h a 0.9.8q y OpenSSL 1.0.0 a 1.0.0c. Dado que el análisis podría provocar una lectura en una dirección de memoria incorrecta, era posible que el atacante provocara un DoS . También era posible que algunas aplicaciones expusieran el contenido de las extensiones OCSP analizadas , lo que provocaba que un atacante pudiera leer el contenido de la memoria que venía después de ClientHello. [66]

Vulnerabilidad biológica ASN.1

OpenSSL es vulnerable al utilizar funciones de entrada/salida básicas (BIO) [67] o basadas en archivos para leer datos en formato DER no confiables. Esta vulnerabilidad se descubrió el 19 de abril de 2012 y se le asignó el identificador CVE CVE - 2012-2110. Si bien no afecta directamente al código SSL/TLS de OpenSSL, ninguna aplicación que utilizara funciones ASN.1 (particularmente d2i_X509 y d2i_PKCS12) se vio afectada. [68]

Ataque de recuperación de texto simple SSL, TLS y DTLS

Al manejar conjuntos de cifrados CBC en SSL, TLS y DTLS, OpenSSL fue descubierto vulnerable a un ataque de sincronización durante el procesamiento MAC. Nadhem Alfardan y Kenny Paterson descubrieron el problema y publicaron sus hallazgos [69] el 5 de febrero de 2013. A la vulnerabilidad se le asignó el identificador CVE CVE - 2013-0169.

Claves privadas predecibles (específicas de Debian)

El generador de números pseudoaleatorios de OpenSSL adquiere entropía mediante métodos de programación complejos. Para evitar que la herramienta de análisis Valgrind emitiera advertencias asociadas, un mantenedor de la distribución Debian aplicó un parche a la variante de Debian de la suite OpenSSL, que inadvertidamente rompió su generador de números aleatorios al limitar el número total de claves privadas que podía generar a 32.768. [70] [71] La versión rota se incluyó en la versión de Debian del 17 de septiembre de 2006 (versión 0.9.8c-1), comprometiendo también a otras distribuciones basadas en Debian, por ejemplo Ubuntu . Hay fácilmente disponibles exploits listos para usar . [72]

Debian informó del error el 13 de mayo de 2008. En la distribución Debian 4.0 (etch), estos problemas se solucionaron en la versión 0.9.8c-4etch3, mientras que las correcciones para la distribución Debian 5.0 (lenny) se proporcionaron en la versión 0.9.8g-9. [73]

Sangrado del corazón

Un logotipo que representa el error Heartbleed

Las versiones 1.0.1 a 1.0.1f de OpenSSL tienen un grave error de manejo de memoria en su implementación de la extensión TLS Heartbeat que podría usarse para revelar hasta 64  KB de la memoria de la aplicación con cada latido [74] [75] ( CVE - 2014-0160). Al leer la memoria del servidor web, los atacantes podrían acceder a datos confidenciales, incluida la clave privada del servidor . [76] Esto podría permitir a los atacantes decodificar comunicaciones espiadas anteriormente si el protocolo de cifrado utilizado no garantiza una confidencialidad directa perfecta . El conocimiento de la clave privada también podría permitir a un atacante montar un ataque de intermediario contra cualquier comunicación futura. [ cita requerida ] La vulnerabilidad también podría revelar partes no cifradas de las solicitudes y respuestas confidenciales de otros usuarios, incluidas las cookies de sesión y las contraseñas, lo que podría permitir a los atacantes secuestrar la identidad de otro usuario del servicio. [77]

En el momento de su divulgación el 7 de abril de 2014, se creía que alrededor del 17% o medio millón de los servidores web seguros de Internet certificados por autoridades confiables eran vulnerables al ataque. [78] Sin embargo, Heartbleed puede afectar tanto al servidor como al cliente.

Vulnerabilidad de inyección de CCS

La vulnerabilidad de inyección CCS ( CVE - 2014-0224) es una vulnerabilidad de evasión de seguridad que resulta de una debilidad en los métodos OpenSSL utilizados para el material de claves. [79]

Esta vulnerabilidad puede explotarse mediante el uso de un ataque de intermediario [80] , en el que un atacante puede descifrar y modificar el tráfico en tránsito. Un atacante remoto no autenticado podría explotar esta vulnerabilidad mediante un protocolo de enlace especialmente diseñado para forzar el uso de material de clave débil. Una explotación exitosa podría conducir a una condición de omisión de seguridad en la que un atacante podría obtener acceso a información potencialmente confidencial. El ataque solo puede realizarse entre un cliente y un servidor vulnerables.

Los clientes OpenSSL son vulnerables en todas las versiones de OpenSSL anteriores a las versiones 0.9.8za, 1.0.0m y 1.0.1h. Solo se sabe que los servidores son vulnerables en OpenSSL 1.0.1 y 1.0.2-beta1. Se recomienda a los usuarios de servidores OpenSSL anteriores a la versión 1.0.1 que actualicen la versión como medida de precaución. [81]

ClienteHola sigalgs DoS

Esta vulnerabilidad ( CVE - 2015-0291) permite a cualquier persona tomar un certificado, leer su contenido y modificarlo con precisión para aprovechar la vulnerabilidad y provocar que un certificado bloquee un cliente o servidor. Si un cliente se conecta a un servidor OpenSSL 1.0.2 y renegocia con una extensión de algoritmos de firma no válida, se produce una desreferencia de puntero nulo. Esto puede provocar un ataque DoS contra el servidor.

Un investigador de seguridad de Stanford, David Ramos, tenía un exploit privado y lo presentó al equipo de OpenSSL, que luego solucionó el problema.

OpenSSL clasificó el error como un problema de alta gravedad y señaló que la versión 1.0.2 era vulnerable. [82]

Ataque de recuperación de claves en subgrupos pequeños de Diffie-Hellman

Esta vulnerabilidad ( CVE - 2016-0701) permite, cuando se dan determinadas circunstancias, recuperar la clave privada Diffie–Hellman del servidor OpenSSL. Un investigador de Adobe System Security, Antonio Sanso, informó de la vulnerabilidad de forma privada.

OpenSSL clasificó el error como un problema de alta gravedad y señaló que solo la versión 1.0.2 se consideró vulnerable. [83]

Tenedores

SSL aglomerado

En 2009, después de las frustraciones con la API original de OpenSSL, Marco Peereboom, un desarrollador de OpenBSD en ese momento, bifurcó la API original al crear Agglomerated SSL (assl), que reutiliza la API de OpenSSL bajo el capó, pero proporciona una interfaz externa mucho más simple. [84] Desde entonces ha quedado obsoleto a la luz de la bifurcación de LibreSSL alrededor de 2016.

LibreSSL

En abril de 2014, a raíz de Heartbleed , los miembros del proyecto OpenBSD bifurcaron OpenSSL comenzando con la rama 1.0.1g, para crear un proyecto llamado LibreSSL . [85] En la primera semana de poda de la base de código de OpenSSL , se habían eliminado más de 90.000 líneas de código C de la bifurcación. [86]

AburridoSSL

En junio de 2014, Google anunció su propia bifurcación de OpenSSL denominada BoringSSL. [87] Google planea cooperar con los desarrolladores de OpenSSL y LibreSSL. [88] [89] [90] Desde entonces, Google ha desarrollado una nueva biblioteca, Tink, basada en BoringSSL. [91]

Críticas

Compatibilidad con versiones anteriores

Entre las comunidades de desarrolladores, OpenSSL es citado a menudo por introducir problemas de compatibilidad de API con cada nueva versión principal, [92] [93] [94] [95] lo que requiere adaptaciones de software que tienden a retrasar las adopciones de nuevas versiones. [96] Esto, combinado con el hecho de que las versiones anteriores generalmente se mantienen durante no más de dos años después del lanzamiento de una nueva versión principal [27] tiende a obligar a algunos proveedores a anticipar las migraciones de software muy temprano mientras aún les queda poco tiempo [97] para actualizar a una nueva versión, a veces con el riesgo de perder algo de compatibilidad con el software existente [98] [99] o arriesgarse a regresiones. [100] [101]

Retraso entre lanzamientos

Si bien las versiones con soporte a largo plazo (LTS) se mantienen durante 5 años, [11] los retrasos acumulados en los plazos de publicación tienden a obligar a los proveedores de sistemas operativos a permanecer más tiempo con la última versión con soporte, lo que deja menos margen cuando la nueva versión está disponible. Por ejemplo, OpenSSL 3.0 se esperaba inicialmente para el cuarto trimestre de 2019 [44] y finalmente se lanzó 21 meses después [27] sin extender el fin esperado del soporte para la versión 1.1.1 con soporte anterior, y esto a pesar de los cambios significativos que requirieron adaptaciones al software existente.

Regresiones significativas del rendimiento

El retraso de soporte reducido de la versión 1.1.1 mencionado anteriormente causa más preocupaciones a los usuarios cuyas cargas de trabajo son sensibles al rendimiento. Algún tiempo después de la disponibilidad general de 3.0, algunos usuarios comenzaron a informar regresiones de rendimiento graves que afectaban a esta versión en entornos multiproceso, muchos citando el uso ineficiente de bloqueos en operaciones frecuentes de bajo nivel, citando ralentizaciones de 80 a 400 veces. [102] [103] [104] [105] [106] [107] [108] [109] El equipo de OpenSSL ha creado un meta-issue para intentar centralizar los informes de tales regresiones de rendimiento masivas. [110] Aproximadamente la mitad de estos reporteros indican la imposibilidad de actualizar a 3.0 desde versiones anteriores, lo que se suma al problema causado por el tiempo de soporte limitado que queda en la versión anterior 1.1.1.

Consideración de los requisitos de los usuarios

Mientras se trabajaba en la capa de transporte de QUIC para soportar la tercera versión del protocolo HTTP , se propuso usar TLS para brindar seguridad, [111] y se identificó que serían necesarias algunas adaptaciones a las bibliotecas TLS. Dichas modificaciones se incorporaron a BoringSSL [112], que era la biblioteca que usaban principalmente los desarrolladores de QUIC en ese momento, y luego se trasladó a otras bibliotecas. [113] Rápidamente se propuso una adaptación de este trabajo a OpenSSL. [114] Si bien se inició un debate el mismo día, rápidamente se estancó y primero se bloqueó por consideraciones de licencia, [114] luego se mantuvo en espera una vez que se aclararon estas preocupaciones. Finalmente, 10 meses después, el Comité de Gestión de OpenSSL anunció en una publicación de blog [115] que este conjunto de parches no se adoptaría para la versión 3.0 por temor a que la API cambiara con el tiempo. Finalmente, más de un año después del lanzamiento planeado de la versión 3.0 que aún no se había producido, un equipo de voluntarios de Akamai y Microsoft decidió bifurcar el proyecto como QuicTLS [116] y dar soporte a estos parches sobre el código OpenSSL para desbloquear el desarrollo de QUIC. Esta acción fue generalmente bien recibida por la comunidad. Finalmente, después de que OpenSSL 3.0 fuera finalmente lanzado, el conjunto de parches de QUIC fue reconsiderado y se decidió no hacerlo, [117] causando decenas a cientos de reacciones de decepción entre la comunidad. [114] La solicitud de incorporación de cambios se cerró, mientras que los usuarios sintieron la necesidad de expresar públicamente su decepción, [118] o rogar a los proveedores de sistemas operativos que apoyaran la bifurcación alternativa de QuicTLS, [119] [120] o buscaran soluciones alternativas. [121] Finalmente, Rich Salz, cofundador de la bifurcación de QuicTLS, anunció [121] su interés en ver un proyecto Apache bifurcado de QuicTLS. Al 25 de febrero de 2023, todavía no hay ninguna biblioteca TLS compatible con QUIC con soporte a largo plazo disponible de forma predeterminada en los sistemas operativos sin necesidad de que los usuarios finales la reconstruyan ellos mismos a partir de las fuentes.

Véase también

Notas

  1. ^ Se omitió la versión principal 2.0.0 debido a su uso anterior en el módulo FIPS de OpenSSL. [29]

Referencias

  1. ^ "Lanzamiento de OpenSSL 3.3.2 · openssl/openssl" . Consultado el 4 de septiembre de 2024 .
  2. ^ "/source/license.html". www.openssl.org . Consultado el 3 de marzo de 2021 .
  3. ^ "Licencia OpenSSL | Intercambio de datos de paquetes de software (SPDX)". spdx.org .
  4. ^ Laurie, Ben (6 de enero de 1999). "ANUNCIO: OpenSSL (Toma 2". ssl-users (Lista de correo) . Consultado el 29 de octubre de 2018 .
  5. ^ "Nuevos committers". OpenSSL Software Foundation. 20 de mayo de 2019. Consultado el 11 de octubre de 2024 .
  6. ^ "Comité de gestión de OpenSSL". OpenSSL Software Foundation . Consultado el 3 de noviembre de 2019 .
  7. ^ "OpenSSL Committers". OpenSSL Software Foundation . Consultado el 3 de noviembre de 2019 .
  8. ^ Marquess, Steve (19 de enero de 2017). «Akamai patrocina TLS 1.3». openssl-announce (Lista de correo) . Consultado el 9 de noviembre de 2018 .
  9. ^ "OpenSSL – Registro de cambios". OpenSSL Software Foundation . Consultado el 26 de septiembre de 2016 .
  10. ^ "Lanzamientos de OpenSSL". GitHub . Consultado el 6 de diciembre de 2022 .
  11. ^ ab «Biblioteca OpenSSL: estrategia de lanzamiento». OpenSSL Software Foundation . Consultado el 1 de agosto de 2024 .
  12. ^ abcdefgh «Notas de la serie OpenSSL 0.9.x». GitHub . Consultado el 6 de diciembre de 2022 .
  13. ^ "Notas de la serie OpenSSL 1.0.0". GitHub . Consultado el 6 de diciembre de 2022 .
  14. ^ "Notas de la serie OpenSSL 1.0.1". GitHub . Consultado el 6 de diciembre de 2022 .
  15. ^ R. Seggelmann; M. Tuexen; M. Williams (febrero de 2012). Extensión Heartbeat de seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6520 . ISSN  2070-1721. RFC 6520. Norma propuesta. Actualizada por RFC 8447.
  16. ^ E. Rescorla (enero de 2010). Exportadores de material de claves para seguridad de la capa de transporte (TLS). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5705 . ISSN  2070-1721. RFC 5705. Norma propuesta. Actualizada por RFC 8446 y 8447.
  17. ^ D. McGrew; E. Rescorla (mayo de 2010). Extensión de seguridad de la capa de transporte de datagramas (DTLS) para establecer claves para el protocolo de transporte seguro en tiempo real (SRTP). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5764 . ISSN  2070-1721. RFC 5764. Norma propuesta. Actualizada por RFC 7983 y 9443.
  18. ^ "Notas de la serie OpenSSL 1.0.2". GitHub . Consultado el 6 de diciembre de 2022 .
  19. ^ "Notas de la serie OpenSSL 1.1.0". GitHub . Consultado el 6 de diciembre de 2022 .
  20. ^ JP. Aumasson (octubre de 2015). MJ. Saarinen (ed.). El hash criptográfico BLAKE2 y el código de autenticación de mensajes (MAC). Presentación independiente IETF . doi : 10.17487/RFC7693 . ISSN  2070-1721. RFC 7693. Informativo.
  21. ^ Y. Nir; A. Langley (junio de 2018). ChaCha20 y Poly1305 para protocolos IETF. Grupo de trabajo de investigación de Internet (IRTF). doi : 10.17487/RFC8439 . ISSN  2070-1721. RFC 8439. Informativo. RFC 7539 obsoleto .
  22. ^ ab A. Langley; M. Hamburg; S. Turner (enero de 2016). Curvas elípticas para seguridad. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7748 . ISSN  2070-1721. RFC 7748. Informativo.
  23. ^ ab Caswell, Matt (11 de septiembre de 2018). "Se lanzó OpenSSL 1.1.1". Blog de OpenSSL . Fundación OpenSSL . Consultado el 11 de octubre de 2024 .
  24. ^ "Notas de la serie OpenSSL 1.1.1". GitHub . Consultado el 6 de diciembre de 2022 .
  25. ^ Caswell, Matt (8 de febrero de 2018). "Uso de TLS1.3 con OpenSSL". Blog de OpenSSL . Fundación OpenSSL . Consultado el 11 de octubre de 2024 .
  26. ^ B. Kaliski; A. Rusch; J. Johnsson; A. Rusch (noviembre de 2016). K. Moriarty (ed.). PKCS #1: Especificaciones de criptografía RSA versión 2.2. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC8017 . ISSN  2070-1721. RFC 8017. Informativo. RFC 3447 queda obsoleto .
  27. ^ abc "¡Se ha lanzado OpenSSL 3.0!". Blog de OpenSSL . Consultado el 11 de octubre de 2024 .
  28. ^ "Notas de la serie OpenSSL 3.0". GitHub . Consultado el 6 de diciembre de 2022 .
  29. ^ por Matt Caswell (28 de noviembre de 2018). "La granada de mano sagrada de Antioquía". Blog de OpenSSL . Consultado el 11 de octubre de 2024 .
  30. ^ "Lanzamiento final de OpenSSL 3.1". Blog de OpenSSL . Consultado el 11 de octubre de 2024 .
  31. ^ "Notas de la serie OpenSSL 3.1". GitHub . Consultado el 15 de marzo de 2023 .
  32. ^ "Lanzamiento final de OpenSSL 3.2.0". Blog de OpenSSL . Consultado el 11 de octubre de 2024 .
  33. ^ "Notas de la serie OpenSSL 3.2". GitHub . Consultado el 24 de noviembre de 2023 .
  34. ^ A. Ghedini; V. Vasiliev (diciembre de 2020). Compresión de certificados TLS. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC8879 . ISSN  2070-1721. RFC 8879. Norma propuesta.
  35. ^ T. Pornin (agosto de 2013). Uso determinista del algoritmo de firma digital (DSA) y del algoritmo de firma digital de curva elíptica (ECDSA). Presentación independiente. doi : 10.17487/RFC6979 . ISSN  2070-1721. RFC 6979. Informativo.
  36. ^ J. Gilmore; S. Weiler; T. Kivinen (junio de 2014). P. Wouters; H. Tschofenig (eds.). Uso de claves públicas sin procesar en la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7250 . ISSN  2070-1721. RFC 7250. Norma propuesta.
  37. ^ "Lanzamiento final de OpenSSL 3.3". Blog de OpenSSL . Consultado el 11 de octubre de 2024 .
  38. ^ abc "README de OpenSSL 1.0.0 del motor GOST". cvs.openssl.org. Archivado desde el original el 15 de abril de 2013.
  39. ^ "Código fuente de OpenSSL, directorio crypto/whrlpool". GitHub . Consultado el 29 de agosto de 2017 .
  40. ^ "Protección de datos a largo plazo con secreto hacia delante" . Consultado el 5 de noviembre de 2012 .
  41. ^ "NIST recertifica módulo de cifrado de código abierto". gcn.com. Archivado desde el original el 10 de octubre de 2007.
  42. ^ "FIPS-140". openssl.org . Consultado el 12 de noviembre de 2019 .
  43. ^ "Guía del usuario de OpenSSL para el módulo de objetos FIPS de OpenSSL v2.0" (PDF) . openssl.org. 14 de marzo de 2017 . Consultado el 12 de noviembre de 2019 .
  44. ^ ab "Actualización sobre el desarrollo de la versión 3.0, FIPS y 1.0.2 EOL". Blog de OpenSSL . 7 de noviembre de 2019 . Consultado el 11 de octubre de 2024 .
  45. ^ "Certificado n.° 1747 del programa de validación de módulos criptográficos". Centro de recursos de seguridad informática . 11 de octubre de 2016.
  46. ^ "Certificado n.° 2398 del programa de validación de módulos criptográficos". Centro de recursos de seguridad informática . 11 de octubre de 2016.
  47. ^ "Certificado n.° 2473 del programa de validación de módulos criptográficos". Centro de recursos de seguridad informática . 11 de octubre de 2016.
  48. ^ "Resultados de búsqueda del programa de validación de módulos criptográficos". Centro de recursos de seguridad informática . 11 de octubre de 2016.
  49. ^ "Resultados de búsqueda del programa de validación de módulos criptográficos". Centro de recursos de seguridad informática . 11 de octubre de 2016.
  50. ^ Schneider, Troy K. (20 de julio de 2016). "Obtención de la aprobación gubernamental de un OpenSSL más seguro". GCN: Tecnología, herramientas y tácticas para la TI del sector público .
  51. ^ Waterman, Shaun (21 de julio de 2016). "SafeLogic salva el día en el uso de OpenSSL por parte de los federales". FedScoop .
  52. ^ Rashid, Fahmida Y. (26 de julio de 2016). "OpenSSL rediseñado en camino a la validación gubernamental". InfoWorld .
  53. ^ Wells, Joyce (3 de agosto de 2017). "Oracle, SafeLogic y OpenSSL unen fuerzas para actualizar el módulo FIPS". Tendencias y aplicaciones de bases de datos .
  54. ^ Kerner, Sean Michael (4 de agosto de 2017). "Oracle se une a SafeLogic para desarrollar un módulo FIPS para la seguridad de OpenSSL". eWeek .
  55. ^ "Lanzamiento de OpenSSL 3.0 Alpha7". Blog de OpenSSL . 20 de octubre de 2020 . Consultado el 11 de octubre de 2024 .
  56. ^ "Programa de validación de módulos criptográficos: OpenSSL". Centro de recursos de seguridad informática . 11 de octubre de 2016.
  57. ^ "OpenSSL: Código fuente, licencia". openssl.org.
  58. ^ "Licencias – Free Software Foundation". fsf.org.
  59. ^ "WGET 1.10.2 para Windows (win32)". users.ugent.be. Archivado desde el original el 2 de enero de 2008.
  60. ^ "Lanzamientos de código fuente y binarios". climm.org. Archivado desde el original el 12 de febrero de 2011. Consultado el 30 de noviembre de 2010 .
  61. ^ "Archivo de LICENCIA de Deluge". deluge-torrent.org . Consultado el 24 de enero de 2013 .
  62. ^ Salz, Rich (1 de agosto de 2015). "Acuerdos de licencia y cambios en camino". openssl.org . Consultado el 11 de octubre de 2024 .
  63. ^ "Renovación de la licencia de OpenSSL con la licencia Apache v. 2.0 para fomentar un uso más amplio con otros proyectos y productos FOSS". 23 de marzo de 2017. Archivado desde el original el 18 de julio de 2017 . Consultado el 6 de agosto de 2018 .
  64. ^ Lee, Victoria; Radcliffe, Mark; Stevenson, Chris (5 de febrero de 2019). «Top 10 FOSS legal developments of 2018». Opensource.com, Red Hat . Archivado desde el original el 5 de febrero de 2019. Consultado el 28 de septiembre de 2019. El proyecto OpenSSL anunció que había completado su cambio de la licencia OpenSSL/SSLeay a la licencia de software Apache versión 2 (ASLv2).
  65. ^ "Cambio de licencia de OpenSSL 3.0". 22 de septiembre de 2021. Consultado el 24 de septiembre de 2021 .
  66. ^ "Las actualizaciones de OpenSSL solucionan vulnerabilidades de seguridad críticas". 9 de agosto de 2014. Consultado el 25 de agosto de 2014 .
  67. ^ "Vulnerabilidad de desbordamiento de montón en OpenSSL ASN.1 asn1_d2i_read_bio()". Cisco.
  68. ^ "Vulnerabilidad de ASN1 BIO". OpenSSL.
  69. ^ "Sobre la seguridad de RC4 en TLS". Departamento de Seguridad de la Información de Royal Holloway.
  70. ^ "research!rsc: Lecciones del fiasco de Debian/OpenSSL". research.swtch.com . Consultado el 12 de agosto de 2015 .
  71. ^ "SSLkeys". Wiki de Debian . Consultado el 19 de junio de 2015 .
  72. ^ "Debian OpenSSL – Predictable PRNG Bruteforce SSH Exploit Python". Base de datos de exploits . 1 de junio de 2008. Consultado el 12 de agosto de 2015 .
  73. ^ "DSA-1571-1 openssl – generador de números aleatorios predecibles". Proyecto Debian . 13 de mayo de 2008.
  74. ^ OpenSSL.org (7 de abril de 2014). «OpenSSL Security Advisory [07 Apr 2014]» (Aviso de seguridad de OpenSSL [07 de abril de 2014]) . Consultado el 9 de abril de 2014 .
  75. ^ OpenSSL (7 de abril de 2014). «TLS heartbeat read overrun (CVE-2014-0160)» ( Desbordamiento de lectura de latidos de TLS [CVE-2014-0160] ). Consultado el 8 de abril de 2014 .
  76. ^ Codenomicon Ltd (8 de abril de 2014). "Heartbleed Bug" . Consultado el 8 de abril de 2014 .
  77. ^ "¿Por qué Heartbleed es peligroso? Explotación de CVE-2014-0160". IPSec.pl. 2014. Archivado desde el original el 8 de abril de 2014. Consultado el 8 de abril de 2014 .
  78. ^ Mutton, Paul (8 de abril de 2014). "Medio millón de sitios web de amplia confianza son vulnerables al error Heartbleed". Netcraft Ltd. Consultado el 8 de abril de 2014 .
  79. ^ "OpenSSL sigue revelando más fallas: se han encontrado más vulnerabilidades críticas". Cyberoam Threat Research Labs. 2014. Archivado desde el original el 19 de junio de 2014. Consultado el 13 de junio de 2014 .
  80. ^ "CVE-2014-0224". CVE. 2014.
  81. ^ "Aviso de seguridad de OpenSSL". OpenSSL. 5 de junio de 2014.
  82. ^ "OpenSSL corrige una vulnerabilidad de denegación de servicio grave". Brandon Stosh. 20 de marzo de 2015.
  83. ^ Goodlin, Dan (28 de enero de 2016). "Un error de alta gravedad en OpenSSL permite a los atacantes descifrar el tráfico HTTPS". Ars Technica .
  84. ^ "security/assl: assl-1.5.0p0v0 – ocultar la horrible API SSL en una interfaz sensata". Puertos OpenBSD . 22 de mayo de 2014 . Consultado el 10 de febrero de 2015 .
  85. ^ "OpenBSD ha iniciado una limpieza y desmantelamiento masivo de OpenSSL". OpenBSD journal . 15 de abril de 2014.
  86. ^ "OpenBSD bifurca, poda y corrige OpenSSL". ZDNet. 21 de abril de 2014. Consultado el 21 de abril de 2014 .
  87. ^ "BoringSSL". Git en Google .
  88. ^ "Google presenta una 'bifurcación' independiente de OpenSSL llamada 'BoringSSL'". Ars Technica . 21 de junio de 2014.
  89. ^ "BoringSSL". Blog de Adam Langley . 20 de junio de 2014.
  90. ^ "BoringSSL quiere acabar con el entusiasmo que dio origen a Heartbleed". Sophos. 24 de junio de 2014.
  91. ^ Buchanan, Bill (30 de agosto de 2018). "Adiós OpenSSL y hola a Google Tink". Medium . Consultado el 4 de abril de 2019 .
  92. ^ "OpenSSL 3 interrumpe la compilación de webpack · Problema n.° 22305 · brave/brave-browser". GitHub .
  93. ^ "openssl versión 3.0 en arch? / Rincón de novatos / Foros de Arch Linux". bbs.archlinux.org .
  94. ^ "Planes de transición a OpenSSL 3.0". Centro comunitario de Ubuntu . 6 de abril de 2022.
  95. ^ "Compatibilidad con OpenSSL 3.0 · Problema n.° 597 · nginx/unit". GitHub .
  96. ^ "Nuestro futuro con OpenSSL". Discusiones en Python.org . 28 de noviembre de 2022.
  97. ^ "La experiencia de incorporar OpenSSL 3.0 a Red Hat Enterprise Linux y Fedora". www.redhat.com .
  98. ^ "Compilar con OpenSSL 3.X". groups.google.com .
  99. ^ "Agente de administración de ESET (RHEL 9.x, OpenSSL 3.0.x)". Foro de seguridad de ESET . 6 de junio de 2022.
  100. ^ "Problema 46313: SSLObject no genera SSLEOFError en OpenSSL 3 - Rastreador de Python". bugs.python.org .
  101. ^ "RHEL 9: openssl (RHSA-2022:6224)". www.tenable.com .
  102. ^ "Degradación masiva del rendimiento en OpenSsl 3.0 si se utiliza en una aplicación de servidor multiproceso pesada · Problema n.° 17064 · openssl/openssl". GitHub .
  103. ^ "Problema de rendimiento con Openssl 3.0 en aplicaciones multiproceso al usar d2i_x509 · Problema n.° 17950 · openssl/openssl". GitHub .
  104. ^ "Grave degradación de la eficiencia en la carga de credenciales en comparación con la versión 1.1.1 · Problema n.° 18814 · openssl/openssl". GitHub .
  105. ^ "El rendimiento de la versión 3.0 se ha reducido debido al bloqueo · Problema n.° 20286 · openssl/openssl". GitHub .
  106. ^ "Alto uso de CPU para solicitudes SSL salientes después de actualizar de v16.15.0 a v18.1.0 · Problema n.° 43128 · nodejs/node". GitHub .
  107. ^ "Degradación masiva del rendimiento en el proveedor FIPS OpenSsl 3.0 · Problema n.° 18472 · openssl/openssl". GitHub .
  108. ^ "Mediciones de rendimiento · Problema n.° 16791 · openssl/openssl". GitHub .
  109. ^ "La decodificación PEM/DER de claves privadas RSA PKCS8 es 80 veces más lenta en 3.0 · Problema n.° 15199 · openssl/openssl". GitHub .
  110. ^ "Problemas de rendimiento 3.0 · Problema n.° 17627 · openssl/openssl". GitHub .
  111. ^ Thomson, Martin; Turner, Sean (14 de enero de 2017). "Uso de la seguridad de la capa de transporte (TLS) para proteger QUIC" – vía IETF.
  112. ^ "221 - boringssl - Una bifurcación de OpenSSL diseñada para satisfacer las necesidades de Google - Monorail". bugs.chromium.org .
  113. ^ "Compatibilidad con la API QUIC TLS (#826) · Problemas · gnutls / GnuTLS · GitLab". GitLab . 4 de septiembre de 2019.
  114. ^ abc "WIP: soporte para QUIC maestro por tmshort · Solicitud de incorporación de cambios n.° 8797 · openssl/openssl". GitHub .
  115. ^ "QUIC y OpenSSL". Blog de OpenSSL . Consultado el 11 de octubre de 2024 .
  116. ^ "quictls anuncia en twitter".
  117. ^ "Requisitos de publicación de OMC". www.mail-archive.com .
  118. ^ "La API QUIC de OpenSSL no se puede proporcionar | daniel.haxx.se". 25 de octubre de 2021.
  119. ^ Tarreau, Willy (27 de octubre de 2021). "[Pkg-openssl-devel] ¿Hay alguna intención de mantener quictls?".
  120. ^ "Error n.º 1011391: openssl: por favor, admita el conjunto de parches de quictls". groups.google.com .
  121. ^ ab "Compatibilidad con HTTP/3 · Problema n.° 680 · haproxy/haproxy". GitHub .

Enlaces externos