OpenSSL es una biblioteca de software para aplicaciones que proporcionan comunicaciones seguras a través de redes informáticas contra escuchas ilegales e identifican a la parte en el otro extremo. Es ampliamente utilizado 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. Se encuentran disponibles contenedores que permiten el uso de la biblioteca OpenSSL en una variedad de lenguajes informáticos.
La OpenSSL Software Foundation (OSF) representa el proyecto OpenSSL en la mayoría de las capacidades legales, incluidos acuerdos de licencia de contribuyente, gestión de donaciones, etc. OpenSSL Software Services (OSS) también representa el proyecto OpenSSL para 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 .
El proyecto OpenSSL se fundó en 1998 para proporcionar un conjunto gratuito de herramientas de cifrado para el código utilizado en Internet. Está basado en una bifurcación de SSLeay de Eric Andrew Young y Tim Hudson, que extraoficialmente finalizó su desarrollo el 17 de diciembre de 1998, cuando Young y Hudson se pusieron a trabajar para RSA Security . Los miembros fundadores iniciales fueron Mark Cox, Ralf Engelschall, Stephen Henson, Ben Laurie y Paul Sutton. [4]
En mayo de 2019 [update], [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). Sólo hay dos empleados a tiempo completo (becarios) y el resto son voluntarios.
El proyecto tiene un presupuesto de menos de 1 millón de dólares al año y depende principalmente de donaciones. El desarrollo de TLS 1.3 fue patrocinado por Akamai . [8]
OpenSSL admite varios algoritmos criptográficos diferentes:
( El secreto directo perfecto se admite mediante la curva elíptica Diffie-Hellman desde la versión 1.0. [30] )
FIPS 140 es un programa federal de EE. UU. para la prueba y certificación de módulos criptográficos. Uno de los primeros certificados FIPS 140-1 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. [31] OpenSSL 1.0.2 admitía el uso del módulo de objetos FIPS (FOM) OpenSSL, que fue creado para ofrecer algoritmos aprobados por FIPS en un entorno validado por FIPS 140-2. [32] [33] OpenSSL decidió polémicamente categorizar la arquitectura 1.0.2 como 'fin de vida útil' 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 disponible actualmente con soporte para Modo FIPS. [34] Como resultado del EOL, muchos usuarios no pudieron implementar correctamente el FOM 2.0 y dejaron de cumplir porque no obtuvieron soporte extendido para la arquitectura 1.0.2, aunque el FOM en sí permaneció validado durante ocho meses más.
El módulo de objetos FIPS 2.0 permaneció validado según FIPS 140-2 en varios formatos hasta el 1 de septiembre de 2020, cuando NIST desaprobó el uso de FIPS 186-2 para el estándar de firma digital y designó todos los módulos que no cumplían como "históricos". Esta designación incluye una advertencia a las agencias federales de que no deben incluir el módulo en ninguna adquisición nueva. Las tres validaciones de OpenSSL se incluyeron en la obsolescencia: el módulo de objetos FIPS de OpenSSL (certificado n.° 1747), [35] el módulo de objetos FIPS de OpenSSL SE (certificado n.° 2398), [36] y el módulo de objetos FIPS de OpenSSL RE (certificado n.° 2473). ). [37] 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 desaprobación, como BoringCrypto de Google [38] y CryptoComply de SafeLogic. [39]
El Comité de Gestión de OpenSSL anunció un cambio en el esquema de versiones.
Debido a este cambio, el número principal de la próxima versión principal 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 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 soporte de SafeLogic [40] [41] [42] y soporte adicional de Oracle en 2017, [43] [44] pero el proceso ha sido un desafío. [45]
El 20 de octubre de 2020, el proveedor OpenSSL FIPS 3.0 se agregó a la lista de implementación en prueba de CMVP, lo que reflejó un compromiso oficial con un laboratorio de pruebas para proceder con una validación FIPS 140-2. Esto resultó en una gran cantidad de certificaciones en los meses siguientes. [46]
OpenSSL tenía doble licencia bajo la licencia OpenSSL y la licencia SSLeay, lo que significa que se pueden utilizar los términos de cualquiera de las licencias. [47] 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 GNU GPL . [48] 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 utilizan este tipo de excepciones. [49] [50] 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. [51] Otros paquetes utilizan 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 contribuyentes firmaran un Acuerdo de licencia de colaborador (CLA) y que OpenSSL eventualmente volvería a obtener la licencia según los términos de la Licencia Apache 2.0 . [52] Este proceso comenzó en marzo de 2017, [53] y finalizó en 2018. [54]
El 7 de septiembre de 2021, se lanzó OpenSSL 3.0.0 bajo la licencia Apache 2.0. [55]
OpenSSL 0.9.6k tiene un error en el que ciertas secuencias ASN.1 desencadenaban una gran cantidad de recursiones en máquinas con Windows, descubierto el 4 de noviembre de 2003. Windows no podía manejar grandes recursiones correctamente, por lo que OpenSSL fallaba como resultado. Ser capaz de enviar cantidades arbitrarias de secuencias ASN.1 provocaría que OpenSSL fallara.
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 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 conducir a 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 llevaría a que un atacante pudiera leer el contenido de la memoria que venía después de ClientHello. [56]
Cuando se utilizan funciones básicas de entrada/salida (BIO) [57] o ARCHIVO para leer datos en formato DER que no son de confianza, OpenSSL es vulnerable. Esta vulnerabilidad se descubrió el 19 de abril de 2012 y se le asignó el identificador CVE CVE - 2012-2110. Si bien no afectó directamente el código SSL/TLS de OpenSSL, cualquier aplicación que usara funciones ASN.1 (particularmente d2i_X509 y d2i_PKCS12) tampoco se vio afectada. [58]
Al manejar conjuntos de cifrado CBC en SSL, TLS y DTLS, se encontró que OpenSSL era vulnerable a un ataque de sincronización durante el procesamiento MAC. Nadhem Alfardan y Kenny Paterson descubrieron el problema y publicaron sus hallazgos [59] el 5 de febrero de 2013. A la vulnerabilidad se le asignó el identificador CVE CVE - 2013-0169.
El generador de números pseudoaleatorios de OpenSSL adquiere entropía utilizando métodos de programación complejos. Para evitar que la herramienta de análisis Valgrind emita advertencias asociadas, un responsable 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. [60] [61] 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 otras distribuciones basadas en Debian, por ejemplo Ubuntu . Los exploits listos para usar están fácilmente disponibles. [62]
Debian informó el 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. [63]
Las versiones de OpenSSL 1.0.1 a 1.0.1f tienen un error grave en el manejo de la memoria en su implementación de TLS Heartbeat Extension que podría usarse para revelar hasta 64 KB de la memoria de la aplicación con cada latido [64] [65] ( CVE - 2014 -0160). Al leer la memoria del servidor web, los atacantes podrían acceder a datos confidenciales, incluida la clave privada del servidor . [66] Esto podría permitir a los atacantes decodificar comunicaciones escuchadas anteriormente si el protocolo de cifrado utilizado no garantiza un secreto directo perfecto . El conocimiento de la clave privada también podría permitir a un atacante organizar un ataque de intermediario contra cualquier comunicación futura. [ cita necesaria ] La vulnerabilidad también podría revelar partes no cifradas de solicitudes y respuestas confidenciales de otros usuarios, incluidas cookies de sesión y contraseñas, lo que podría permitir a los atacantes secuestrar la identidad de otro usuario del servicio. [67]
Cuando se reveló el 7 de abril de 2014, se creía que alrededor del 17% o medio millón de servidores web seguros de Internet certificados por autoridades confiables habían sido vulnerables al ataque. [68] Sin embargo, Heartbleed puede afectar tanto al servidor como al cliente.
La vulnerabilidad de inyección CCS ( CVE - 2014-0224) es una vulnerabilidad de elusión de seguridad que resulta de una debilidad en los métodos OpenSSL utilizados para el material de claves. [69]
Esta vulnerabilidad se puede explotar mediante el uso de un ataque de intermediario, [70] donde un atacante puede descifrar y modificar el tráfico en tránsito. Un atacante remoto no autenticado podría aprovechar esta vulnerabilidad mediante el uso de 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 elusión de la seguridad en la que un atacante podría obtener acceso a información potencialmente confidencial. El ataque sólo se puede realizar 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. Sólo 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 como medida de precaución. [71]
Esta vulnerabilidad ( CVE - 2015-0291) permite a cualquier persona tomar un certificado, leer su contenido y modificarlo con precisión para abusar de la vulnerabilidad y provocar que un certificado bloquee a 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 se encontró vulnerable. [72]
Esta vulnerabilidad ( CVE - 2016-0701) permite, cuando se dan algunas circunstancias particulares, recuperar la clave privada Diffie-Hellman del servidor OpenSSL. Un investigador de Adobe System Security, Antonio Sanso, informó en privado sobre la vulnerabilidad.
OpenSSL clasificó el error como un problema de alta gravedad y señaló que solo la versión 1.0.2 resultó vulnerable. [73]
En 2009, después de frustraciones con la API OpenSSL original, Marco Peereboom, un desarrollador de OpenBSD en ese momento, bifurcó la API original creando Agglomerated SSL (assl), que reutiliza la API OpenSSL internamente, pero proporciona una interfaz externa mucho más simple. [74] Desde entonces ha quedado obsoleto a la luz de la bifurcación LibreSSL alrededor de 2016.
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 . [75] En la primera semana de poda del código base de OpenSSL , se eliminaron más de 90.000 líneas de código C de la bifurcación. [76]
En junio de 2014, Google anunció su propia bifurcación de OpenSSL denominada BoringSSL. [77] Google planea cooperar con los desarrolladores de OpenSSL y LibreSSL. [78] [79] [80] Desde entonces, Google ha desarrollado una nueva biblioteca, Tink, basada en BoringSSL. [81]
Entre las comunidades de desarrolladores, OpenSSL es a menudo citado por presentar una pequeña falla en la compatibilidad de API con cada nueva versión principal, [82] [83] [84] [85] , lo que requiere adaptaciones de software que tienden a retrasar la adopción de nuevas versiones. [86] Esto, combinado con el hecho de que las versiones anteriores generalmente se mantienen durante no más de dos años después de que se lanza una nueva versión importante [87] tiende a obligar a algunos proveedores a anticipar las migraciones de software muy temprano y aún les queda poco tiempo [88 ] para actualizar a una nueva versión, a veces con el riesgo de perder parte de la compatibilidad con el software existente [89] [90] o arriesgarse a sufrir regresiones. [91] [92]
Si bien las versiones LTS ( soporte a largo plazo ) se mantienen durante 5 años, [93] los retrasos acumulados en los plazos de lanzamiento tienden a obligar a los proveedores de sistemas operativos a permanecer más tiempo en la última versión compatible, dejando menos margen cuando la nueva versión está disponible. Por ejemplo, OpenSSL 3.0 se esperaba inicialmente para el cuarto trimestre de 2019 [94] y finalmente se publicó 21 meses después [87] sin extender el fin esperado del soporte para la versión 1.1.1 previamente admitida, y esto a pesar de los cambios significativos que requirieron adaptaciones al software existente. .
La reducción del retraso en el soporte de la versión 1.1.1 mencionada 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 graves regresiones de rendimiento 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. [95] [96] [97] [98] [99] [100] [101] [102] El equipo de OpenSSL ha creado un meta-problema para tratar de centralizar informes de regresiones de rendimiento tan masivas. [103] 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 limitado de soporte que quedaba en la versión anterior 1.1.1.
Mientras se trabajaba en la capa de transporte QUIC para admitir la tercera versión del protocolo HTTP , se propuso utilizar TLS para proporcionar seguridad [104] e identificó que se necesitarían algunas adaptaciones a las bibliotecas TLS. Dichas modificaciones se llevaron a BoringSSL [105] , que era la biblioteca utilizada principalmente por los desarrolladores de QUIC en ese entonces, y luego se transfirió a otras bibliotecas. [106] Rápidamente se propuso una adaptación de este trabajo a OpenSSL. [107] Si bien algunas discusiones comenzaron el mismo día, rápidamente se estancaron y primero se bloquearon por consideraciones de licencia, [107] luego se mantuvieron en suspenso 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 [108] que este conjunto de parches no se adoptaría para 3.0 por temor a que la API cambiara con el tiempo. Finalmente, más de un año después del lanzamiento previsto de 3.0, que aún no llegaba, un equipo de voluntarios de Akamai y Microsoft decidió bifurcar el proyecto como QuicTLS [109] y admitir estos parches además del código OpenSSL para desbloquear el desarrollo de QUIC. . Esta acción fue generalmente bien recibida por la comunidad. Finalmente, después de que finalmente se lanzó OpenSSL 3.0, el conjunto de parches QUIC fue reconsiderado y se decidió no hacerlo, [110] causando decenas a cientos de reacciones de decepción entre la comunidad. [107] La solicitud de extracción se cerró, mientras que los usuarios sintieron la necesidad de expresar públicamente su decepción, [111] o rogar a los proveedores de sistemas operativos que admitieran la bifurcación alternativa QuicTLS, [112] [113] o buscar soluciones alternativas. [114] Finalmente, Rich Salz, cofundador de la bifurcación QuicTLS, anunció [114] su interés en ver un proyecto Apache bifurcado desde QuicTLS. Al 25 de febrero de 2023, todavía no hay ninguna biblioteca TLS compatible a largo plazo compatible con QUIC disponible de forma predeterminada en los sistemas operativos sin necesidad de que los usuarios finales la reconstruyan ellos mismos a partir de las fuentes.
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).
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}