Comparación de implementaciones de TLS

El protocolo Transport Layer Security (TLS) permite proteger las comunicaciones dentro y fuera de las redes. Esta comparativa de implementaciones de TLS analiza varias de las bibliotecas más destacadas . Existen diversas implementaciones de TLS que son software libre y de código abierto .

Todas las categorías de comparación utilizan la versión estable de cada implementación que se detalla en la sección de descripción general. La comparación se limita a las características directamente relacionadas con el protocolo TLS.

Existen varias versiones del protocolo TLS. SSL 2.0 es una versión obsoleta ^{[ 23 ]} con importantes debilidades. SSL 3.0 (1996) y TLS 1.0 (1999) son sucesores con dos debilidades en el relleno CBC que fueron explicadas en 2001 por Serge Vaudenay. ^{[ 24 ]} TLS 1.1 (2006) solucionó solo uno de los problemas, cambiando a vectores de inicialización (IV) aleatorios para los cifrados de bloques CBC, mientras que el uso más problemático de mac-pad-encrypt en lugar del seguro pad-mac-encrypt se abordó con RFC 7366. ^{[ 25 ]} Una solución alternativa para SSL 3.0 y TLS 1.0, aproximadamente equivalente a los IV aleatorios de TLS 1.1, fue ampliamente adoptada por muchas implementaciones a finales de 2011. ^{[ 26 ]} En 2014, se descubrió la vulnerabilidad POODLE de SSL 3.0, que aprovecha las vulnerabilidades conocidas en CBC y una negociación de reserva insegura utilizada en los navegadores. ^{[ 27 ]}

TLS 1.2 (2008) introdujo un método para identificar el hash utilizado para las firmas digitales. Si bien permitió el uso de funciones hash más robustas para firmas digitales en el futuro (rsa, sha256/sha384/sha512) en comparación con la opción conservadora de SSL 3.0 (rsa, sha1+md5), el cambio en el protocolo TLS 1.2 debilitó de forma inadvertida y sustancial las firmas digitales predeterminadas y proporciona (rsa, sha1) e incluso (rsa, md5). ^{[ 28 ]}

Datagram Transport Layer Security (DTLS o Datagram TLS) 1.0 es una modificación de TLS 1.1 para una capa de transporte orientada a paquetes, donde se debe tolerar la pérdida y el reordenamiento de paquetes. La revisión DTLS 1.2, basada en TLS 1.2, se publicó en enero de 2012. ^{[ 29 ]}

TLS 1.3 (2018), especificado en la RFC 8446, incluye importantes optimizaciones y mejoras de seguridad. QUIC (2021), especificado en la RFC 9000, y DTLS 1.3 (2022), especificado en la RFC 9147, se basan en TLS 1.3. La publicación de TLS 1.3 y DTLS 1.3 dejó obsoletas las versiones TLS 1.2 y DTLS 1.3.

Cabe destacar que existen vulnerabilidades conocidas en SSL 2.0 y SSL 3.0. En 2021, la IETF publicó el RFC 8996, que también prohíbe la negociación de TLS 1.0, TLS 1.1 y DTLS 1.0 debido a vulnerabilidades conocidas. El NIST SP 800-52 exige compatibilidad con TLS 1.3 para enero de 2024. La compatibilidad con TLS 1.3 implica que dos nodos compatibles nunca negociarán TLS 1.2.

Los componentes necesarios para la criptografía de la suite B de la NSA (RFC 6460) son:

• Estándar de Cifrado Avanzado (AES) con claves de 128 y 256 bits. Para el flujo de tráfico, se debe usar AES con el Modo Contador (CTR) para tráfico de bajo ancho de banda o con el Modo Galois/Contador (GCM) para tráfico de alto ancho de banda (véase Modos de operación de cifrado por bloques ) — cifrado simétrico
• Algoritmo de firma digital de curva elíptica (ECDSA) — firmas digitales
• Diffie-Hellman de curva elíptica (ECDH): acuerdo clave
• Algoritmo de hash seguro 2 (SHA-256 y SHA-384) — resumen del mensaje

Según la norma CNSSP-15, la curva elíptica de 256 bits (especificada en FIPS 186-2), SHA-256 y AES con claves de 128 bits son suficientes para proteger información clasificada hasta el nivel Secreto , mientras que la curva elíptica de 384 bits (especificada en FIPS 186-2), SHA-384 y AES con claves de 256 bits son necesarias para la protección de información de Alto Secreto .

Cabe señalar que ciertas certificaciones han recibido serias críticas negativas de personas que están involucradas en ellas. ^{[ 71 ]}

Esta sección enumera las funcionalidades de verificación de certificados disponibles en las distintas implementaciones.

Notas

Esta sección enumera las curvas elípticas compatibles con cada implementación.

Cabe destacar que la vulnerabilidad de seguridad CRIME aprovecha la compresión TLS, por lo que las implementaciones conservadoras no habilitan la compresión a nivel TLS. La compresión HTTP no está relacionada con esta vulnerabilidad ni se ve afectada por ella, pero sí es aprovechada por el ataque BREACH, que está relacionado .

En esta sección se enumeran las extensiones que admite cada implementación. Cabe destacar que la extensión de renegociación segura es fundamental para la seguridad del cliente HTTPS . Los clientes TLS que no la implementan son vulnerables a ataques, independientemente de si implementan o no la renegociación TLS.

Esta sección enumera la capacidad conocida de una implementación para aprovechar los conjuntos de instrucciones de la CPU que optimizan el cifrado, o para utilizar dispositivos específicos del sistema que permiten el acceso al hardware criptográfico subyacente para la aceleración o la separación de datos.

Esta sección enumera la capacidad de una implementación para aprovechar los backends específicos del sistema operativo disponibles, o incluso los backends proporcionados por otra implementación.

• SCTP — con soporte DTLS
• DCCP — con soporte DTLS
• SRTP — con soporte para DTLS (DTLS-SRTP) y Protocolo de control de transporte seguro en tiempo real (SRTCP)