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 .
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 [actualizar], [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]
OpenSSL admite varios algoritmos criptográficos diferentes:
( El secreto directo perfecto se admite mediante el uso de la curva elíptica Diffie-Hellman desde la versión 1.0. [40] )
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]
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]
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.
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]
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]
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.
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]
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.
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]
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]
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]
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.
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]
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]
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 [97] tiende a obligar a algunos proveedores a anticipar las migraciones de software muy temprano mientras aún les queda poco tiempo [98] para actualizar a una nueva versión, a veces con el riesgo de perder algo de compatibilidad con el software existente [99] [100] o arriesgarse a regresiones. [101] [102]
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 [103] y finalmente se lanzó 21 meses después [97] 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.
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 multi-thread, muchos citando el uso ineficiente de bloqueos en operaciones frecuentes de bajo nivel, citando ralentizaciones de 80 a 400 veces. [104] [105] [106] [107] [108] [109] [110] [111] El equipo de OpenSSL ha creado un meta-issue para intentar centralizar los informes de tales regresiones de rendimiento masivas. [112] 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.
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, [113] y se identificó que serían necesarias algunas adaptaciones a las bibliotecas TLS. Dichas modificaciones se incorporaron a BoringSSL [114], que era la biblioteca que usaban principalmente los desarrolladores de QUIC en ese momento, y luego se trasladó a otras bibliotecas. [115] Rápidamente se propuso una adaptación de este trabajo a OpenSSL. [116] Si bien se inició cierta discusión el mismo día, rápidamente se estancó y primero se bloqueó por consideraciones de licencia, [116] 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 [117] 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 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 [118] 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, [119] causando decenas a cientos de reacciones de decepción entre la comunidad. [116] La solicitud de incorporación de cambios se cerró, mientras que los usuarios sintieron la necesidad de expresar públicamente su decepción, [120] o rogar a los proveedores de sistemas operativos que dieran soporte a la bifurcación alternativa de QuicTLS, [121] [122] o buscaran soluciones alternativas. [123] Finalmente, Rich Salz, cofundador de la bifurcación de QuicTLS, anunció [123] 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.
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}