Comparación de implementaciones TLS
El protocolo de la capa de seguridad de transporte Transport Layer Security (TLS)  provee la capacidad de asegurar la comunicación a través de las redes. Esta comparación de implementaciones TLS  contrasta varias de las bibliotecas más notables. Hay varias implementaciones de TLS que son software libre y de código abierto.

Todas las categorías de comparación usan la versión estable de cada implementación listada en la sección de descripción general. La comparación está limitada a características que se relacionan directamente con el protocolo TLS.

Descripción general

Soporte de protocolo 
Existen varias versiones del protocolo TLS. SSL 2.0 es una versión obsoleta del protocolo con debilidades significativas. SSL 3.0 (1996) y TLS 1.0 (1999) le suceden con dos desventajas en relleno-CBC, las cuales fueron explicadas en el 2001 por Serge Vaudenay.  TLS 1.1 (2006) solo corrigió uno de los problemas al alternar aleatoriamente los vectores de inicialización (IV) para los bloques de cifrado CBC, mientras que el uso más problemático del cifrado mac-pad, no del cifrado pad-mac (el cual es más seguro), fue abordado con RFC7366.  Una solución alternativa para SSL 3.0 y TLS 1.0, aproximadamente equivalente a los IVs aleatorios del TLS 1.1, fue adoptada abiertamente por varias implementaciones a finales del 2011, así que desde una perspectiva de seguridad, todas las versiones existentes de TLS 1.0, 1.1 y 1.2 proveen una fuerza equivalente en el protocolo base que, hasta al menos el 2030, resultan más apropiadas para la seguridad de 128 bits de acuerdo al NIST SP800-57.  En el 2014 se descubrió la vulnerabilidad POODLE de SSL 3.0, la cual toma ventaja de la vulnerabilidades conocidas en CBC y de una negociación de respaldo insegura usada en los navegadores web.

TLS 1.2 (2008) es la versión más recientemente publicada del protocolo base, la cual introduce una forma de identificar los hashes usados para firmas digitales.  Mientras permite el uso de funciones hash más fuertes para las firmas digitales en el futuro (rsa,sha256/sha384/sha512), por encima de su alternativa más conservadora, SSL 3.0 (rsa,sha1+md5), el cambio de protocolo TLS 1.2 inadvertida y sustancialmente debilita las firmas digitales por defecto y además provee (rsa,sha1) e incluso (rsa,md5).

La capa de seguridad de transporte de datagrama (DTLS o TLS de datagrama) 1.0 es una modificación del TLS 1.1 para una capa de transporte orientada a paquetes, donde la pérdida y reordenación de paquetes deben ser toleradas. La revisión de DTLS 1.2 basada en TLS 1.2 fue publicada en enero del 2012

Cabe notar que hay vulnerabilidades conocidas en SSL 2.0 y SSL 3.0. Con la excepción de los predecibles IVs (para los cuales existe una solución alternativa), todas las vulnerabilidades conocidas en la actualidad afectan a todas las versiones de TLS 1.0/1.1/1.2 por igual.

(a) El cliente SSL 2.0 Hello está soportado aun cuando SSL 2.0 no esté respaldado o esté inhabilitado por compatibilidades atrasadas.

Criptografía de NSA Suite B 
Los componentes requeridos para la  Criptografía de NSA Suite B (RFC 6460) son:
 Estándar de Encriptación Avanzada (AES) con tamaños de clave de 128 y 256 bits. Para el flujo de tráfico, AES debería ser usado en Modo Contador (CTR) para tráfico de baja banda ancha o en Modo Contador/Galois (GCM), modo de operación para alto tráfico de banda ancha (véase modos de operación de cifrado en bloque) — encriptación simétrica
 Algoritmo de Firma Digital de Curva Elíptica (ECDSA) — firmas digitales
 Curva Elíptica Diffie–Hellman  (ECDH) — acuerdo clave
 Algoritmo 2 de Hash Protegido (SHA-256 y SHA-384) — resumen del mensaje

Por medio de CNSSP-15, la curva elíptica de 256-bit (especificada en FIPS 186-2), SHA-256, y AES, claves de 128 bits son suficientes para proteger información clasificada hasta el nivel secreto, mientras que con la curva elíptica de 384-bits (especificada en FIPS 186-2), SHA-384, y AES, claves de 256-bits son necesarias para la protección de información de alta seguridad.

Certificaciones 
Nótese que ciertas certificaciones han recibido serias críticas negativas de personas que, de hecho, han están involucradas en ellas.

Algoritmos de intercambio de claves (solo con certificado) 
Esta sección lista la funcionalidad de la verificación de certificado disponible en las distintas implementaciones.

Algoritmos de intercambio de clave (intercambio de clave alternativo)

Métodos de verificación de certificado

Algoritmos de cifrado 

 Notas

(1) Este algoritmo aún no está definido como una suite de cifrado en RFC; está como una propuesta en borrador.

(2) Solo autenticación, no encriptación.

Algoritmos obsoletos 

 Notas

(1) IDEA y DES han sido removidos del TLS 1.2

(2) 40 bits de intensidad de cifrado fueron diseñados para operar a longitudes de clave reducidas para cumplir con las regulaciones de los Estados Unidos acerca de la exportación de software criptográfico que contiene algoritmos de cifrado de alta intensidad (véase Exportación de criptografía de los Estados Unidos). Estas suites débiles están prohibidas en TLS 1.1 y versiones posteriores.

(3) Lo ataques RC4 debilitan y/o interrumpen el RC4 usado en SSL/TLS. El uso de RC4 está prohibido por el RFC 7465.

(4) Loas ataques RC4 debilitan y/o interrumpen el RC4 usado en SSL/TLS.

Curvas elípticas respaldadas 
Esta sección lista las curvas elípticas respaldadas por cada implementación.

Integridad de datos

Compresión 
Nótese que la falla de seguridad CRIME toma ventaja de la compresión TLS, así que las implementaciones conservadoras no habilitan la compresión al nivel de TLS. La compresión HTTP no está relacionada ni se ve afectada por este abuso, pero se aprovecha del relacionado ataque BREACH.

Extensiones 
En esta sección se listan las extensiones que cada implementación mantiene. Nótese que la extensión de Renegociación Segura es crítica para la seguridad del cliente HTTPS . Clientes TLS que no la implementan son vulnerables a ataques, independientemente de si el cliente implementa la renegociación TLS o no.

Criptografía asistida 
Esta sección lista las habilidades de implementación conocidas por tomar ventaja de los sets de instrucción de CPU que optimizan la encriptación, o que utilizan dispositivos específicos del sistema que permiten accesar el hardware criptográfico subyacente para la aceleración o separación de datos.

Soporte basado en sistema 
Esta sección lista la habilidad de cada implementación de aprovechar el soporte específico del sistema operativo disponible, o incluso el soporte provisto por alguna otra implementación.

Módulo criptográfico/Token de soporte

Dependencias de código

Entorno de desarrollo

Problemas de portabilidad

Véase también 
 Stream Control Transmission Protocol
 Protocolo de Control de Congestión de Datagramas
 Secure Real-time Transport Protocol

Referencias 

Software criptográfico
Security software comparisons
Transport Layer Security implementation
El protocolo de la capa de seguridad de transporte Transport Layer Security ( TLS ) provee la capacidad de asegurar la comunicación a través de las redes . Esta comparación de implementaciones TLS contrasta varias de las bibliotecas más notables . Hay varias implementaciones de TLS que son software libre y de código abierto . Todas las categorías de comparación usan la versión estable de cada implementación listada en la sección de descripción general . La comparación está limitada a características que se relacionan directamente con el protocolo TLS . Descripción general Soporte de protocolo Existen varias versiones del protocolo TLS . SSL0 es una versión obsoleta del protocolo con debilidades significativas . SSL0y TLS0le suceden con dos desventajas en relleno-CBC , las cuales fueron explicadas en elpor Serge Vaudenay . TLS1solo corrigió uno de los problemas al alternar aleatoriamente los vectores de inicialización ( IV ) para los bloques de cifrado CBC , mientras que el uso más problemático del cifrado mac-pad , no del cifrado pad-mac ( el cual es más seguro ) , fue abordado con RFC7366 . Una solución alternativa para SSL0 y TLS0 , aproximadamente equivalente a los IVs aleatorios del TLS1 , fue adoptada abiertamente por varias implementaciones a finales del así que desde una perspectiva de seguridad , todas las versiones existentes de TLS0,1 y2 proveen una fuerza equivalente en el protocolo base que , hasta al menos el resultan más apropiadas para la seguridad debits de acuerdo al NIST SP800-57 . En else descubrió la vulnerabilidad POODLE de SSL0 , la cual toma ventaja de la vulnerabilidades conocidas en CBC y de una negociación de respaldo insegura usada en los navegadores web . TLS2es la versión más recientemente publicada del protocolo base , la cual introduce una forma de identificar los hashes usados para firmas digitales . Mientras permite el uso de funciones hash más fuertes para las firmas digitales en el futuro ( rsa,sha256/sha384/sha512 ) , por encima de su alternativa más conservadora , SSL0 ( rsa,sha1+md5 ) , el cambio de protocolo TLS2 inadvertida y sustancialmente debilita las firmas digitales por defecto y además provee ( rsa,sha1 ) e incluso ( rsa,md5 ) . La capa de seguridad de transporte de datagrama ( DTLS o TLS de datagrama)0 es una modificación del TLS1 para una capa de transporte orientada a paquetes , donde la pérdida y reordenación de paquetes deben ser toleradas . La revisión de DTLS2 basada en TLS2 fue publicada en enero del Cabe notar que hay vulnerabilidades conocidas en SSL0 y SSL0 . Con la excepción de los predecibles IVs ( para los cuales existe una solución alternativa ) , todas las vulnerabilidades conocidas en la actualidad afectan a todas las versiones de TLS0/1.1/1.2 por igual . ( a ) El cliente SSL0 Hello está soportado aun cuando SSL0 no esté respaldado o esté inhabilitado por compatibilidades atrasadas . Criptografía de NSA Suite B Los componentes requeridos para la Criptografía de NSA Suite B ( RFCson : Estándar de Encriptación Avanzada ( AES ) con tamaños de clave deybits . Para el flujo de tráfico , AES debería ser usado en Modo Contador ( CTR ) para tráfico de baja banda ancha o en Modo Contador/Galois ( GCM ) , modo de operación para alto tráfico de banda ancha ( vea se modos de operación de cifrado en bloque ) — encriptación simétrica Algoritmo de Firma Digital de Curva Elíptica ( ECDSA ) — firmas digitales Curva Elíptica Diffie–Hellman ( ECDH ) — acuerdo clave Algoritmode Hash Protegido ( SHA-256 y SHA-384 ) — resumen del mensaje Por medio de CNSSP-15 , la curva elíptica debit ( especificada en FIPS SHA-256 , y AES , claves debits son suficientes para proteger información clasificada hasta el nivel secreto , mientras que con la curva elíptica debits ( especificada en FIPS SHA-384 , y AES , claves debits son necesarias para la protección de información de alta seguridad . Certificaciones Nótese que ciertas certificaciones han recibido serias críticas negativas de personas que , de hecho , han están involucradas en ellas . Algoritmos de intercambio de claves ( solo con certificado ) Esta sección lista la funcionalidad de la verificación de certificado disponible en las distintas implementaciones . Algoritmos de intercambio de clave ( intercambio de clave alternativo ) Métodos de verificación de certificado Algoritmos de cifrado Notas ( 1 ) Este algoritmo aún no está definido como una suite de cifrado en RFC ; está como una propuesta en borrador . ( 2 ) Solo autenticación , no encriptación . Algoritmos obsoletos Notas ( 1 ) IDEA y DES han sido removidos del TLS2 ( 2) bits de intensidad de cifrado fueron diseñados para operar a longitudes de clave reducidas para cumplir con las regulaciones de los Estados Unidos acerca de la exportación de software criptográfico que contiene algoritmos de cifrado de alta intensidad ( vea se Exportación de criptografía de los Estados Unidos ) . Estas suites débiles están prohibidas en TLS1 y versiones posteriores . ( 3 ) Lo ataques RC4 debilitan y/o interrumpen el RC4 usado en SSL/TLS . El uso de RC4 está prohibido por el RFC ( 4 ) Loas ataques RC4 debilitan y/o interrumpen el RC4 usado en SSL/TLS . Curvas elípticas respaldadas Esta sección lista las curvas elípticas respaldadas por cada implementación . Integridad de datos Compresión Nótese que la falla de seguridad CRIME toma ventaja de la compresión TLS , así que las implementaciones conservadoras no habilitan la compresión al nivel de TLS . La compresión HTTP no está relacionada ni se ve afectada por este abuso , pero se aprovecha del relacionado ataque BREACH . Extensiones En esta sección se listan las extensiones que cada implementación mantiene . Nótese que la extensión de Renegociación Segura es crítica para la seguridad del cliente HTTPS \ . Clientes TLS que no la implementan son vulnerables a ataques , independientemente de si el cliente implementa la renegociación TLS o no . Criptografía asistida Esta sección lista las habilidades de implementación conocidas por tomar ventaja de los sets de instrucción de CPU que optimizan la encriptación , o que utilizan dispositivos específicos del sistema que permiten accesar el hardware criptográfico subyacente para la aceleración o separación de datos . Soporte basado en sistema Esta sección lista la habilidad de cada implementación de aprovechar el soporte específico del sistema operativo disponible , o incluso el soporte provisto por alguna otra implementación . Módulo criptográfico/Token de soporte Dependencias de código Entorno de desarrollo Problemas de portabilidad Vea se también Stream Control Transmission Protocol Protocolo de Control de Congestión de Datagramas Secure Real-time Transport Protocol Referencias Software criptográfico Security software comparisons Transport Layer Security implementation