Transport Layer Security ( TLS ), el sucesor del ahora obsoleto Secure Sockets Layer ( SSL ), es un protocolo criptográfico diseñado para proporcionar seguridad en las comunicaciones a través de una red informática. Varias versiones del protocolo se utilizan ampliamente en aplicaciones como correo electrónico , mensajería instantánea y voz sobre IP , pero su uso como capa de seguridad en HTTPS sigue siendo el más visible públicamente.
El protocolo TLS tiene como objetivo principal proporcionar privacidad e integridad de datos entre dos o más aplicaciones informáticas que se comunican. Se ejecuta en la capa de aplicación de Internet y se compone de dos capas: el registro TLS y los protocolos de protocolo de enlace TLS.
TLS es un estándar propuesto por Internet Engineering Task Force (IETF), definido por primera vez en 1999, y la versión actual es TLS 1.3 definida en agosto de 2018. TLS se basa en las especificaciones SSL anteriores (1994, 1995, 1996) desarrolladas por Netscape Communications para agregar el protocolo HTTPS a su navegador web Navigator .
Descripción
Las aplicaciones cliente-servidor utilizan el protocolo TLS para comunicarse a través de una red de una manera diseñada para evitar escuchas y manipulaciones .
Dado que las aplicaciones pueden comunicarse con o sin TLS (o SSL), es necesario que el cliente indique al servidor la configuración de una conexión TLS. [1] Una de las principales formas de lograr esto es utilizar un número de puerto diferente para las conexiones TLS. Por ejemplo, el puerto 80 se usa normalmente para el tráfico HTTP sin cifrar , mientras que el puerto 443 es el puerto común que se usa para el tráfico HTTPS cifrado . Otro mecanismo es que el cliente realice una solicitud específica del protocolo al servidor para cambiar la conexión a TLS; por ejemplo, haciendo una solicitud STARTTLS cuando se utilizan los protocolos de correo y noticias .
Una vez que el cliente y el servidor han acordado utilizar TLS, negocian una conexión con estado mediante un procedimiento de protocolo de enlace . [2] Los protocolos utilizan un protocolo de enlace con un cifrado asimétrico para establecer no solo la configuración del cifrado, sino también una clave compartida específica de la sesión con la que se cifran las comunicaciones adicionales mediante un cifrado simétrico . Durante este protocolo de enlace, el cliente y el servidor acuerdan varios parámetros utilizados para establecer la seguridad de la conexión:
- El protocolo de enlace comienza cuando un cliente se conecta a un servidor habilitado para TLS que solicita una conexión segura y el cliente presenta una lista de conjuntos de cifrado compatibles ( funciones de cifrado y hash ).
- De esta lista, el servidor elige una función de cifrado y hash que también admite y notifica al cliente de la decisión.
- El servidor generalmente proporciona una identificación en forma de certificado digital . El certificado contiene el nombre del servidor , la autoridad certificadora (CA) de confianza que garantiza la autenticidad del certificado y la clave de cifrado pública del servidor.
- El cliente confirma la validez del certificado antes de continuar.
- Para generar las claves de sesión utilizadas para la conexión segura, el cliente:
- cifra un número aleatorio ( PreMasterSecret ) con la clave pública del servidor y envía el resultado al servidor (que solo el servidor debería poder descifrar con su clave privada); Luego, ambas partes usan el número aleatorio para generar una clave de sesión única para el posterior cifrado y descifrado de datos durante la sesión.
- utiliza el intercambio de claves Diffie-Hellman para generar de forma segura una clave de sesión única y aleatoria para el cifrado y el descifrado que tiene la propiedad adicional del secreto hacia adelante: si la clave privada del servidor se divulga en el futuro, no se puede utilizar para descifrar la sesión actual, incluso si la sesión es interceptada y registrada por un tercero.
Esto concluye el protocolo de enlace y comienza la conexión segura, que se cifra y descifra con la clave de sesión hasta que se cierra la conexión. Si alguno de los pasos anteriores falla, el protocolo de enlace TLS falla y no se crea la conexión.
TLS y SSL no encajan perfectamente en una sola capa del modelo OSI o el modelo TCP / IP . [3] [4] TLS se ejecuta "sobre algún protocolo de transporte confiable (por ejemplo, TCP)", [5] lo que implicaría que está por encima de la capa de transporte . Sirve para el cifrado de capas superiores, que normalmente es función de la capa de presentación . Sin embargo, las aplicaciones generalmente usan TLS como si fuera una capa de transporte, [3] [4] aunque las aplicaciones que usan TLS deben controlar activamente el inicio de los apretones de manos TLS y el manejo de los certificados de autenticación intercambiados. [5]
Cuando están protegidas por TLS, las conexiones entre un cliente (por ejemplo, un navegador web) y un servidor (por ejemplo, wikipedia.org) deben tener una o más de las siguientes propiedades:
- La conexión es privada (o segura ) porque se utiliza un algoritmo de clave simétrica para cifrar los datos transmitidos. Las claves para este cifrado simétrico se generan de forma única para cada conexión y se basan en un secreto compartido que se negoció al inicio de la sesión. El servidor y el cliente negocian los detalles de qué algoritmo de cifrado y claves criptográficas utilizar antes de que se transmita el primer byte de datos (ver más abajo). La negociación de un secreto compartido es segura (el secreto negociado no está disponible para los espías y no puede ser obtenido, incluso por un atacante que se coloca en el medio de la conexión) y confiable (ningún atacante puede modificar las comunicaciones durante la negociación sin ser detectado).
- La identidad de las partes comunicantes se puede autenticar mediante criptografía de clave pública . Esta autenticación es necesaria para el servidor y opcional para el cliente. [6]
- La conexión es confiable porque cada mensaje transmitido incluye una verificación de la integridad del mensaje utilizando un código de autenticación de mensaje para evitar la pérdida o alteración de los datos no detectados durante la transmisión. [7] : 3
Además de lo anterior, la configuración cuidadosa de TLS puede proporcionar propiedades adicionales relacionadas con la privacidad, como el secreto hacia adelante , lo que garantiza que cualquier divulgación futura de claves de cifrado no se pueda utilizar para descifrar cualquier comunicación TLS registrada en el pasado.
TLS admite muchos métodos diferentes para intercambiar claves, cifrar datos y autenticar la integridad de los mensajes. Como resultado, la configuración segura de TLS implica muchos parámetros configurables y no todas las opciones proporcionan todas las propiedades relacionadas con la privacidad descritas en la lista anterior (consulte las tablas a continuación § Intercambio de claves , § Seguridad de cifrado e § Integridad de datos ).
Se han realizado intentos para subvertir aspectos de la seguridad de las comunicaciones que TLS busca proporcionar, y el protocolo se ha revisado varias veces para abordar estas amenazas de seguridad. Los desarrolladores de navegadores web han revisado repetidamente sus productos para defenderse de posibles debilidades de seguridad después de que se descubrieron (consulte el historial de compatibilidad con TLS / SSL de los navegadores web).
Historia y desarrollo
Protocolo | Publicado | Estado |
---|---|---|
SSL 1.0 | Inédito | Inédito |
SSL 2.0 | 1995 | En desuso en 2011 ( RFC 6176 ) |
SSL 3.0 | 1996 | En desuso en 2015 ( RFC 7568 ) |
TLS 1.0 | 1999 | En desuso en 2020 ( RFC 8996 ) [8] [9] [10] |
TLS 1.1 | 2006 | En desuso en 2020 ( RFC 8996 ) [8] [9] [10] |
TLS 1.2 | 2008 | |
TLS 1.3 | 2018 |
Sistema de red de datos seguro
El Protocolo de seguridad de la capa de transporte (TLS), junto con varias otras plataformas básicas de seguridad de red, se desarrolló a través de una iniciativa conjunta iniciada en agosto de 1986, entre la Agencia de Seguridad Nacional, la Oficina Nacional de Normas, la Agencia de Comunicaciones de Defensa y doce comunicaciones y corporaciones informáticas que iniciaron un proyecto especial llamado Secure Data Network System (SDNS). [11] El programa se describió en septiembre de 1987 en la 10ª Conferencia Nacional de Seguridad Informática en una amplia serie de artículos publicados. El innovador programa de investigación se centró en el diseño de la próxima generación de especificaciones de productos y redes de comunicaciones informáticas seguras que se implementarán para aplicaciones en Internet públicas y privadas. Su objetivo era complementar los nuevos estándares de Internet OSI que emergen rápidamente y que avanzan tanto en los perfiles GOSIP del gobierno de EE. UU. Como en el enorme esfuerzo de Internet ITU-ISO JTC1 a nivel internacional. Originalmente conocido como protocolo SP4, pasó a llamarse TLS y posteriormente se publicó en 1995 como estándar internacional ITU-T X.274 | ISO / IEC 10736: 1995.
Programación de red segura
Los primeros esfuerzos de investigación hacia la seguridad de la capa de transporte incluyeron la interfaz de programación de aplicaciones (API) Secure Network Programming (SNP) , que en 1993 exploró el enfoque de tener una API de capa de transporte segura que se pareciera mucho a los sockets de Berkeley , para facilitar la adaptación de aplicaciones de red preexistentes con seguridad. medidas. [12]
SSL 1.0, 2.0 y 3.0
Netscape desarrolló los protocolos SSL originales, y Taher Elgamal , científico jefe de Netscape Communications de 1995 a 1998, ha sido descrito como el "padre de SSL". [13] [14] [15] [16] SSL versión 1.0 nunca se lanzó públicamente debido a serias fallas de seguridad en el protocolo. La versión 2.0, lanzada en febrero de 1995, contenía una serie de fallas de seguridad que requirieron el diseño de la versión 3.0. [17] [15] Lanzada en 1996, SSL versión 3.0 representó un rediseño completo del protocolo producido por Paul Kocher trabajando con los ingenieros de Netscape Phil Karlton y Alan Freier, con una implementación de referencia de Christopher Allen y Tim Dierks de Consensus Development. Las versiones más recientes de SSL / TLS se basan en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por IETF como un documento histórico en RFC 6101 .
SSL 2.0 quedó obsoleto en 2011 por RFC 6176 . En 2014, se descubrió que SSL 3.0 era vulnerable al ataque POODLE que afecta a todos los cifrados de bloque en SSL; RC4 , el único cifrado que no es de bloques admitido por SSL 3.0, también es factible roto como se usa en SSL 3.0. [18] SSL 3.0 quedó obsoleto en junio de 2015 por RFC 7568 .
TLS 1.0
TLS 1.0 se definió por primera vez en RFC 2246 en enero de 1999 como una actualización de SSL Versión 3.0 y escrito por Christopher Allen y Tim Dierks de Consensus Development. Como se indica en el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dramáticas, pero son lo suficientemente significativas como para excluir la interoperabilidad entre TLS 1.0 y SSL 3.0". Tim Dierks escribió más tarde que estos cambios, y el cambio de nombre de "SSL" a "TLS", fueron un gesto para salvar la cara a Microsoft, "por lo que no se vería [como] que el IETF estaba simplemente marcando el protocolo de Netscape". [19]
El PCI Council sugirió que las organizaciones migren de TLS 1.0 a TLS 1.1 o superior antes del 30 de junio de 2018. [20] [21] En octubre de 2018, Apple , Google , Microsoft y Mozilla anunciaron conjuntamente que desaprobarían TLS 1.0 y 1.1 en marzo. 2020. [8]
TLS 1.1
TLS 1.1 se definió en RFC 4346 en abril de 2006. [22] Es una actualización de TLS versión 1.0. Las diferencias significativas en esta versión incluyen:
- Protección adicional contra ataques de encadenamiento de bloques de cifrado (CBC).
- El vector de inicialización implícito (IV) fue reemplazado por un IV explícito.
- Cambio en el manejo de errores de relleno .
- Soporte para el registro de parámetros de IANA . [23] : 2
El soporte para las versiones 1.0 y 1.1 de TLS fue ampliamente desaprobado por los sitios web alrededor de 2020, deshabilitando el acceso a las versiones de Firefox antes de la 18 y Google Chrome antes de la 29. [24] [25]
TLS 1.2
TLS 1.2 se definió en RFC 5246 en agosto de 2008. Se basa en la anterior especificación TLS 1.1. Las principales diferencias incluyen:
- La combinación MD5 - SHA-1 en la función pseudoaleatoria (PRF) fue reemplazada por SHA-256 , con una opción para usar PRF especificadas por el conjunto de cifrado .
- La combinación MD5 – SHA-1 en el hash del mensaje terminado se reemplazó por SHA-256, con una opción para utilizar algoritmos hash específicos del conjunto de cifrado. Sin embargo, el tamaño del hash en el mensaje terminado debe ser de al menos 96 bits . [26]
- La combinación MD5 – SHA-1 en el elemento firmado digitalmente se reemplazó con un solo hash negociado durante el protocolo de enlace , que por defecto es SHA-1.
- Mejora de la capacidad del cliente y del servidor para especificar qué hashes y algoritmos de firma aceptan.
- Ampliación del soporte para cifrados de cifrado autenticados , utilizados principalmente para el modo Galois / Counter (GCM) y el modo CCM del cifrado Advanced Encryption Standard (AES).
- Se agregaron la definición de extensiones TLS y los conjuntos de cifrado AES. [23] : 2
Todas las versiones de TLS se perfeccionaron aún más en RFC 6176 en marzo de 2011, eliminando su retrocompatibilidad con SSL de modo que las sesiones TLS nunca negocien el uso de Secure Sockets Layer (SSL) versión 2.0.
TLS 1.3
TLS 1.3 se definió en RFC 8446 en agosto de 2018. Se basa en la especificación TLS 1.2 anterior. Las principales diferencias con TLS 1.2 incluyen: [27]
- Separación de los algoritmos de autenticación y acuerdos de claves de los conjuntos de cifrado
- Eliminación de soporte para curvas elípticas con nombre débiles y menos utilizadas
- Eliminación de la compatibilidad con las funciones hash criptográficas MD5 y SHA-224
- Requerir firmas digitales incluso cuando se usa una configuración previa
- Integrando HKDF y la propuesta DH semi-efímera
- Reemplazo de reanudación con PSK y tickets
- Admite apretones de manos de 1 a RTT y soporte inicial para 0- RTT
- Obligar el secreto hacia adelante perfecto , mediante el uso de claves efímeras durante el acuerdo de claves (EC) DH
- Eliminación de soporte para muchas características inseguras u obsoletas, incluida la compresión , renegociación, cifrados que no son AEAD , intercambio de claves no PFS (entre los que se encuentran intercambios de claves RSA estáticas y DH estáticas ), grupos DHE personalizados , negociación de formato de punto EC, protocolo de especificación de cambio de cifrado, Hola mensaje UNIX tiempo, y el campo de longitud AD de entrada a los cifrados AEAD
- Prohibir la negociación SSL o RC4 por compatibilidad con versiones anteriores
- Integración del uso de hash de sesión
- Depreciar el uso del número de versión de la capa de registro y congelar el número para mejorar la compatibilidad con versiones anteriores
- Mover algunos detalles del algoritmo relacionados con la seguridad de un apéndice a la especificación y relegar ClientKeyShare a un apéndice
- Agregar el cifrado de flujo ChaCha20 con el código de autenticación de mensajes Poly1305
- Adición de los algoritmos de firma digital Ed25519 y Ed448
- Adición de los protocolos de intercambio de claves x25519 y x448
- Adición de soporte para enviar múltiples respuestas OCSP
- Cifrar todos los mensajes de protocolo de enlace después de ServerHello
Network Security Services (NSS), la biblioteca de criptografía desarrollada por Mozilla y utilizada por su navegador web Firefox , habilitó TLS 1.3 de forma predeterminada en febrero de 2017. [28] Posteriormente se agregó compatibilidad con TLS 1.3, pero debido a problemas de compatibilidad para un pequeño número de usuarios, no habilitado automáticamente [29] - a Firefox 52.0 , que se lanzó en marzo de 2017. TLS 1.3 se habilitó de forma predeterminada en mayo de 2018 con el lanzamiento de Firefox 60.0 . [30]
Google Chrome estableció TLS 1.3 como la versión predeterminada por un corto tiempo en 2017. Luego lo eliminó como predeterminado, debido a cajas intermedias incompatibles como los proxies web Blue Coat . [31]
Durante el IETF 100 Hackathon que tuvo lugar en Singapur en 2017, el Grupo TLS trabajó en la adaptación de aplicaciones de código abierto para usar TLS 1.3. [32] [33] El grupo TLS estaba formado por personas de Japón , Reino Unido y Mauricio a través del equipo cyberstorm.mu. [33] Este trabajo continuó en el IETF 101 Hackathon en Londres , [34] y el IETF 102 Hackathon en Montreal. [35]
wolfSSL permitió el uso de TLS 1.3 a partir de la versión 3.11.1, lanzada en mayo de 2017. [36] Como la primera implementación comercial de TLS 1.3, wolfSSL 3.11.1 admitía el Borrador 18 y ahora es compatible con el Borrador 28, [37] la versión final, así como muchas versiones anteriores. Se publicó una serie de blogs sobre la diferencia de rendimiento entre TLS 1.2 y 1.3. [38]
En , el popular proyecto OpenSSL lanzó la versión 1.1.1 de su biblioteca, en la que el soporte para TLS 1.3 era "la nueva característica principal". [39]
Seguridad del transporte empresarial
La Electronic Frontier Foundation elogió TLS 1.3 y expresó su preocupación por la variante del protocolo Enterprise Transport Security (ETS) que deshabilita intencionalmente importantes medidas de seguridad en TLS 1.3. [40] Originalmente llamado Enterprise TLS (eTLS), ETS es un estándar publicado conocido como 'ETSI TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". Está diseñado para usarse completamente dentro de redes propietarias, como los sistemas bancarios. ETS no admite el secreto hacia adelante para permitir que las organizaciones de terceros conectadas a las redes propietarias puedan usar su clave privada para monitorear el tráfico de la red para la detección de malware y facilitar la realización de auditorías. [41] [42] A pesar de los beneficios declarados, la EFF advirtió que la pérdida del secreto hacia adelante podría facilitar la exposición de los datos, además de decir que hay mejores formas de analizar el tráfico.
Certificados digitales
Un certificado digital certifica la propiedad de una clave pública por parte del sujeto nombrado del certificado e indica ciertos usos esperados de esa clave. Esto permite que otros (partes de confianza) se basen en firmas o en afirmaciones realizadas por la clave privada que corresponde a la clave pública certificada. Los almacenes de claves y los almacenes de confianza pueden estar en varios formatos, como .pem, .crt, .pfx y .jks.
Autoridades de certificación
TLS generalmente se basa en un conjunto de autoridades de certificación de terceros confiables para establecer la autenticidad de los certificados. La confianza suele estar anclada en una lista de certificados distribuidos con el software del agente de usuario, [43] y la parte que confía puede modificarla.
Según Netcraft , que supervisa los certificados TLS activos, la autoridad certificadora (CA) líder en el mercado ha sido Symantec desde el comienzo de su encuesta (o VeriSign antes de que Symantec comprara la unidad de negocios de servicios de autenticación). A partir de 2015, Symantec representaba poco menos de un tercio de todos los certificados y el 44% de los certificados válidos utilizados por el millón de sitios web más activos, contados por Netcraft. [44] En 2017, Symantec vendió su negocio TLS / SSL a DigiCert. [45] En un informe actualizado, se demostró que IdenTrust , DigiCert y Sectigo son las tres principales autoridades de certificación en términos de participación de mercado desde mayo de 2019. [46]
Como consecuencia de la elección de certificados X.509 , las autoridades de certificación y una infraestructura de clave pública son necesarias para verificar la relación entre un certificado y su propietario, así como para generar, firmar y administrar la validez de los certificados. Si bien esto puede ser más conveniente que verificar las identidades a través de una red de confianza , las divulgaciones de vigilancia masiva de 2013 hicieron más conocido que las autoridades de certificación son un punto débil desde el punto de vista de la seguridad, lo que permite ataques de intermediario (MITM). si la autoridad certificadora coopera (o se ve comprometida). [47] [48]
Algoritmos
Intercambio de claves o acuerdo de claves
Antes de que un cliente y un servidor puedan comenzar a intercambiar información protegida por TLS, deben intercambiar de forma segura o acordar una clave de cifrado y un cifrado para usar al cifrar datos (consulte § Cifrado ). Entre los métodos utilizados para el intercambio / acuerdo de claves se encuentran: claves públicas y privadas generadas con RSA (denotado TLS_RSA en el protocolo de enlace TLS), Diffie-Hellman (TLS_DH), Diffie-Hellman efímero (TLS_DHE), Diffie-Hellman de curva elíptica ( TLS_ECDH), Diffie-Hellman de curva elíptica efímera (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon), [7] clave precompartida (TLS_PSK) [49] y Contraseña remota segura (TLS_SRP). [50]
Los métodos de acuerdo de claves TLS_DH_anon y TLS_ECDH_anon no autentican al servidor o al usuario y, por lo tanto, rara vez se utilizan porque son vulnerables a los ataques de intermediarios . Solo TLS_DHE y TLS_ECDHE proporcionan confidencialidad directa .
Los certificados de clave pública utilizados durante el intercambio / acuerdo también varían en el tamaño de las claves de cifrado públicas / privadas utilizadas durante el intercambio y, por lo tanto, la solidez de la seguridad proporcionada. En julio de 2013, Google anunció que ya no usaría claves públicas de 1024 bits y cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios porque la fuerza del cifrado está directamente relacionada con el tamaño de la clave. . [51] [52]
Algoritmo | SSL 2.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | Estado |
---|---|---|---|---|---|---|---|
RSA | sí | sí | sí | sí | sí | No | Definido para TLS 1.2 en RFC |
DH - RSA | No | sí | sí | sí | sí | No | |
DHE - RSA ( secreto hacia adelante ) | No | sí | sí | sí | sí | sí | |
ECDH - RSA | No | No | sí | sí | sí | No | |
ECDHE - RSA (sigilo hacia adelante) | No | No | sí | sí | sí | sí | |
DH - DSS | No | sí | sí | sí | sí | No | |
DHE - DSS (secreto hacia adelante) | No | sí | sí | sí | sí | No [53] | |
ECDH - ECDSA | No | No | sí | sí | sí | No | |
ECDHE - ECDSA (sigilo hacia adelante) | No | No | sí | sí | sí | sí | |
ECDH - EdDSA | No | No | sí | sí | sí | No | |
ECDHE - EdDSA (sigilo hacia adelante) [54] | No | No | sí | sí | sí | sí | |
PSK | No | No | sí | sí | sí | ||
PSK - RSA | No | No | sí | sí | sí | ||
DHE - PSK (secreto hacia adelante) | No | No | sí | sí | sí | sí | |
ECDHE - PSK (sigilo hacia adelante) | No | No | sí | sí | sí | sí | |
SRP | No | No | sí | sí | sí | ||
SRP - DSS | No | No | sí | sí | sí | ||
SRP - RSA | No | No | sí | sí | sí | ||
Kerberos | No | No | sí | sí | sí | ||
DH -ANON (inseguro) | No | sí | sí | sí | sí | ||
ECDH -ANON (inseguro) | No | No | sí | sí | sí | ||
GOST R 34.10-94 / 34.10-2001 [55] | No | No | sí | sí | sí | Propuesto en borradores de RFC |
Cifrar
Cifrar | Versión del protocolo | Estado | |||||||
---|---|---|---|---|---|---|---|---|---|
Tipo | Algoritmo | Resistencia nominal (bits) | SSL 2.0 | SSL 3.0 [n 1] [n 2] [n 3] [n 4] | TLS 1.0 [n 1] [n 3] | TLS 1.1 [n 1] | TLS 1.2 [n 1] | TLS 1.3 | |
Cifrado en bloque con modo de operación | AES GCM [56] [n 5] | 256, 128 | N / A | N / A | N / A | N / A | Seguro | Seguro | Definido para TLS 1.2 en RFC |
AES CCM [57] [n 5] | N / A | N / A | N / A | N / A | Seguro | Seguro | |||
AES CBC [n 6] | N / A | Inseguro | Depende de mitigaciones | Depende de mitigaciones | Depende de mitigaciones | N / A | |||
Camelia GCM [58] [n 5] | 256, 128 | N / A | N / A | N / A | N / A | Seguro | N / A | ||
CBC de camelia [59] [n 6] | N / A | Inseguro | Depende de mitigaciones | Depende de mitigaciones | Depende de mitigaciones | N / A | |||
ARIA GCM [60] [n 5] | 256, 128 | N / A | N / A | N / A | N / A | Seguro | N / A | ||
ARIA CBC [60] [n 6] | N / A | N / A | Depende de mitigaciones | Depende de mitigaciones | Depende de mitigaciones | N / A | |||
SEMILLA CBC [61] [n 6] | 128 | N / A | Inseguro | Depende de mitigaciones | Depende de mitigaciones | Depende de mitigaciones | N / A | ||
3DES EDE CBC [n 6] [n 7] | 112 [n 8] | Inseguro | Inseguro | Inseguro | Inseguro | Inseguro | N / A | ||
GOST 28147-89 CNT [55] [n 7] | 256 | N / A | N / A | Inseguro | Inseguro | Inseguro | N / A | Definido en RFC 4357 | |
IDEA CBC [n 6] [n 7] [n 9] | 128 | Inseguro | Inseguro | Inseguro | Inseguro | N / A | N / A | Eliminado de TLS 1.2 | |
DES CBC [n 6] [n 7] [n 9] | 56 | Inseguro | Inseguro | Inseguro | Inseguro | N / A | N / A | ||
40 [n 10] | Inseguro | Inseguro | Inseguro | N / A | N / A | N / A | Prohibido en TLS 1.1 y posteriores | ||
RC2 CBC [n 6] [n 7] | 40 [n 10] | Inseguro | Inseguro | Inseguro | N / A | N / A | N / A | ||
Cifrado de flujo | ChaCha20 - Poly1305 [66] [n 5] | 256 | N / A | N / A | N / A | N / A | Seguro | Seguro | Definido para TLS 1.2 en RFC |
RC4 [n 11] | 128 | Inseguro | Inseguro | Inseguro | Inseguro | Inseguro | N / A | Prohibido en todas las versiones de TLS por RFC 7465 | |
40 [n 10] | Inseguro | Inseguro | Inseguro | N / A | N / A | N / A | |||
Ninguno | Nulo [n 12] | - | Inseguro | Inseguro | Inseguro | Inseguro | Inseguro | N / A | Definido para TLS 1.2 en RFC |
- Notas
- ^ a b c d Se debe implementar RFC 5746 para corregir una falla de renegociación que de otra manera rompería este protocolo.
- ^ Si las bibliotecas implementan las correcciones enumeradas en RFC 5746 , esto viola la especificación SSL 3.0, que el IETF no puede cambiar a diferencia de TLS. La mayoría de las bibliotecas actuales implementan la solución e ignoran la infracción que esto provoca.
- ^ a b El ataque BEAST rompe todos los cifrados de bloque (cifrados CBC) utilizados en SSL 3.0 y TLS 1.0 a menos que el cliente y / o el servidor lo mitiguen. Consulte § Navegadores web .
- ^ Elataque POODLE rompe todos los cifrados de bloque (cifrados CBC) utilizados en SSL 3.0 a menos que el cliente y / o el servidor lo mitiguen. Consulte § Navegadores web .
- ^ a b c d e Los cifrados AEAD (como GCM y CCM ) solo se pueden usar en TLS 1.2 o posterior.
- ^ a b c d e f g h Los cifrados CBC pueden ser atacados con el ataque Lucky Thirteen si la biblioteca no se escribe con cuidado para eliminar los canales laterales de temporización.
- ^ a b c d e El ataque Sweet32 rompe los cifrados de bloque con un tamaño de bloque de 64 bits. [62]
- ^ Aunque la longitud de la clave de 3DES es de 168 bits, la fuerza de seguridad efectiva de 3DES es de solo 112 bits, [63] que está por debajo del mínimo recomendado de 128 bits. [64]
- ^ a b IDEA y DES se han eliminado de TLS 1.2. [sesenta y cinco]
- ^ a b c Los conjuntos de cifrado de 40 bits de fuerza se diseñaron intencionalmente con longitudes de clave reducidas para cumplir con las regulaciones de EE. UU. rescindidas desde entonces que prohíben la exportación de software criptográfico que contenga ciertos algoritmos de cifrado sólidos (consulte Exportación de criptografía de los Estados Unidos ). Estas suites débiles están prohibidas en TLS 1.1 y versiones posteriores.
- ^ El uso de RC4 en todas las versiones de TLS está prohibido por RFC 7465 (porque los ataques RC4 debilitan o rompen el RC4 utilizado en SSL / TLS).
- ^ Solo autenticación, sin cifrado.
Integridad de los datos
Se utiliza un código de autenticación de mensajes (MAC) para la integridad de los datos. HMAC se utiliza para el modo CBC de cifrado de bloques. El cifrado autenticado (AEAD), como el modo GCM y el modo CCM, utiliza MAC integrado con AEAD y no utiliza HMAC . [67] PRF basado en HMAC , o HKDF se utiliza para el protocolo de enlace TLS.
Algoritmo | SSL 2.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | Estado |
---|---|---|---|---|---|---|---|
HMAC - MD5 | sí | sí | sí | sí | sí | No | Definido para TLS 1.2 en RFC |
HMAC - SHA1 | No | sí | sí | sí | sí | No | |
HMAC - SHA256 / 384 | No | No | No | No | sí | No | |
AEAD | No | No | No | No | sí | sí | |
GOST 28147-89 IMIT [55] | No | No | sí | sí | sí | Propuesto en borradores de RFC | |
GOST R 34.11-94 [55] | No | No | sí | sí | sí |
Aplicaciones y adopción
En el diseño de aplicaciones, TLS generalmente se implementa sobre los protocolos de la capa de transporte, cifrando todos los datos relacionados con el protocolo de protocolos como HTTP , FTP , SMTP , NNTP y XMPP .
Históricamente, TLS se ha utilizado principalmente con protocolos de transporte fiables, como el Protocolo de control de transmisión (TCP). Sin embargo, también se ha implementado con protocolos de transporte orientados a datagramas, como el User Datagram Protocol (UDP) y el Datagram Congestion Control Protocol (DCCP), cuyo uso se ha estandarizado de forma independiente utilizando el término Datagram Transport Layer Security (DTLS). .
Sitios web
Un uso principal de TLS es proteger el tráfico de la World Wide Web entre un sitio web y un navegador web codificado con el protocolo HTTP. Este uso de TLS para proteger el tráfico HTTP constituye el protocolo HTTPS . [68]
Versión del protocolo | Soporte del sitio web [69] | Seguridad [69] [70] |
---|---|---|
SSL 2.0 | 0,5% | Inseguro |
SSL 3.0 | 3,4% | Inseguro [71] |
TLS 1.0 | 46,9% | Obsoleto [8] [9] [10] |
TLS 1.1 | 52,3% | Obsoleto [8] [9] [10] |
TLS 1.2 | 99,4% | Depende del cifrado [n 1] y las mitigaciones del cliente [n 2] |
TLS 1.3 | 44,8% | Seguro |
- Notas
- ^ ver § Tabla de cifrado arriba
- ^ ver § Navegadores web y § Ataques contra las secciones TLS / SSL
navegadores web
A abril de 2016[actualizar], las últimas versiones de los principales navegadores web son compatibles con TLS 1.0, 1.1 y 1.2, y las tienen habilitadas de forma predeterminada. Sin embargo, no todos los sistemas operativos de Microsoft compatibles son compatibles con la última versión de IE. Además, muchos sistemas operativos actualmente admiten varias versiones de IE, pero esto ha cambiado de acuerdo con las Preguntas frecuentes sobre la política del ciclo de vida de soporte de Internet Explorer de Microsoft , "a partir del 12 de enero de 2016, solo la versión más actual de Internet Explorer disponible para un sistema operativo compatible recibirá información técnica. actualizaciones de soporte y seguridad ". Luego, la página continúa para enumerar la última versión compatible de IE en esa fecha para cada sistema operativo. La próxima fecha crítica sería cuando un sistema operativo llega al final de su vida útil, que se encuentra en la hoja de datos del ciclo de vida de Windows de Microsoft .
Las mitigaciones contra ataques conocidos aún no son suficientes:
- Mitigaciones contra el ataque POODLE : algunos navegadores ya previenen el respaldo a SSL 3.0; sin embargo, esta mitigación debe ser respaldada no solo por los clientes sino también por los servidores. Se requiere deshabilitar SSL 3.0, la implementación de "división de registros anti-POODLE" o negar los cifrados CBC en SSL 3.0.
- Google Chrome: completo (TLS_FALLBACK_SCSV se implementa desde la versión 33, el respaldo a SSL 3.0 está deshabilitado desde la versión 39, SSL 3.0 en sí está deshabilitado de forma predeterminada desde la versión 40. La compatibilidad con SSL 3.0 se eliminó desde la versión 44).
- Mozilla Firefox: completo (la compatibilidad con SSL 3.0 se ha eliminado desde la versión 39. SSL 3.0 está deshabilitado de forma predeterminada y el respaldo a SSL 3.0 está deshabilitado desde la versión 34 , TLS_FALLBACK_SCSV está implementado desde la versión 35. En ESR, SSL 3.0 está deshabilitado por predeterminado y TLS_FALLBACK_SCSV se implementa desde ESR 31.3.)
- Internet Explorer: parcial (solo en la versión 11, SSL 3.0 está deshabilitado de forma predeterminada desde abril de 2015. La versión 10 y anteriores siguen siendo vulnerables contra POODLE).
- Opera : completo (TLS_FALLBACK_SCSV se implementa desde la versión 20, la "división de registros anti-POODLE", que es efectiva solo con la implementación del lado del cliente, se implementa desde la versión 25, SSL 3.0 está deshabilitado por defecto desde la versión 27. Soporte de SSL 3.0 se eliminará desde la versión 31).
- Safari: completo (solo en OS X 10.8 y posteriores e iOS 8, los cifrados CBC durante el respaldo a SSL 3.0 están denegados, pero esto significa que usará RC4, que tampoco se recomienda. El soporte de SSL 3.0 en sí mismo se descarta en OS X 10.11 y posterior y iOS 9.)
- Mitigación contra ataques RC4 :
- Google Chrome inhabilitó RC4 excepto como respaldo desde la versión 43. RC4 está inhabilitado desde Chrome 48.
- Firefox desactivó RC4 excepto como respaldo desde la versión 36. Firefox 44 desactivó RC4 de forma predeterminada.
- Opera desactivó RC4 excepto como respaldo desde la versión 30. RC4 está desactivado desde Opera 35.
- Internet Explorer para Windows 7 / Server 2008 R2 y Windows 8 / Server 2012 han establecido la prioridad de RC4 al mínimo y también puede deshabilitar RC4 excepto como un respaldo a través de la configuración del registro. Internet Explorer 11 Mobile 11 para Windows Phone 8.1 deshabilita RC4 excepto como respaldo si no funciona ningún otro algoritmo habilitado. Edge e IE 11 desactivan RC4 por completo en agosto de 2016.
- Mitigación contra el ataque FREAK :
- El navegador de Android incluido con Android 4.0 y versiones anteriores sigue siendo vulnerable al ataque FREAK.
- Internet Explorer 11 Mobile sigue siendo vulnerable al ataque FREAK.
- Google Chrome, Internet Explorer (escritorio), Safari (escritorio y móvil) y Opera (móvil) tienen implementadas las mitigaciones FREAK.
- Mozilla Firefox en todas las plataformas y Google Chrome en Windows no se vieron afectados por FREAK.
Navegador | Versión | Plataformas | Protocolos SSL | Protocolos TLS | Soporte de certificado | Vulnerabilidades solucionadas [n 1] | Selección de protocolo por usuario [n 2] | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | EV [n 3] [72] | SHA-2 [73] | ECDSA [74] | BESTIA [n 4] | DELITO [n 5] | CANICHE (SSLv3) [n 6] | RC4 [n 7] | FREAK [75] [76] | Atolladero | |||||
Google Chrome ( Chrome para Android ) [n 8] [n 9] | 1-9 | Windows (7+) macOS (10.11+) Linux Android (5.0+) iOS (12.2+) Chrome OS | Desactivado por defecto | Habilitado por defecto | sí | No | No | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado [81] | Vulnerable (HTTPS) | Vulnerable | Vulnerable | Vulnerable (excepto Windows) | Vulnerable | Sí [n 10] | |
10-20 | No [82] | Habilitado por defecto | sí | No | No | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Vulnerable (HTTPS / SPDY) | Vulnerable | Vulnerable | Vulnerable (excepto Windows) | Vulnerable | Sí [n 10] | |||
21 | No | Habilitado por defecto | sí | No | No | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado [83] | Vulnerable | Vulnerable | Vulnerable (excepto Windows) | Vulnerable | Sí [n 10] | |||
22-29 | No | Habilitado por defecto | sí | Sí [84] | No [84] [85] [86] [87] | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Vulnerable | Vulnerable | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |||
30–32 | No | Habilitado por defecto | sí | sí | Sí [85] [86] [87] | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Vulnerable | Vulnerable | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |||
33–37 | No | Habilitado por defecto | sí | sí | sí | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado parcialmente [n 12] | Prioridad más baja [90] [91] [92] | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |||
38, 39 | No | Habilitado por defecto | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Parcialmente mitigado | Prioridad más baja | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |||
40 | No | Desactivado por defecto [89] [93] | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado [n 13] | Prioridad más baja | Vulnerable (excepto Windows) | Vulnerable | Sí [n 14] | |||
41, 42 | No | Desactivado por defecto | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado | Prioridad más baja | Mitigado | Vulnerable | Sí [n 14] | |||
43 | No | Desactivado por defecto | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado | Solo como alternativa [n 15] [94] | Mitigado | Vulnerable | Sí [n 14] | |||
44–47 | No | No [95] | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | No afectado | Solo como alternativa [n 15] | Mitigado | Mitigada [96] | Temporal [n 11] | |||
48, 49 | No | No | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
50–53 | No | No | sí | sí | sí | No | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
54–66 | No | No | sí | sí | sí | Deshabilitado por defecto (versión borrador) | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
67–69 | No | No | sí | sí | sí | Sí (versión borrador) | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
70–83 | No | No | sí | sí | sí | sí | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
84–90 | No | No | Advertir por defecto | Advertir por defecto | sí | sí | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
91 | No | No | No [99] | No [99] | sí | sí | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Independiente del sistema operativo Microsoft Edge (basado en Chromium) | 79–83 | Windows (7+) macOS (10.12+) Linux Android (4.4+) iOS (11.0+) | No | No | sí | sí | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto | Mitigado | Mitigado | Sí [n 10] | |
84–90 | No | No | Advertir por defecto | Advertir por defecto | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto | Mitigado | Mitigado | Sí [n 10] | |||
91 | No | No | No [100] | No [100] | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto | Mitigado | Mitigado | Sí [n 10] | |||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Mozilla Firefox ( Firefox para móviles ) [n 17] | 1,0, 1,5 | Windows (7+) macOS (10.12+) Linux Android (5.0+) iOS (11.4+) ESR solo para: Windows (7+) macOS (10.9+) Linux | Habilitado de forma predeterminada [101] | Habilitado de forma predeterminada [101] | Sí [101] | No | No | No | No | Sí [73] | No | No afectado [102] | No afectado | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 10] | |
2 | Deshabilitado de forma predeterminada [101] [103] | Habilitado por defecto | sí | No | No | No | No | sí | Sí [74] | No afectado | No afectado | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 10] | |||
3-7 | Desactivado por defecto | Habilitado por defecto | sí | No | No | No | sí | sí | sí | No afectado | No afectado | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 10] | |||
8-10 ESR 10 | No [103] | Habilitado por defecto | sí | No | No | No | sí | sí | sí | No afectado | No afectado | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 10] | |||
11-14 | No | Habilitado por defecto | sí | No | No | No | sí | sí | sí | No afectado | Vulnerable (SPDY) [83] | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 10] | |||
15-22 ESR 17.0-17.0.10 | No | Habilitado por defecto | sí | No | No | No | sí | sí | sí | No afectado | Mitigado | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 10] | |||
ESR 17.0.11 | No | Habilitado por defecto | sí | No | No | No | sí | sí | sí | No afectado | Mitigado | Vulnerable | Prioridad más baja [104] [105] | No afectado | Vulnerable | Sí [n 10] | |||
23 | No | Habilitado por defecto | sí | Desactivado por defecto [106] | No | No | sí | sí | sí | No afectado | Mitigado | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 18] | |||
24, 25.0.0 ESR 24.0-24.1.0 | No | Habilitado por defecto | sí | Desactivado por defecto | Desactivado de forma predeterminada [107] | No | sí | sí | sí | No afectado | Mitigado | Vulnerable | Vulnerable | No afectado | Vulnerable | Sí [n 18] | |||
25.0.1, 26 ESR 24.1.1 | No | Habilitado por defecto | sí | Desactivado por defecto | Desactivado por defecto | No | sí | sí | sí | No afectado | Mitigado | Vulnerable | Prioridad más baja [104] [105] | No afectado | Vulnerable | Sí [n 18] | |||
27–33 ESR 31,0–31,2 | No | Habilitado por defecto | sí | Sí [108] [109] | Sí [110] [109] | No | sí | sí | sí | No afectado | Mitigado | Vulnerable | Prioridad más baja | No afectado | Vulnerable | Sí [n 18] | |||
34, 35 ESR 31,3–31,7 | No | Deshabilitado de forma predeterminada [111] [112] | sí | sí | sí | No | sí | sí | sí | No afectado | Mitigado | Mitigado [n 19] | Prioridad más baja | No afectado | Vulnerable | Sí [n 18] | |||
ESR 31,8 | No | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | No afectado | Mitigado | Mitigado | Prioridad más baja | No afectado | Mitigada [115] | Sí [n 18] | |||
36–38 ESR 38.0 | No | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | No afectado | Mitigado | Mitigado | Solo como alternativa [n 15] [116] | No afectado | Vulnerable | Sí [n 18] | |||
ESR 38,1–38,8 | No | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | No afectado | Mitigado | Mitigado | Solo como alternativa [n 15] | No afectado | Mitigada [115] | Sí [n 18] | |||
39–43 | No | No [117] | sí | sí | sí | No | sí | sí | sí | No afectado | Mitigado | No afectado | Solo como alternativa [n 15] | No afectado | Mitigada [115] | Sí [n 18] | |||
44–48 ESR 45 | No | No | sí | sí | sí | No | sí | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [118] [119] [120] [121] | No afectado | Mitigado | Sí [n 18] | |||
49–59 ESR 52 | No | No | sí | sí | sí | Inhabilitado de forma predeterminada (versión borrador) [122] | sí | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] | No afectado | Mitigado | Sí [n 18] | |||
60–62 ESR 60 | No | No | sí | sí | sí | Sí (versión borrador) | sí | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] | No afectado | Mitigado | Sí [n 18] | |||
63–77 ESR 68 | No | No | sí | sí | sí | sí | sí | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] | No afectado | Mitigado | Sí [n 18] | |||
78–89 ESR 78.0–78.11 | No | No | Desactivado de forma predeterminada [123] | Desactivado de forma predeterminada [123] | sí | sí | sí | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] | No afectado | Mitigado | Sí [n 18] | |||
ESR 78,12 | 90 | ||||||||||||||||||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Opera Browser ( Opera Mobile ) ( Pre-Presto y Presto ) [n 20] | 1-2 | No es compatible con SSL / TLS [125] | |||||||||||||||||
3 | Sí [126] | No | No | No | No | No | No | No | No | No es compatible con SSL 3.0 o TLS | Vulnerable | Desconocido | Desconocido | N / A | |||||
4 | sí | Sí [127] | No | No | No | No | No | No | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Desconocido | Desconocido | Desconocido | |||
5 | Habilitado por defecto | Habilitado por defecto | Sí [128] | No | No | No | No | No | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Desconocido | Desconocido | Sí [n 10] | |||
6–7 | Habilitado por defecto | Habilitado por defecto | sí | No | No | No | No | Sí [73] | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Desconocido | Desconocido | Sí [n 10] | |||
8 | Habilitado por defecto | Habilitado por defecto | sí | Desactivado por defecto [129] | No | No | No | sí | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Desconocido | Desconocido | Sí [n 10] | |||
9 | Deshabilitado por defecto [130] | Habilitado por defecto | sí | sí | No | No | desde v9.5 (solo escritorio) | sí | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Desconocido | Desconocido | Sí [n 10] | |||
10-11.52 | No [131] | Habilitado por defecto | sí | Desactivado por defecto | Desactivado de forma predeterminada [131] | No | Sí (solo escritorio) | sí | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Desconocido | Desconocido | Sí [n 10] | |||
11.60-11.64 | No | Habilitado por defecto | sí | Desactivado por defecto | Desactivado por defecto | No | Sí (solo escritorio) | sí | No | Mitigado [132] | No afectado | Vulnerable | Vulnerable | Desconocido | Desconocido | Sí [n 10] | |||
12-12.14 | No | Deshabilitado por defecto [n 21] | sí | Desactivado por defecto | Desactivado por defecto | No | Sí (solo escritorio) | sí | No | Mitigado | No afectado | Mitigado [n 21] | Vulnerable | Desconocido | Mitigada [134] | Sí [n 10] | |||
12.15-12.17 | No | Desactivado por defecto | sí | Desactivado por defecto | Desactivado por defecto | No | Sí (solo escritorio) | sí | No | Mitigado | No afectado | Mitigado | Mitigado parcialmente [135] [136] | Desconocido | Mitigada [134] | Sí [n 10] | |||
12.18 | No | Desactivado por defecto | sí | Sí [137] | Sí [137] | No | Sí (solo escritorio) | sí | Sí [137] | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] [137] | Mitigada [137] | Mitigada [134] | Sí [n 10] | |||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Navegador Opera ( Opera Mobile ) ( Webkit y Blink ) [n 22] | 14-16 | Windows (7+) macOS (10.11+) Linux Android (4.4+) | No | Habilitado por defecto | sí | Sí [140] | No | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Vulnerable | Vulnerable | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |
17-19 | No | Habilitado por defecto | sí | sí | Sí [141] | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Vulnerable | Vulnerable | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |||
20-24 | No | Habilitado por defecto | sí | sí | sí | No | Sí (solo escritorio) | necesita SO compatible con SHA-2 [73] | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado parcialmente [n 23] | Prioridad más baja [142] | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |||
25, 26 | No | Habilitado de forma predeterminada [n 24] | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado [n 25] | Prioridad más baja | Vulnerable (excepto Windows) | Vulnerable | Temporal [n 11] | |||
27 | No | Deshabilitado por defecto [93] | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado [n 26] | Prioridad más baja | Vulnerable (excepto Windows) | Vulnerable | Sí [n 27] (solo escritorio) | |||
28, 29 | No | Desactivado por defecto | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado | Prioridad más baja | Mitigado | Vulnerable | Sí [n 27] (solo escritorio) | |||
30 | No | Desactivado por defecto | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | Mitigado | Solo como alternativa [n 15] [94] | Mitigado | Mitigada [134] | Sí [n 27] (solo escritorio) | |||
31–34 | No | No [95] | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | No afectado | Solo como alternativa [n 15] [94] | Mitigado | Mitigado | Temporal [n 11] | |||
35, 36 | No | No | sí | sí | sí | No | Sí (solo escritorio) | sí | necesita un sistema operativo compatible con ECC [74] | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
37–40 | No | No | sí | sí | sí | No | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
41–56 | No | No | sí | sí | sí | Deshabilitado por defecto (versión borrador) | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
57–74 | No | No | sí | sí | sí | sí | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | |||
75 | 76 | No | No | Advertir por defecto | Advertir por defecto | sí | sí | Sí (solo escritorio) | sí | sí | No afectado | Mitigado | No afectado | Desactivado por defecto [n 16] [97] [98] | Mitigado | Mitigado | Temporal [n 11] | ||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Microsoft Internet Explorer (1–10) [n 28] | 1.x | Windows 3.1 , 95 , NT , [n 29] [n 30] Mac OS 7 , 8 | Sin soporte SSL / TLS | ||||||||||||||||
2 | sí | No | No | No | No | No | No | No | No | No es compatible con SSL 3.0 o TLS | Vulnerable | Vulnerable | Vulnerable | N / A | |||||
3 | sí | Sí [145] | No | No | No | No | No | No | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | Desconocido | |||
4 , 5 , 6 | Windows 3.1 , 95 , 98 , NT , 2000 [n 29] [n 30] Mac OS 7.1 , 8 , X , Solaris , HP-UX | Habilitado por defecto | Habilitado por defecto | Deshabilitado de forma predeterminada [145] | No | No | No | No | No | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | Sí [n 10] | ||
6 | Windows XP [n 30] | Habilitado por defecto | Habilitado por defecto | Desactivado por defecto | No | No | No | No | Sí [n 31] [146] | No | Mitigado | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | Sí [n 10] | ||
7 , 8 | Desactivado de forma predeterminada [147] | Habilitado por defecto | Sí [147] | No | No | No | sí | Sí [n 31] [146] | No | Mitigado | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | Sí [n 10] | |||
6 | Servidor 2003 [n 30] | Habilitado por defecto | Habilitado por defecto | Desactivado por defecto | No | No | No | No | Sí [n 31] [146] | No | Mitigado | No afectado | Vulnerable | Vulnerable | Mitigado [150] | Mitigado [151] | Sí [n 10] | ||
7 , 8 | Desactivado de forma predeterminada [147] | Habilitado por defecto | Sí [147] | No | No | No | sí | Sí [n 31] [146] | No | Mitigado | No afectado | Vulnerable | Vulnerable | Mitigado [150] | Mitigado [151] | Sí [n 10] | |||
7 , 8 , 9 | Windows Vista | Desactivado por defecto | Habilitado por defecto | sí | No | No | No | sí | sí | Sí [74] | Mitigado | No afectado | Vulnerable | Vulnerable | Mitigado [150] | Mitigado [151] | Sí [n 10] | ||
7 , 8 , 9 | Servidor 2008 | Desactivado por defecto | Habilitado por defecto | sí | Desactivado por defecto [152] (KB4019276) | Desactivado por defecto [152] (KB4019276) | No | sí | sí | Sí [74] | Mitigado | No afectado | Vulnerable | Vulnerable | Mitigado [150] | Mitigado [151] | Sí [n 10] | ||
8 , 9 , 10 | De Windows 7 / 8 Servidor 2008 R2 / 2012 | Desactivado por defecto | Habilitado por defecto | sí | Desactivado por defecto [153] | Desactivado por defecto [153] | No | sí | sí | sí | Mitigado | No afectado | Vulnerable | Prioridad más baja [154] [n 32] | Mitigado [150] | Mitigado [151] | Sí [n 10] | ||
Internet Explorer 11 [n 28] | 11 | Windows 7 Server 2008 R2 | Desactivado por defecto | Deshabilitado por defecto [n 33] | sí | Sí [156] | Sí [156] | No | sí | sí | sí | Mitigado | No afectado | Mitigado [n 33] | Desactivado por defecto [160] | Mitigado [150] | Mitigado [151] | Sí [n 10] | |
11 [161] | Windows 8.1 | Desactivado por defecto | Deshabilitado por defecto [n 33] | sí | Sí [156] | Sí [156] | No | sí | sí | sí | Mitigado | No afectado | Mitigado [n 33] | Desactivado por defecto [n 16] | Mitigado [150] | Mitigado [151] | Sí [n 10] | ||
Servidor 2012 Servidor 2012 R2 | |||||||||||||||||||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Microsoft Edge (12-18) (basado en EdgeHTML) Solo cliente Internet Explorer 11 [n 28] | 11 | 12-13 | Windows 10 1507–1511 | Desactivado por defecto | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] |
11 | 14-18 (solo cliente) | Windows 10 1607-1909 Windows Server (SAC) 1709-1909 | No [162] | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | |
11 | 18 (solo cliente) | Windows 10 2004 Windows Server (SAC) 2004 | No | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | |
Internet Explorer 11 [n 28] | 11 | Windows 10 20H2 Servidor de Windows (SAC) 20H2 | No | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | |
11 | Windows 10 21H1 Servidor de Windows (SAC) 21H1 | No | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | ||
11 | Windows 10 21H2 Servidor de Windows (SAC) 21H2 | No | Desactivado por defecto | sí | sí | sí | Sí [163] | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | ||
11 | Ventanas 11 | No | Desactivado por defecto | sí | sí | sí | sí | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | ||
Versiones de Internet Explorer 11 [n 28] LTSC | 11 | Windows 10 LTSB 2015 (1507) | Desactivado por defecto | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | |
11 | Windows 10 LTSB 2016 (1607) | No [162] | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | ||
11 | Windows Server 2016 (LTSB / 1607) | No [162] | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | ||
11 | Windows 10 LTSC 2019 (1809) Windows Server 2019 (LTSC / 1809) | No | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | ||
11 | Windows 10 LTSC 2022 (21H2) Windows Server 2022 (LTSC / 21H2) | No | Desactivado por defecto | sí | sí | sí | Sí [163] | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | Sí [n 10] | ||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Microsoft Internet Explorer Mobile [n 28] | 7, 9 | Windows Phone 7, 7.5, 7.8 | Desactivado de forma predeterminada [147] | Habilitado por defecto | sí | No [ cita requerida ] | No [ cita requerida ] | No | No [ cita requerida ] | sí | Sí [164] | Desconocido | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | Solo con herramientas de terceros [n 34] | |
10 | Windows Phone 8 | Desactivado por defecto | Habilitado por defecto | sí | Deshabilitado por defecto [166] | Deshabilitado por defecto [166] | No | No [ cita requerida ] | sí | Sí [167] | Mitigado | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | Solo con herramientas de terceros [n 34] | ||
11 | Windows Phone 8.1 | Desactivado por defecto | Habilitado por defecto | sí | Sí [168] | Sí [168] | No | No [ cita requerida ] | sí | sí | Mitigado | No afectado | Vulnerable | Solo como alternativa [n 15] [169] [170] | Vulnerable | Vulnerable | Solo con herramientas de terceros [n 34] | ||
Microsoft Edge (13-15) (basado en EdgeHTML) [n 35] | 13 | Windows 10 Mobile 1511 | Desactivado por defecto | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | |
14, 15 | Windows 10 Mobile 1607–1709 | No [162] | Desactivado por defecto | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Apple Safari [n. 36] | 1 | Mac OS X 10.2 , 10.3 | No [175] | sí | sí | No | No | No | No | No | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | |
2-5 | Mac OS X 10.4 , 10.5 , Windows XP | No | sí | sí | No | No | No | desde v3.2 | No | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | ||
3-5 | Vista , gana 7 | No | sí | sí | No | No | No | desde v3.2 | No | Sí [164] | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | ||
4-6 | Mac OS X 10.6 , 10.7 | No | sí | sí | No | No | No | sí | Sí [73] | Sí [74] | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | ||
6 | OS X 10.8 | No | sí | sí | No | No | No | sí | sí | Sí [74] | Mitigado [n 37] | No afectado | Mitigado [n 38] | Vulnerable [n 38] | Mitigado [181] | Vulnerable | No | ||
7, 9 | OS X 10.9 | No | sí | sí | Sí [182] | Sí [182] | No | sí | sí | sí | Mitigado [177] | No afectado | Mitigado [n 38] | Vulnerable [n 38] | Mitigado [181] | Vulnerable | No | ||
8-10 | OS X 10.10 | No | sí | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado [n 38] | Prioridad más baja [183] [n 38] | Mitigado [181] | Mitigado [184] | No | ||
9-11 | OS X 10.11 | No | No | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | No afectado | Prioridad más baja | Mitigado | Mitigado | No | ||
10-13 | macOS 10.12 , 10.13 | No | No | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
12, 13 | 14 | macOS 10.14 | No | No | sí | sí | sí | Sí (desde macOS 10.14.4) [185] | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | |
13 | 14 | macOS 10.15 | No | No | sí | sí | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | |
14 | macOS 11 | No | No | sí | sí | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
15 | macOS 12 | No | No | Desconocido | Desconocido | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario | |
Apple Safari (móvil) [n 39] | 3 | iPhone OS 1 , 2 | No [189] | sí | sí | No | No | No | No | No | No | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | |
4, 5 | iPhone OS 3 , iOS 4 | No | sí | sí | No | No | No | Sí [190] | sí | desde iOS 4 [164] | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | ||
5, 6 | iOS 5 , 6 | No | sí | sí | Sí [186] | Sí [186] | No | sí | sí | sí | Vulnerable | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | ||
7 | ios 7 | No | sí | sí | sí | sí | No | sí | sí | Sí [191] | Mitigado [192] | No afectado | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | ||
8 | iOS 8 | No | sí | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | Mitigado [n 38] | Prioridad más baja [193] [n 38] | Mitigado [194] | Mitigado [195] | No | ||
9 | iOS 9 | No | No | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | No afectado | Prioridad más baja | Mitigado | Mitigado | No | ||
10-11 | iOS 10 , 11 | No | No | sí | sí | sí | No | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
12 | iOS 12 | No | No | sí | sí | sí | Sí (desde iOS 12.2) [185] | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
13 | iOS 13 | No | No | sí | sí | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
iPadOS 13 | |||||||||||||||||||
14 | iOS 14 | No | No | sí | sí | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
iPadOS 14 | |||||||||||||||||||
15 | iOS 15 | No | No | Desconocido | Desconocido | sí | sí | sí | sí | sí | Mitigado | No afectado | No afectado | Desactivado por defecto [n 16] | Mitigado | Mitigado | No | ||
iPadOS 15 | |||||||||||||||||||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | EV [n 3] | SHA-2 | ECDSA | BESTIA [n 4] | DELITO [n 5] | CANICHE (SSLv3) [n 6] | RC4 [n 7] | FREAK [75] [76] | Atolladero | Selección de protocolo por usuario | |
Sistema operativo Android de Google [196] | Android 1.0–4.0.4 | No | Habilitado por defecto | sí | No | No | No | Desconocido | Sí [73] | desde 3.0 [164] [74] | Desconocido | Desconocido | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | ||
Android 4.1–4.4.4 | No | Habilitado por defecto | sí | Desactivado por defecto [197] | Desactivado por defecto [197] | No | Desconocido | sí | sí | Desconocido | Desconocido | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | |||
Android 5.0–5.0.2 | No | Habilitado por defecto | sí | Sí [197] [198] | Sí [197] [198] | No | Desconocido | sí | sí | Desconocido | Desconocido | Vulnerable | Vulnerable | Vulnerable | Vulnerable | No | |||
Android 5.1–5.1.1 | No | Deshabilitado de forma predeterminada [ cita requerida ] | sí | sí | sí | No | Desconocido | sí | sí | Desconocido | Desconocido | No afectado | Solo como alternativa [n 15] | Mitigado | Mitigado | No | |||
Android 6.0 - 7.1.2 | No | Deshabilitado de forma predeterminada [ cita requerida ] | sí | sí | sí | No | Desconocido | sí | sí | Desconocido | Desconocido | No afectado | Desactivado por defecto | Mitigado | Mitigado | No | |||
Android 8.0 - 9 | No | No [199] | sí | sí | sí | No | Desconocido | sí | sí | Desconocido | Desconocido | No afectado | Desactivado por defecto | Mitigado | Mitigado | No | |||
Android 10 | No | No | sí | sí | sí | sí | Desconocido | sí | sí | Desconocido | Desconocido | No afectado | Desactivado por defecto | Mitigado | Mitigado | No | |||
Android 11 | No | No | sí | sí | sí | sí | Desconocido | sí | sí | Desconocido | Desconocido | No afectado | Desactivado por defecto | Mitigado | Mitigado | No | |||
Android 12 | No | No | Desconocido | Desconocido | sí | sí | Desconocido | sí | sí | Desconocido | Desconocido | No afectado | Desactivado por defecto | Mitigado | Mitigado | No | |||
Navegador | Versión | Plataformas | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 (obsoleto) | TLS 1.1 (obsoleto) | TLS 1.2 | TLS 1.3 | Certificado EV | Certificado SHA-2 | Certificado ECDSA | BESTIA | CRIMEN | CANICHE (SSLv3) | RC4 | FENÓMENO | Atolladero | Selección de protocolo por usuario |
Color o nota | Significado | |
---|---|---|
Versión del navegador | Plataforma | |
Versión del navegador | Sistema operativo | Lanzamiento futuro; en desarrollo |
Versión del navegador | Sistema operativo | Última versión actual |
Versión del navegador | Sistema operativo | Antiguo lanzamiento; todavía apoyado |
Versión del navegador | Sistema operativo | Antiguo lanzamiento; El apoyo a largo plazo sigue activo, pero terminará en menos de 12 meses. |
Versión del navegador | Sistema operativo | Antiguo lanzamiento; ya no es compatible |
n / A | Sistema operativo | Mixto / No especificado |
Sistema operativo (versión +) | Versión mínima requerida del sistema operativo (para versiones compatibles del navegador) | |
Ya no es compatible con este sistema operativo |
- Notas
- ^ ¿El navegador tiene mitigaciones o no es vulnerable a los ataques conocidos? Tenga en cuenta que la seguridad real depende de otros factores, como el cifrado negociado, la fuerza del cifrado, etc. (consulte la sección Tabla de cifrado ).
- ^ Si un usuario o administrador puede elegir los protocolos que se utilizarán o no. En caso afirmativo, se pueden evitar varios ataques como BEAST (vulnerable en SSL 3.0 y TLS 1.0) o POODLE (vulnerable en SSL 3.0).
- ^ a b Si EV SSL y DV SSL (SSL normal) se pueden distinguir mediante indicadores (icono de candado verde, barra de direcciones verde, etc.) o no.
- ^ a b p. ej. División de registros 1 / n-1.
- ^ a b p. ej. Deshabilitar la compresión de encabezado en HTTPS / SPDY.
- ^ a b
- Mitigaciones completas; deshabilitar SSL 3.0 en sí, "división de registros anti-POODLE". La "división de registros Anti-POODLE" es efectiva solo con la implementación del lado del cliente y es válida de acuerdo con la especificación SSL 3.0; sin embargo, también puede causar problemas de compatibilidad debido a problemas en las implementaciones del lado del servidor.
- Mitigaciones parciales; deshabilitar el respaldo a SSL 3.0, TLS_FALLBACK_SCSV, deshabilitar los conjuntos de cifrado con el modo de operación CBC . Si el servidor también admite TLS_FALLBACK_SCSV, el ataque POODLE fallará contra esta combinación de servidor y navegador, pero las conexiones en las que el servidor no admite TLS_FALLBACK_SCSV y sí admite SSL 3.0 seguirán siendo vulnerables. Si deshabilita los conjuntos de cifrado con el modo de operación CBC en SSL 3.0, solo están disponibles los conjuntos de cifrado con RC4, los ataques RC4 se vuelven más fáciles.
- Al deshabilitar SSL 3.0 manualmente, el ataque POODLE fallará.
- ^ a b
- Mitigación completa; deshabilitar conjuntos de cifrado con RC4.
- Mitigaciones parciales para mantener la compatibilidad con sistemas antiguos; estableciendo la prioridad de RC4 a menor.
- ^ Google Chrome (y Chromium ) admite TLS 1.0 y TLS 1.1 de la versión 22 (se agregó y luego se eliminó de la versión 21). Se agregó compatibilidad con TLS 1.2 y luego se eliminó de Chrome 29. [77] [78] [79]
- ^ Utiliza la implementación de TLS proporcionada por BoringSSL para Android, OS X y Windows [80] o por NSS para Linux. Google está cambiando la biblioteca TLS utilizada en Chrome a BoringSSL de NSS por completo.
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar configurar habilitación / deshabilitación de cada protocolo a través de configuración / opción (el nombre del menú depende de los navegadores)
- ^ a b c d e f g h i j k l m n o p q r s t u v configurar la versión máxima y mínima de los protocolos de habilitación con la opción de línea de comandos
- ^ TLS_FALLBACK_SCSV está implementado. [88] El respaldo a SSL 3.0 está deshabilitado desde la versión 39. [89]
- ^ Además de TLS_FALLBACK_SCSV y deshabilitar una alternativa a SSL 3.0, SSL 3.0 en sí está deshabilitado de forma predeterminada. [89]
- ^ a b c configure la versión mínima de los protocolos de habilitación a través de chrome: // flags [93] (la versión máxima se puede configurar con la opción de línea de comandos)
- ^ a b c d e f g h i Sólo cuando no haya disponibles conjuntos de cifrado con otro que no sea RC4, los conjuntos de cifrado con RC4 se utilizarán como reserva.
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq Todos los conjuntos de cifrado RC4 están deshabilitados por defecto.
- ^ Utiliza la implementación de TLS proporcionada por NSS . A partir de Firefox 22, Firefox solo admite TLS 1.0 a pesar de que el NSS incluido es compatible con TLS 1.1. Desde Firefox 23, TLS 1.1 se puede habilitar, pero no se habilitó de forma predeterminada debido a problemas. Firefox 24 tiene la compatibilidad con TLS 1.2 deshabilitada de forma predeterminada. TLS 1.1 y TLS 1.2 se han habilitado de forma predeterminada en la versión 27 de Firefox.
- ^ a b c d e f g h i j k l m n configure la versión máxima y mínima de los protocolos de habilitación a través de about: config
- ^ SSL 3.0 en sí está deshabilitado de forma predeterminada. [111] Además, el respaldo a SSL 3.0 está deshabilitado desde la versión 34, [113] y TLS_FALLBACK_SCSV está implementado desde 35.0 y ESR 31.3. [111] [114]
- ^ Opera 10 agregó soporte para TLS 1.2 a partir de Presto 2.2. El soporte anterior era para TLS 1.0 y 1.1. TLS 1.1 y 1.2 están deshabilitados de forma predeterminada (excepto para la versión 9 [124] que habilitó TLS 1.1 de forma predeterminada).
- ^ a b SSL 3.0 está deshabilitado de forma remota de forma predeterminada desde el 15 de octubre de 2014 [133]
- ^ La compatibilidad con TLS de Opera 14 y superior es la misma que la de Chrome, porque Opera ha migrado albackend de Chromium (Opera 14 para Android se basa en Chromium 26 con WebKit , [138] y Opera 15 y superior se basan en Chromium 28 y superior con Blink [139] ).
- ^ TLS_FALLBACK_SCSV está implementado. [142]
- ^ SSL 3.0 está habilitado de forma predeterminada, con algunas mitigaciones contra vulnerabilidades conocidas como BEAST y POODLE implementadas. [133]
- ^ Además de TLS_FALLBACK_SCSV, se implementa la "división de registros anti-POODLE". [133]
- ^ Además de TLS_FALLBACK_SCSV y la "división de registros anti-POODLE", SSL 3.0 está deshabilitado de forma predeterminada. [93]
- ^ a b c configure la versión mínima de los protocolos de habilitación a través de opera: // flags [93] (la versión máxima se puede configurar con la opción de línea de comandos)
- ^ a b c d e f IE utiliza la implementación TLS del sistema operativo Microsoft Windows proporcionada por el proveedor de soporte de seguridad SChannel . TLS 1.1 y 1.2 están deshabilitados de forma predeterminada hasta IE11. [143] [144]
- ^ a b Windows NT 3.1 es compatible con IE 1–2, Windows NT 3.5 es compatible con IE 1–3, Windows NT 3.51 y Windows NT 4.0 es compatible con IE 1–6
- ^ a b c d Windows XP, así como Server 2003 y versiones anteriores, solo admiten cifrados débiles como 3DES y RC4 listos para usar. [148] Los cifrados débiles de esta versión de SChannel no solo se utilizan para IE, sino también para otros productos de Microsoft que se ejecutan en este sistema operativo, como Office o Windows Update. Solo Windows Server 2003 puede obtener una actualización manual para admitir cifrados AES por KB948963 [149]
- ^ a b c d MS13-095 o MS14-049 para 2003 y XP-64 o SP3 para XP (32 bits)
- ^ RC4 se puede deshabilitar excepto como un recurso alternativo (solo cuando no haya disponibles conjuntos de cifrado que no sean RC4, los conjuntos de cifrado con RC4 se utilizarán como un recurso alternativo). [155]
- ^ a b c d El respaldo a SSL 3.0 son los sitios bloqueados de forma predeterminada en Internet Explorer 11 para el modo protegido. [157] [158] SSL 3.0 está deshabilitado de forma predeterminada en Internet Explorer 11 desde abril de 2015. [159]
- ^ a b c Se puede desactivar mediante la edición del registro, pero se necesitan herramientas de terceros para hacerlo. [165]
- ^ Edge (anteriormente conocido como Project Spartan) se basa en una bifurcación del motor de renderizado de Internet Explorer 11.
- ^ Safari usa la implementación del sistema operativo en Mac OS X, Windows (XP, Vista, 7) [171] con versión desconocida, [172] Safari 5 es la última versión disponible para Windows. OS X 10.8 en adelante tiene soporte SecureTransport para TLS 1.1 y 1.2 [173] El informe SSL de Qualys simula Safari 5.1.9 conectando con TLS 1.0 no 1.1 o 1.2 [174]
- ^ En septiembre de 2013, Apple implementó lamitigación BEAST en OS X 10.8 (Mountain Lion), pero no estaba activada de forma predeterminada, lo que hace que Safari siga siendo teóricamente vulnerable al ataque BEAST en esa plataforma. [176] [177] La mitigación de BEAST se ha habilitado de forma predeterminada desde OS X 10.8.5 actualizado en febrero de 2014. [178]
- ^ a b c d e f g h Debido a que Apple eliminó el soporte para todos los protocolos CBC en SSL 3.0 para mitigar POODLE, [179] [180] esto deja solo RC4, que también está completamente roto por los ataques RC4 en SSL 3.0.
- ^ Mobile Safari y el software de terceros que utilizan la biblioteca UIWebView del sistema utilizan laimplementación del sistema operativo iOS , que admite TLS 1.2 a partir de iOS 5.0. [186] [187] [188]
Bibliotecas
La mayoría de las bibliotecas de programación SSL y TLS son software gratuito y de código abierto .
- BoringSSL , una bifurcación de OpenSSL para Chrome / Chromium y Android, así como otras aplicaciones de Google.
- Botan , una biblioteca criptográfica con licencia BSD escrita en C ++.
- BSAFE Micro Edition Suite: una implementación multiplataforma de TLS escrita en C utilizando un módulo criptográfico validado por FIPS
- BSAFE SSL-J: una biblioteca TLS que proporciona una API patentada y una API JSSE , utilizando un módulo criptográfico validado por FIPS
- cryptlib : una biblioteca de criptografía de código abierto portátil (incluye implementación TLS / SSL)
- Los programadores de Delphi pueden usar una biblioteca llamada Indy que utiliza OpenSSL o, alternativamente, ICS que ahora es compatible con TLS 1.3.
- GnuTLS : una implementación gratuita (con licencia LGPL)
- Java Secure Socket Extension : una implementación de Java incluida en Java Runtime Environment admitía TLS 1.1 y 1.2 a partir de Java 7. (TLS 1.1 / 1.2 se deshabilitó inicialmente de forma predeterminada para el cliente en Java 7, pero se habilitó en enero de 2017. [200] ) Java 11 es compatible con TLS 1.3. [201] [202]
- LibreSSL : una bifurcación de OpenSSL por el proyecto OpenBSD.
- MatrixSSL : una implementación con licencia dual
- mbed TLS (anteriormente PolarSSL): una pequeña implementación de biblioteca SSL para dispositivos integrados que está diseñada para facilitar su uso
- Servicios de seguridad de red : biblioteca de código abierto validada por FIPS 140
- OpenSSL : una implementación gratuita (licencia BSD con algunas extensiones)
- SChannel : una implementación de SSL y TLS Microsoft Windows como parte de su paquete.
- Transporte seguro : una implementación de SSL y TLS utilizada en OS X e iOS como parte de sus paquetes.
- wolfSSL (anteriormente CyaSSL): Biblioteca SSL / TLS integrada con un fuerte enfoque en la velocidad y el tamaño.
Implementación | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
---|---|---|---|---|---|---|
Botan | No | No [203] | sí | sí | sí | |
Suite BSAFE Micro Edition | No | Desactivado por defecto | sí | sí | sí | En desarrollo |
BSAFE SSL-J | No | Desactivado por defecto | sí | sí | sí | sí |
cryptlib | No | Desactivado de forma predeterminada en el momento de la compilación | sí | sí | sí | |
GnuTLS | No [a] | Deshabilitado de forma predeterminada [204] | sí | sí | sí | Sí [205] |
Extensión de Java Secure Socket | No [a] | Deshabilitado de forma predeterminada [206] | sí | sí | sí | sí |
LibreSSL | No [207] | No [208] | sí | sí | sí | A partir de la versión 3.2.2 [209] [210] |
MatrixSSL | No | Desactivado de forma predeterminada en el momento de la compilación [211] | sí | sí | sí | sí (versión borrador) |
mbed TLS (anteriormente PolarSSL) | No | Deshabilitado por defecto [212] | sí | sí | sí | |
Servicios de seguridad de red | No [b] | Deshabilitado de forma predeterminada [213] | sí | Sí [214] | Sí [215] | Sí [216] |
OpenSSL | No [217] | Habilitado por defecto | sí | Sí [218] | Sí [218] | Sí [219] |
SChannel XP / 2003 [220] | Deshabilitado por defecto por MSIE 7 | Habilitado por defecto | Habilitado por defecto por MSIE 7 | No | No | No |
SChannel Vista [221] | Desactivado por defecto | Habilitado por defecto | sí | No | No | No |
SCanal 2008 [221] | Desactivado por defecto | Habilitado por defecto | sí | Deshabilitado de forma predeterminada (KB4019276) [152] | Deshabilitado de forma predeterminada (KB4019276) [152] | No |
SCanal 7/2008 R2 [222] | Desactivado por defecto | Deshabilitado por defecto en MSIE 11 | sí | Habilitado por defecto por MSIE 11 | Habilitado por defecto por MSIE 11 | No |
SCanal 8/2012 [222] | Desactivado por defecto | Habilitado por defecto | sí | Desactivado por defecto | Desactivado por defecto | No |
SCanal 8.1 / 2012 R2, 10 v1507 y v1511 [222] | Desactivado por defecto | Deshabilitado por defecto en MSIE 11 | sí | sí | sí | No |
SCanal 10 v1607 / 2016 [162] | No | Desactivado por defecto | sí | sí | sí | No |
SCanal 10 v1903 [223] | No | Desactivado por defecto | sí | sí | sí | No |
SCanal 10 v21H1 [224] | No | Desactivado por defecto | sí | sí | sí | No |
Transporte seguro OS X 10.2–10.8 / iOS 1–4 | sí | sí | sí | No | No | |
Transporte seguro OS X 10.9–10.10 / iOS 5–8 | No [c] | sí | sí | Si [c] | Si [c] | |
Transporte seguro OS X 10.11 / iOS 9 | No | No [c] | sí | sí | sí | |
Biblioteca Seed7 TLS / SSL | No | sí | sí | sí | sí | |
wolfSSL (anteriormente CyaSSL) | No | Deshabilitado de forma predeterminada [225] | sí | sí | sí | Sí [226] |
Implementación | SSL 2.0 (inseguro) | SSL 3.0 (inseguro) | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
- ^El saludo del cliente SSL 2.0 es compatible aunque SSL 2.0 no es compatible o está deshabilitado debido a las compatibilidades con versiones anteriores.
- ^La implementación del lado del servidor del protocolo SSL / TLS aún admite el procesamiento de los mensajes de saludo del cliente compatibles con v2 recibidos. [227]
- ^Transporte seguro: SSL 2.0 se suspendió en OS X 10.8. SSL 3.0 se suspendió en OS X 10.11 e iOS 9. TLS 1.1 y 1.2 están disponibles en iOS 5.0 y posteriores, y OS X 10.9 y posteriores. [228][229]
Un documento presentado en la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones [230] mostró que pocas aplicaciones utilizaban correctamente algunas de estas bibliotecas SSL, lo que generaba vulnerabilidades. Según los autores
"la causa raíz de la mayoría de estas vulnerabilidades es el terrible diseño de las API para las bibliotecas SSL subyacentes. En lugar de expresar propiedades de seguridad de alto nivel de los túneles de red, como la confidencialidad y la autenticación, estas API exponen detalles de bajo nivel del protocolo SSL a los desarrolladores de aplicaciones. Como consecuencia, los desarrolladores a menudo utilizan las API de SSL de forma incorrecta, malinterpretando y malinterpretando sus múltiples parámetros, opciones, efectos secundarios y valores de retorno ".
Otros usos
El Protocolo simple de transferencia de correo (SMTP) también puede protegerse mediante TLS. Estas aplicaciones utilizan certificados de clave pública para verificar la identidad de los puntos finales.
TLS también se puede utilizar para tunelizar una pila de red completa para crear una VPN , que es el caso de OpenVPN y OpenConnect . Muchos proveedores ya han combinado las capacidades de autenticación y cifrado de TLS con autorización. También ha habido un desarrollo sustancial desde finales de la década de 1990 en la creación de tecnología cliente fuera de los navegadores web, con el fin de permitir el soporte para aplicaciones cliente / servidor. En comparación con las tecnologías VPN IPsec tradicionales , TLS tiene algunas ventajas inherentes en el firewall y el cruce de NAT que facilitan la administración para grandes poblaciones de acceso remoto.
TLS también es un método estándar para proteger la señalización de aplicaciones del Protocolo de inicio de sesión (SIP). TLS se puede utilizar para proporcionar autenticación y cifrado de la señalización SIP asociada con VoIP y otras aplicaciones basadas en SIP. [231]
Seguridad
SSL 2.0
SSL 2.0 tenía varias fallas: [232]
- Se utilizaron claves criptográficas idénticas para la autenticación y el cifrado de mensajes . (En SSL 3.0, los secretos MAC pueden ser más grandes que las claves de cifrado, por lo que los mensajes pueden permanecer a prueba de manipulaciones incluso si las claves de cifrado están dañadas. [233] )
- SSL 2.0 tenía una construcción MAC débil que usaba la función hash MD5 con un prefijo secreto, lo que lo hacía vulnerable a los ataques de extensión de longitud .
- SSL 2.0 no tenía ninguna protección para el protocolo de enlace, lo que significa que un ataque de degradación de hombre en el medio podría pasar desapercibido.
- SSL 2.0 utilizó la conexión TCP cercana para indicar el final de los datos. Esto significó que los ataques de truncamiento eran posibles: el atacante simplemente falsifica un FIN de TCP, dejando al destinatario inconsciente de un mensaje de fin de datos ilegítimo (SSL 3.0 solucionó este problema al tener una alerta de cierre explícita).
- SSL 2.0 asumió un solo servicio y un certificado de dominio fijo, lo que chocaba con la característica estándar del alojamiento virtual en los servidores web. Esto significa que la mayoría de los sitios web se vieron prácticamente perjudicados por el uso de SSL.
SSL 2.0 estaba deshabilitado de forma predeterminada, comenzando con Internet Explorer 7 , [234] Mozilla Firefox 2, [235] Opera 9.5, [236] y Safari . El soporte para SSL 2.0 (y cifrados débiles de 40 y 56 bits) se eliminó por completo de Opera a partir de la versión 10. [237] [238]
SSL 3.0
SSL 3.0 mejoró sobre SSL 2.0 al agregar cifrados basados en SHA-1 y compatibilidad con la autenticación de certificados.
Desde el punto de vista de la seguridad, SSL 3.0 debe considerarse menos deseable que TLS 1.0. Los conjuntos de cifrado SSL 3.0 tienen un proceso de derivación de claves más débil; la mitad de la clave maestra que se establece depende completamente de la función hash MD5, que no es resistente a colisiones y, por lo tanto, no se considera segura. Bajo TLS 1.0, la clave maestra que se establece depende tanto de MD5 como de SHA-1, por lo que su proceso de derivación no se considera actualmente débil. Es por esta razón que las implementaciones de SSL 3.0 no se pueden validar bajo FIPS 140-2. [239]
En octubre de 2014, se informó de una vulnerabilidad en el diseño de SSL 3.0, por la cual el modo de operación CBC con SSL 3.0 se volvió vulnerable al ataque de relleno (ver ataque #POODLE ).
TLS
TLS tiene una variedad de medidas de seguridad:
- Protección contra una degradación del protocolo a una versión anterior (menos segura) o un conjunto de cifrado más débil.
- Numerar los registros de aplicaciones posteriores con un número de secuencia y utilizar este número de secuencia en los códigos de autenticación de mensajes (MAC).
- Uso de un resumen de mensajes mejorado con una clave (para que solo un titular de la clave pueda verificar la MAC). La construcción HMAC utilizada por la mayoría de los conjuntos de cifrado TLS se especifica en RFC 2104 (SSL 3.0 utilizó una MAC diferente basada en hash).
- El mensaje que finaliza el apretón de manos ("Finalizado") envía un hash de todos los mensajes de apretón de manos intercambiados vistos por ambas partes.
- La función pseudoaleatoria divide los datos de entrada a la mitad y procesa cada uno con un algoritmo hash diferente ( MD5 y SHA-1 ), luego los XOR los junta para crear el MAC. Esto proporciona protección incluso si uno de estos algoritmos resulta vulnerable.
Ataques contra TLS / SSL
Los ataques importantes contra TLS / SSL se enumeran a continuación.
En febrero de 2015, IETF emitió un RFC informativo [240] que resume los diversos ataques conocidos contra TLS / SSL.
Ataque de renegociación
En agosto de 2009 se descubrió una vulnerabilidad del procedimiento de renegociación que puede provocar ataques de inyección de texto sin formato contra SSL 3.0 y todas las versiones actuales de TLS. [241] Por ejemplo, permite a un atacante que puede secuestrar una conexión https empalmar sus propias solicitudes al comienzo de la conversación que el cliente tiene con el servidor web. En realidad, el atacante no puede descifrar la comunicación cliente-servidor, por lo que es diferente de un ataque típico de intermediario. Una solución a corto plazo es que los servidores web dejen de permitir la renegociación, que normalmente no requerirá otros cambios a menos que se utilice la autenticación del certificado del cliente . Para corregir la vulnerabilidad, se propuso una extensión de indicación de renegociación para TLS. Requerirá que el cliente y el servidor incluyan y verifiquen información sobre apretones de manos anteriores en cualquier apretón de manos de renegociación. [242] Esta extensión se ha convertido en una norma propuesta y se le ha asignado el número RFC 5746 . Varias bibliotecas han implementado el RFC. [243] [244] [245]
Ataques de degradación: FREAK ataque y Ataque de atasco
Un ataque de degradación de protocolo (también llamado ataque de reversión de versión) engaña a un servidor web para que negocie conexiones con versiones anteriores de TLS (como SSLv2) que hace tiempo que se abandonaron como inseguras.
Las modificaciones anteriores a los protocolos originales, como False Start [246] (adoptado y habilitado por Google Chrome [247] ) o Snap Start , supuestamente introdujeron ataques limitados de degradación del protocolo TLS [248] o permitieron modificaciones a la lista de conjuntos de cifrado enviada por el cliente al servidor. Al hacerlo, un atacante podría tener éxito en influir en la selección del conjunto de cifrado en un intento de degradar el conjunto de cifrado negociado para utilizar un algoritmo de cifrado simétrico más débil o un intercambio de claves más débil. [249] Un documento presentado en una conferencia de ACM sobre seguridad informática y de comunicaciones en 2012 demostró que la extensión False Start estaba en riesgo: en determinadas circunstancias, podría permitir a un atacante recuperar las claves de cifrado sin conexión y acceder a los datos cifrados. [250]
Los ataques de degradación de cifrado pueden obligar a los servidores y clientes a negociar una conexión utilizando claves criptográficamente débiles. En 2014, se descubrió un ataque de intermediario llamado FREAK que afectaba a la pila OpenSSL , el navegador web predeterminado de Android y algunos navegadores Safari . [251] El ataque implicó engañar a los servidores para que negociaran una conexión TLS utilizando claves de cifrado de 512 bits criptográficamente débiles.
Logjam es un exploit de seguridad descubierto en mayo de 2015 que aprovecha la opción de utilizar grupos Diffie-Hellman de 512 bits "de grado de exportación" heredados que se remontan a la década de 1990. [252] Obliga a los servidores susceptibles a degradarse a grupos Diffie-Hellman de 512 bits criptográficamente débiles. Un atacante puede deducir las claves que el cliente y el servidor determinan mediante el intercambio de claves Diffie-Hellman .
Ataques entre protocolos: DROWN
El ataque DROWN es un exploit que ataca a los servidores que admiten conjuntos de protocolos SSL / TLS contemporáneos al explotar su soporte para el protocolo SSLv2 obsoleto e inseguro para aprovechar un ataque a las conexiones que utilizan protocolos actualizados que de otro modo serían seguros. [253] [254] DROWN aprovecha una vulnerabilidad en los protocolos utilizados y la configuración del servidor, en lugar de un error de implementación específico. Los detalles completos de DROWN se anunciaron en marzo de 2016, junto con un parche para el exploit. En ese momento, más de 81.000 del millón de sitios web más populares se encontraban entre los sitios web protegidos por TLS que eran vulnerables al ataque DROWN. [254]
Ataque de la BESTIA
El 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una prueba de concepto llamada BEAST ( Exploit del navegador contra SSL / TLS ) [255] utilizando un subprograma de Java para violar las restricciones de la política de origen , para un encadenamiento de bloques de cifrado conocido desde hace mucho tiempo (CBC ) vulnerabilidad en TLS 1.0: [256] [257] un atacante que observa 2 bloques de texto cifrado consecutivos C0, C1 puede probar si el bloque de texto sin formato P1 es igual ax eligiendo el siguiente bloque de texto sin formato P2 = x C0 C1; según la operación CBC, C2 = E (C1 P2) = E (C1 X C0 C1) = E (C0 x), que será igual a C1 si x = P1. No se habían demostrado previamente exploits prácticos para esta vulnerabilidad , que fue descubierta originalmente por Phillip Rogaway [258] en 2002. La vulnerabilidad del ataque se había solucionado con TLS 1.1 en 2006, pero TLS 1.1 no había tenido una amplia adopción antes de este ataque. demostración.
RC4 como cifrado de flujo es inmune al ataque BEAST. Por lo tanto, RC4 se usó ampliamente como una forma de mitigar el ataque BEAST en el lado del servidor. Sin embargo, en 2013, los investigadores encontraron más debilidades en RC4. A partir de entonces, ya no se recomendaba habilitar RC4 en el lado del servidor. [259]
Los propios Chrome y Firefox no son vulnerables a los ataques BEAST, [81] [102] sin embargo, Mozilla actualizó sus bibliotecas NSS para mitigar los ataques tipo BEAST . Mozilla Firefox y Google Chrome utilizan NSS para implementar SSL. Algunos servidores web que tienen una implementación defectuosa de la especificación SSL pueden dejar de funcionar como resultado. [260]
Microsoft publicó el boletín de seguridad MS12-006 el 10 de enero de 2012, que solucionó la vulnerabilidad BEAST al cambiar la forma en que el componente de canal seguro de Windows ( SChannel ) transmite paquetes de red cifrados desde el servidor. [261] Los usuarios de Internet Explorer (antes de la versión 11) que se ejecutan en versiones anteriores de Windows ( Windows 7 , Windows 8 y Windows Server 2008 R2 ) pueden restringir el uso de TLS a 1.1 o superior.
Apple solucionó la vulnerabilidad BEAST implementando la división 1 / n-1 y activándola de forma predeterminada en OS X Mavericks , lanzada el 22 de octubre de 2013. [262]
Ataques de CRIMEN e INCUMPLIMIENTO
Los autores del ataque BEAST también son los creadores del ataque CRIME posterior , que puede permitir que un atacante recupere el contenido de las cookies web cuando se utiliza la compresión de datos junto con TLS. [263] [264] Cuando se utiliza para recuperar el contenido de las cookies de autenticación secretas , permite que un atacante realice un secuestro de sesión en una sesión web autenticada.
Si bien el ataque CRIME se presentó como un ataque general que podría funcionar eficazmente contra una gran cantidad de protocolos, incluidos, entre otros, TLS, y protocolos de capa de aplicación como SPDY o HTTP , solo se demostraron y mitigaron en gran medida las vulnerabilidades contra TLS y SPDY. en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, aunque los autores de CRIME han advertido que esta vulnerabilidad podría estar aún más extendida que la compresión SPDY y TLS combinadas. En 2013 , se anunció una nueva instancia del ataque CRIME contra la compresión HTTP, denominado BREACH . Basado en el ataque CRIME, un ataque BREACH puede extraer tokens de inicio de sesión, direcciones de correo electrónico u otra información confidencial del tráfico web cifrado TLS en tan solo 30 segundos (dependiendo de la cantidad de bytes que se extraerán), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso o puede inyectar contenido en páginas válidas que el usuario está visitando (por ejemplo, una red inalámbrica bajo el control del atacante). [265] Todas las versiones de TLS y SSL corren el riesgo de INCUMPLIMIENTO, independientemente del algoritmo de cifrado o cifrado utilizado. [266] A diferencia de instancias anteriores de CRIME, de las que se puede defender con éxito desactivando la compresión TLS o la compresión de encabezado SPDY, BREACH aprovecha la compresión HTTP que no se puede desactivar de manera realista, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para usuarios. [265] Esta es una limitación conocida de TLS, ya que es susceptible al ataque de texto sin formato elegido contra los datos de la capa de aplicación que estaba destinado a proteger.
Ataques de sincronización en el acolchado
Las versiones anteriores de TLS eran vulnerables al ataque de oráculo de relleno descubierto en 2002. En 2013 se publicó una nueva variante, llamada ataque Lucky Thirteen .
Algunos expertos [64] también recomendaron evitar el CBC Triple-DES . Desde los últimos cifrados soportados desarrollados para apoyar programa de cualquier uso de Windows XP SSL 's / biblioteca TLS como Internet Explorer en Windows XP son RC4 y Triple-DES, y desde RC4 ahora es obsoleto (véase la discusión de los ataques RC4 ), esto hace que sea difícil para admitir cualquier versión de SSL para cualquier programa que utilice esta biblioteca en XP.
Se lanzó una corrección como la extensión Encrypt-then-MAC para la especificación TLS, lanzada como RFC 7366 . [267] El ataque Lucky Thirteen se puede mitigar en TLS 1.2 utilizando únicamente cifrados AES_GCM; AES_CBC sigue siendo vulnerable. [ cita requerida ]
Ataque CANICHE
El 14 de octubre de 2014, los investigadores de Google publicaron una vulnerabilidad en el diseño de SSL 3.0, que hace que el modo de operación CBC con SSL 3.0 sea vulnerable a un ataque de relleno ( CVE - 2014-3566 ). Llamaron a este ataque POODLE ( Padding Oracle On Downgraded Legacy Encryption ). En promedio, los atacantes solo necesitan realizar 256 solicitudes SSL 3.0 para revelar un byte de mensajes cifrados. [71]
Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayoría de los clientes y servidores admiten TLS 1.0 y superior, todos los navegadores principales cambian voluntariamente a SSL 3.0 si fallan los apretones de manos con versiones más recientes de TLS, a menos que brinden la opción para que un usuario o administrador deshabilite SSL 3.0 y el usuario o administrador lo hace [ cita requerida ] . Por lo tanto, el intermediario puede primero realizar un ataque de reversión de la versión y luego explotar esta vulnerabilidad. [71]
El 8 de diciembre de 2014, se anunció una variante de POODLE que afecta las implementaciones de TLS que no hacen cumplir correctamente los requisitos de bytes de relleno. [268]
Ataques RC4
A pesar de la existencia de ataques a RC4 que rompieron su seguridad, los conjuntos de cifrado en SSL y TLS que se basaban en RC4 todavía se consideraban seguros antes de 2013 según la forma en que se usaban en SSL y TLS. En 2011, la suite RC4 se recomendó como una solución para el ataque BEAST . [269] Las nuevas formas de ataque reveladas en marzo de 2013 demostraron de manera concluyente la viabilidad de romper RC4 en TLS, lo que sugiere que no era una buena solución para BEAST. [70] AlFardan, Bernstein, Paterson, Poettering y Schuldt propusieron un escenario de ataque que utilizó sesgos estadísticos recién descubiertos en la tabla de claves RC4 [270] para recuperar partes del texto plano con un gran número de cifrados TLS. [271] [272] El 8 de julio de 2013 se dio a conocer un ataque a RC4 en TLS y SSL que requiere encriptaciones 13 × 2 20 para romper RC4 y luego se describió como "factible" en la presentación adjunta en un Simposio de Seguridad de USENIX en agosto de 2013. [273] [274] En julio de 2015, las mejoras posteriores en el ataque hacen que sea cada vez más práctico derrotar la seguridad de TLS cifrado con RC4. [275]
Como muchos navegadores modernos han sido diseñados para vencer los ataques BEAST (excepto Safari para Mac OS X 10.7 o anterior, para iOS 6 o anterior, y para Windows; consulte § Navegadores web ), RC4 ya no es una buena opción para TLS 1.0. Los cifrados CBC que fueron afectados por el ataque BEAST en el pasado se han convertido en una opción de protección más popular. [64] Mozilla y Microsoft recomiendan deshabilitar RC4 siempre que sea posible. [276] [277]RFC 7465 prohíbe el uso de conjuntos de cifrado RC4 en todas las versiones de TLS.
El 1 de septiembre de 2015, Microsoft, Google y Mozilla anunciaron que los conjuntos de cifrado RC4 se desactivarían de forma predeterminada en sus navegadores ( Microsoft Edge , Internet Explorer 11 en Windows 7 / 8.1 / 10, Firefox y Chrome ) a principios de 2016. [278 ] [279] [280]
Ataque de truncamiento
Un ataque de truncamiento de TLS (cierre de sesión) bloquea las solicitudes de cierre de sesión de la cuenta de la víctima para que el usuario, sin saberlo, permanezca conectado a un servicio web. Cuando se envía la solicitud para cerrar sesión, el atacante inyecta un mensaje TCP FIN sin cifrar (no hay más datos del remitente) para cerrar la conexión. Por lo tanto, el servidor no recibe la solicitud de cierre de sesión y desconoce la terminación anormal. [281]
Publicado en julio de 2013, [282] [283] el ataque hace que servicios web como Gmail y Hotmail muestren una página que informa al usuario que ha cerrado la sesión correctamente, al tiempo que garantiza que el navegador del usuario mantiene la autorización con el servicio, lo que permite un atacante con acceso posterior al navegador para acceder y tomar el control de la cuenta de inicio de sesión del usuario. El ataque no se basa en la instalación de malware en la computadora de la víctima; los atacantes solo necesitan ubicarse entre la víctima y el servidor web (por ejemplo, configurando un punto de acceso inalámbrico no autorizado). [281] Esta vulnerabilidad también requiere acceso a la computadora de la víctima. Otra posibilidad es que cuando se usa FTP, la conexión de datos puede tener un FIN falso en el flujo de datos, y si las reglas del protocolo para el intercambio de alertas close_notify no se adhieren a un archivo, se pueden truncar.
Ataque PAC profano
Este ataque, descubierto a mediados de 2016, aprovecha las debilidades del Protocolo de detección automática de proxy web (WPAD) para exponer la URL a la que un usuario web intenta acceder a través de un enlace web habilitado para TLS. [284] La divulgación de una URL puede violar la privacidad de un usuario, no solo por el sitio web al que se accede, sino también porque las URL se utilizan a veces para autenticar a los usuarios. Los servicios para compartir documentos, como los que ofrecen Google y Dropbox, también funcionan enviando al usuario un token de seguridad que se incluye en la URL. Un atacante que obtenga dichas URL puede obtener acceso completo a la cuenta o los datos de la víctima.
El exploit funciona contra casi todos los navegadores y sistemas operativos.
Ataque Sweet32
El ataque Sweet32 rompe todos los cifrados de bloque de 64 bits utilizados en el modo CBC como se utiliza en TLS al explotar un ataque de cumpleaños y un ataque man-in-the-middle o la inyección de un JavaScript malicioso en una página web. El propósito del ataque man-in-the-middle o la inyección de JavaScript es permitir que el atacante capture suficiente tráfico para montar un ataque de cumpleaños. [285]
Errores de implementación: Error de sangrado del corazón, Ataque BERserk, error de Cloudflare
El error Heartbleed es una vulnerabilidad grave específica de la implementación de SSL / TLS en la popular biblioteca de software criptográfico OpenSSL , que afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad, informada en abril de 2014, permite a los atacantes robar claves privadas de servidores que normalmente deberían estar protegidos. [286] El error Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves privadas secretas asociadas con los certificados públicos utilizados para identificar a los proveedores de servicios y para cifrar el tráfico, los nombres y contraseñas de los usuarios y el contenido real. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y usuarios y hacerse pasar por servicios y usuarios. [287] La vulnerabilidad es causada por un error de sobre-lectura del búfer en el software OpenSSL, en lugar de un defecto en la especificación del protocolo SSL o TLS.
En septiembre de 2014, Intel Security Advanced Threat Research anunció una variante de la vulnerabilidad PKCS # 1 v1.5 RSA Signature Forgery de Daniel Bleichenbacher [288] . Este ataque, denominado BERserk, es el resultado de una decodificación de la longitud ASN.1 incompleta de las firmas de clave pública en algunas implementaciones de SSL, y permite un ataque de intermediario mediante la falsificación de una firma de clave pública. [289]
En febrero de 2015, después de que los medios informaran sobre la preinstalación oculta del adware Superfish en algunos portátiles Lenovo, [290] un investigador descubrió que un certificado raíz de confianza en las máquinas Lenovo afectadas era inseguro, ya que se podía acceder fácilmente a las claves utilizando el nombre de la empresa. Komodia, como frase de contraseña. [291] La biblioteca Komodia fue diseñada para interceptar el tráfico TLS / SSL del lado del cliente para control y vigilancia parental, pero también se usó en numerosos programas publicitarios, incluido Superfish, que a menudo se instalaban subrepticiamente sin que el usuario de la computadora lo supiera. A su vez, estos programas potencialmente no deseados instalaron el certificado raíz corrupto, lo que permitió a los atacantes controlar completamente el tráfico web y confirmar que los sitios web falsos son auténticos.
En mayo de 2016, se informó que docenas de sitios web daneses protegidos por HTTPS pertenecientes a Visa Inc. eran vulnerables a ataques que permitían a los piratas informáticos inyectar código malicioso y contenido falsificado en los navegadores de los visitantes. [292] Los ataques funcionaron porque la implementación de TLS utilizada en los servidores afectados reutilizó incorrectamente números aleatorios ( nonces ) que estaban destinados a usarse solo una vez, lo que garantiza que cada protocolo de enlace de TLS sea único. [292]
En febrero de 2017, un error de implementación causado por un solo carácter mal escrito en el código utilizado para analizar HTML creó un error de desbordamiento de búfer en los servidores de Cloudflare . Similar en sus efectos al error Heartbleed descubierto en 2014, este error de desbordamiento, ampliamente conocido como Cloudbleed , permitió a terceros no autorizados leer datos en la memoria de programas que se ejecutan en los servidores, datos que de otra manera deberían haber sido protegidos por TLS. [293]
Encuesta de sitios web vulnerables a ataques
A julio de 2021[actualizar], el Trustworthy Internet Movement estimó la proporción de sitios web que son vulnerables a los ataques TLS. [69]
Ataques | Seguridad | |||
---|---|---|---|---|
Inseguro | Depende | Seguro | Otro | |
Ataque de renegociación | 0.1% apoya la renegociación insegura | <0,1% admite ambos | El 99,2% apoya la renegociación segura | 0,7% sin apoyo |
Ataques RC4 | 0.4% de compatibilidad con suites RC4 utilizadas con navegadores modernos | 6.5% admite algunas suites RC4 | 93,1% sin apoyo | N / A |
Compresión TLS (ataque CRIME) | > 0.0% vulnerable | N / A | N / A | N / A |
Heartbleed | > 0.0% vulnerable | N / A | N / A | N / A |
Ataque de inyección ChangeCipherSpec | 0,1% vulnerable y explotable | 0,2% vulnerable, no explotable | 98,5% no vulnerable | 1,2% desconocido |
Ataque POODLE contra TLS (no se incluye POODLE original contra SSL 3.0) | 0,1% vulnerable y explotable | 0,1% vulnerable, no explotable | 99,8% no vulnerable | 0,2% desconocido |
Protocolo de degradación | 6.6% Defensa de degradación no compatible | N / A | 72.3% Defensa de degradación apoyada | 21,0% desconocido |
Reenviar el secreto
El secreto hacia adelante es una propiedad de los sistemas criptográficos que asegura que una clave de sesión derivada de un conjunto de claves públicas y privadas no se verá comprometida si una de las claves privadas se ve comprometida en el futuro. [294] Sin el secreto de reenvío, si la clave privada del servidor se ve comprometida, no solo se verán comprometidas todas las futuras sesiones encriptadas con TLS que usen ese certificado de servidor, sino también cualquier sesión anterior que lo haya usado (siempre y cuando estas sesiones pasadas fueran interceptados y almacenados en el momento de la transmisión). [295] Una implementación de TLS puede proporcionar secreto hacia adelante al requerir el uso de intercambio de claves Diffie-Hellman efímero para establecer claves de sesión, y algunas implementaciones notables de TLS lo hacen exclusivamente: por ejemplo, Gmail y otros servicios HTTPS de Google que usan OpenSSL . [296] Sin embargo, muchos clientes y servidores que admiten TLS (incluidos navegadores y servidores web) no están configurados para implementar tales restricciones. [297] [298] En la práctica, a menos que un servicio web utilice el intercambio de claves Diffie-Hellman para implementar el secreto hacia adelante, todo el tráfico web cifrado hacia y desde ese servicio puede ser descifrado por un tercero si obtiene el servidor maestro (privado ) clave; por ejemplo, mediante una orden judicial. [299]
Incluso donde se implementa el intercambio de claves Diffie-Hellman, los mecanismos de administración de sesiones del lado del servidor pueden afectar el secreto hacia adelante. El uso de tickets de sesión TLS (una extensión TLS) hace que la sesión esté protegida por AES128-CBC-SHA256 independientemente de cualquier otro parámetro TLS negociado, incluidos los conjuntos de cifrado de confidencialidad directa, y las claves de ticket de sesión TLS de larga duración anulan el intento de implementación secreto hacia adelante. [300] [301] [302] La investigación de la Universidad de Stanford en 2014 también encontró que de 473,802 servidores TLS encuestados, el 82.9% de los servidores que implementaban intercambio de claves Diffie-Hellman (DHE) efímero para respaldar el secreto hacia adelante usaban parámetros Diffie-Hellman débiles. Estas opciones de parámetros débiles podrían potencialmente comprometer la efectividad del secreto hacia adelante que los servidores buscaban proporcionar. [303]
Desde finales de 2011, Google ha proporcionado confidencialidad hacia adelante con TLS de forma predeterminada a los usuarios de su servicio de Gmail , junto con Google Docs y búsqueda encriptada, entre otros servicios. [304] Desde noviembre de 2013, Twitter ha proporcionado confidencialidad hacia adelante con TLS a los usuarios de su servicio. [305] A agosto de 2019[actualizar], aproximadamente el 80% de los sitios web habilitados para TLS están configurados para usar conjuntos de cifrado que brindan secreto directo a la mayoría de los navegadores web. [69]
Intercepción de TLS
La interceptación de TLS (o intercepción de HTTPS si se aplica particularmente a ese protocolo) es la práctica de interceptar un flujo de datos cifrados para descifrarlo, leerlo y posiblemente manipularlo, y luego volver a cifrarlo y enviar los datos en su camino nuevamente. Esto se hace mediante un " proxy transparente ": el software de intercepción finaliza la conexión TLS entrante, inspecciona el texto sin formato HTTP y luego crea una nueva conexión TLS al destino. [306]
La interceptación de TLS / HTTPS se utiliza como medida de seguridad de la información por parte de los operadores de red para poder escanear y proteger contra la intrusión de contenido malicioso en la red, como virus informáticos y otro malware . [306] De lo contrario, dicho contenido no podría detectarse siempre que esté protegido mediante encriptación, lo que es cada vez más frecuente como resultado del uso rutinario de HTTPS y otros protocolos seguros.
Un inconveniente importante de la interceptación TLS / HTTPS es que presenta nuevos riesgos de seguridad propios. Debido a que proporciona un punto donde el tráfico de red está disponible sin cifrar, los atacantes tienen un incentivo para atacar este punto en particular para obtener acceso a contenido que de otro modo sería seguro. La interceptación también permite al operador de red, o las personas que obtienen acceso a su sistema de interceptación, realizar ataques de intermediario contra los usuarios de la red. Un estudio de 2017 encontró que "la interceptación HTTPS se ha generalizado sorprendentemente y que los productos de interceptación como clase tienen un impacto dramáticamente negativo en la seguridad de la conexión". [306]
Detalles del protocolo
El protocolo TLS intercambia registros , que encapsulan los datos que se intercambiarán en un formato específico (ver más abajo). Cada registro se puede comprimir, rellenar, adjuntar un código de autenticación de mensaje (MAC) o cifrar, todo según el estado de la conexión. Cada registro tiene un campo de tipo de contenido que designa el tipo de datos encapsulados, un campo de longitud y un campo de versión TLS. Los datos encapsulados pueden ser mensajes de control o de procedimiento del propio TLS, o simplemente los datos de la aplicación necesarios para ser transferidos por TLS. Las especificaciones (conjunto de cifrado, claves, etc.) necesarias para intercambiar datos de aplicaciones mediante TLS se acuerdan en el "protocolo de enlace TLS" entre el cliente que solicita los datos y el servidor que responde a las solicitudes. Por lo tanto, el protocolo define tanto la estructura de las cargas útiles transferidas en TLS como el procedimiento para establecer y monitorear la transferencia.
Apretón de manos TLS
Cuando se inicia la conexión, el registro encapsula un protocolo de "control": el protocolo de mensajería de protocolo de enlace ( tipo de contenido 22). Este protocolo se utiliza para intercambiar toda la información requerida por ambas partes para el intercambio de los datos reales de la aplicación por TLS. Define el formato de los mensajes y el orden de su intercambio. Estos pueden variar según las demandas del cliente y el servidor, es decir, existen varios procedimientos posibles para configurar la conexión. Este intercambio inicial da como resultado una conexión TLS exitosa (ambas partes están listas para transferir datos de la aplicación con TLS) o un mensaje de alerta (como se especifica a continuación).
Apretón de manos TLS básico
A continuación, se muestra un ejemplo de conexión típico, que ilustra un protocolo de enlace en el que el servidor (pero no el cliente) está autenticado por su certificado:
- Fase de negociación:
- Un cliente envía un mensaje ClientHello especificando la versión de protocolo TLS más alta que admite, un número aleatorio, una lista de conjuntos de cifrado sugeridos y métodos de compresión sugeridos. Si el cliente está intentando realizar un protocolo de enlace reanudado, puede enviar un ID de sesión . Si el cliente puede utilizar la negociación de protocolo de capa de aplicación , puede incluir una lista de protocolos de aplicación compatibles , como HTTP / 2 .
- El servidor responde con un mensaje ServerHello , que contiene la versión de protocolo elegida, un número aleatorio, un conjunto de cifrado y un método de compresión de las opciones ofrecidas por el cliente. Para confirmar o permitir la reanudación de los apretones de manos, el servidor puede enviar un ID de sesión . La versión de protocolo elegida debe ser la más alta que admitan tanto el cliente como el servidor. Por ejemplo, si el cliente admite la versión 1.1 de TLS y el servidor admite la versión 1.2, se debe seleccionar la versión 1.1; la versión 1.2 no debe seleccionarse.
- El servidor envía su mensaje de Certificado (dependiendo del conjunto de cifrado seleccionado, esto puede ser omitido por el servidor). [307]
- El servidor envía su mensaje ServerKeyExchange (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitirlo ). Este mensaje se envía para todos los conjuntos de cifrado DHE , ECDHE y DH_anon. [7]
- El servidor envía un mensaje ServerHelloDone , indicando que se realizó con la negociación del protocolo de enlace.
- El cliente responde con un mensaje ClientKeyExchange , que puede contener un PreMasterSecret , una clave pública o nada. (De nuevo, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
- El cliente y el servidor luego usan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave ( claves de sesión tales como IV , el cifrado simétrico clave, MAC clave [308] ) para esta conexión se deriva de este secreto principal (y el cliente-servidor y-genera valores aleatorios), que se pasa a través de un cuidado diseño función pseudoaleatoria .
- El cliente ahora envía un registro ChangeCipherSpec , esencialmente diciéndole al servidor: "Todo lo que le diga a partir de ahora será autenticado (y cifrado si los parámetros de cifrado estaban presentes en el certificado del servidor)". ChangeCipherSpec es en sí mismo un protocolo de nivel de registro con el tipo de contenido 20.
- El cliente envía un mensaje Finalizado autenticado y cifrado , que contiene un hash y una MAC sobre los mensajes de protocolo de enlace anteriores.
- El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y la conexión debe cortarse.
- Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente, "Todo lo que le diga a partir de ahora será autenticado (y cifrado, si se negoció el cifrado)".
- El servidor envía su mensaje Finalizado autenticado y cifrado .
- El cliente realiza el mismo procedimiento de descifrado y verificación que hizo el servidor en el paso anterior.
- Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de aplicación está habilitado, con el tipo de contenido 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también serán autenticados y opcionalmente encriptados exactamente como en su mensaje Finalizado . De lo contrario, el tipo de contenido devolverá 25 y el cliente no se autenticará.
Apretón de manos TLS autenticado por el cliente
El siguiente ejemplo completo muestra la autenticación de un cliente (además del servidor como en el ejemplo anterior; consulte la autenticación mutua ) a través de TLS utilizando certificados intercambiados entre ambos pares.
- Fase de negociación:
- Un cliente envía un mensaje ClientHello especificando la versión de protocolo TLS más alta que admite, un número aleatorio, una lista de conjuntos de cifrado sugeridos y métodos de compresión.
- El servidor responde con un mensaje ServerHello , que contiene la versión de protocolo elegida, un número aleatorio, un conjunto de cifrado y un método de compresión de las opciones ofrecidas por el cliente. El servidor también puede enviar una identificación de sesión como parte del mensaje para realizar un apretón de manos reanudado.
- El servidor envía su mensaje de Certificado (dependiendo del conjunto de cifrado seleccionado, esto puede ser omitido por el servidor). [307]
- El servidor envía su mensaje ServerKeyExchange (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitirlo ). Este mensaje se envía para todos los conjuntos de cifrado DHE, ECDHE y DH_anon. [7]
- El servidor envía un mensaje CertificateRequest para solicitar un certificado al cliente.
- El servidor envía un mensaje ServerHelloDone , indicando que se realizó con la negociación del protocolo de enlace.
- El cliente responde con un mensaje de certificado , que contiene el certificado del cliente.
- El cliente envía un mensaje ClientKeyExchange , que puede contener un PreMasterSecret , una clave pública o nada. (De nuevo, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
- El cliente envía un mensaje CertificateVerify , que es una firma sobre los mensajes de protocolo de enlace anteriores utilizando la clave privada del certificado del cliente. Esta firma se puede verificar utilizando la clave pública del certificado del cliente. Esto le permite al servidor saber que el cliente tiene acceso a la clave privada del certificado y, por lo tanto, es el propietario del certificado.
- El cliente y el servidor luego usan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave ("claves de sesión") para esta conexión se derivan de este secreto maestro (y los valores aleatorios generados por el cliente y el servidor), que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada.
- El cliente ahora envía un registro ChangeCipherSpec , esencialmente diciéndole al servidor: "Todo lo que le diga a partir de ahora será autenticado (y cifrado si se negoció el cifrado)". ChangeCipherSpec es en sí mismo un protocolo de nivel de registro y tiene tipo 20 y no 22 .
- Por último, el cliente envía un mensaje Finalizado cifrado , que contiene un hash y una MAC sobre los mensajes de protocolo de enlace anteriores.
- El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y la conexión debe cortarse.
- Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente, "Todo lo que le diga a partir de ahora será autenticado (y cifrado si se negoció el cifrado)".
- El servidor envía su propio mensaje Finalizado cifrado .
- El cliente realiza el mismo procedimiento de descifrado y verificación que hizo el servidor en el paso anterior.
- Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de aplicación está habilitado, con el tipo de contenido 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también se cifrarán exactamente como en su mensaje Finalizado .
Apretón de manos TLS reanudado
Las operaciones de clave pública (por ejemplo, RSA) son relativamente caras en términos de potencia computacional. TLS proporciona un acceso directo seguro en el mecanismo de protocolo de enlace para evitar estas operaciones: sesiones reanudadas. Las sesiones reanudadas se implementan utilizando ID de sesión o tickets de sesión.
Además del beneficio de rendimiento, las sesiones reanudadas también se pueden utilizar para el inicio de sesión único , ya que garantiza que tanto la sesión original como cualquier sesión reanudada se originen en el mismo cliente. Esto es de particular importancia para el protocolo FTP sobre TLS / SSL , que de otro modo sufriría un ataque man-in-the-middle en el que un atacante podría interceptar el contenido de las conexiones de datos secundarias. [309]
Apretón de manos TLS 1.3
El protocolo de enlace TLS 1.3 se condensó en un solo viaje de ida y vuelta en comparación con los dos viajes de ida y vuelta requeridos en versiones anteriores de TLS / SSL.
Primero, el cliente envía un mensaje clientHello al servidor que contiene una lista de cifrados admitidos en orden de preferencia del cliente y adivina qué algoritmo de clave se utilizará para que pueda enviar una clave secreta para compartir si es necesario. Al adivinar qué algoritmo clave se utilizará, el servidor elimina un viaje de ida y vuelta. Después de recibir el clientHello, el servidor envía un serverHello con su clave, un certificado, el paquete de cifrado elegido y el mensaje terminado.
Una vez que el cliente recibe el mensaje finalizado del servidor, ahora se coordina con el servidor en el que se utilizará la suite de cifrado. [310]
ID de sesión
En un apretón de manos completo normal , el servidor envía una identificación de sesión como parte del mensaje ServerHello . El cliente asocia esta identificación de sesión con la dirección IP del servidor y el puerto TCP, de modo que cuando el cliente se conecte nuevamente a ese servidor, pueda usar la identificación de sesión para atajar el protocolo de enlace. En el servidor, la identificación de la sesión se asigna a los parámetros criptográficos negociados previamente, específicamente el "secreto maestro". Ambas partes deben tener el mismo "secreto maestro" o el apretón de manos reanudado fallará (esto evita que un fisgón use una identificación de sesión ). Los datos aleatorios en los mensajes ClientHello y ServerHello garantizan virtualmente que las claves de conexión generadas serán diferentes a las de la conexión anterior. En las RFC, este tipo de apretón de manos se denomina apretón de manos abreviado . También se describe en la literatura como un apretón de manos de reinicio .
- Fase de negociación:
- Un cliente envía un mensaje ClientHello especificando la versión de protocolo TLS más alta que admite, un número aleatorio, una lista de conjuntos de cifrado sugeridos y métodos de compresión. En el mensaje se incluye el ID de sesión de la conexión TLS anterior.
- El servidor responde con un mensaje ServerHello , que contiene la versión de protocolo elegida, un número aleatorio, un conjunto de cifrado y un método de compresión de las opciones ofrecidas por el cliente. Si el servidor reconoce la identificación de sesión enviada por el cliente, responde con la misma identificación de sesión . El cliente utiliza esto para reconocer que se está realizando un apretón de manos reanudado. Si el servidor no reconoce la identificación de sesión enviada por el cliente, envía un valor diferente para su identificación de sesión . Esto le dice al cliente que no se realizará un apretón de manos reanudado. En este punto, tanto el cliente como el servidor tienen el "secreto maestro" y los datos aleatorios para generar los datos clave que se utilizarán para esta conexión.
- El servidor ahora envía un registro ChangeCipherSpec , esencialmente diciéndole al cliente, "Todo lo que le diga a partir de ahora será encriptado". ChangeCipherSpec es en sí mismo un protocolo de nivel de registro y tiene el tipo 20 y no el 22.
- Finalmente, el servidor envía un mensaje Finalizado cifrado , que contiene un hash y una MAC sobre los mensajes de protocolo de enlace anteriores.
- El cliente intentará descifrar el mensaje Finalizado del servidor y verificar el hash y la MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y la conexión debe cortarse.
- Finalmente, el cliente envía un ChangeCipherSpec , diciéndole al servidor, "Todo lo que te diga de ahora en adelante será encriptado".
- El cliente envía su propio mensaje Finalizado cifrado .
- El servidor realiza el mismo procedimiento de descifrado y verificación que hizo el cliente en el paso anterior.
- Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de aplicación está habilitado, con el tipo de contenido 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también se cifrarán exactamente como en su mensaje Finalizado .
Tickets de sesión
RFC 5077 extiende TLS mediante el uso de tickets de sesión, en lugar de ID de sesión. Define una forma de reanudar una sesión TLS sin requerir que el estado específico de la sesión se almacene en el servidor TLS.
Cuando se utilizan tickets de sesión, el servidor TLS almacena su estado específico de sesión en un ticket de sesión y envía el ticket de sesión al cliente TLS para su almacenamiento. El cliente reanuda una sesión TLS enviando el ticket de sesión al servidor y el servidor reanuda la sesión TLS de acuerdo con el estado específico de la sesión en el ticket. El vale de sesión es encriptado y autenticado por el servidor, y el servidor verifica su validez antes de usar su contenido.
Una debilidad particular de este método con OpenSSL es que siempre limita la seguridad de cifrado y autenticación del ticket de sesión TLS transmitido a AES128-CBC-SHA256
, sin importar qué otros parámetros TLS se negociaron para la sesión TLS real. [301] Esto significa que la información de estado (el ticket de la sesión TLS) no está tan bien protegida como la propia sesión TLS. De particular preocupación es el almacenamiento de OpenSSL de las claves en un contexto de toda la aplicación ( SSL_CTX
), es decir, durante la vida de la aplicación, y no permite volver a introducir las claves de los AES128-CBC-SHA256
tickets de sesión TLS sin restablecer el contexto OpenSSL de toda la aplicación (lo cual es poco común , propenso a errores y a menudo requiere intervención administrativa manual). [302] [300]
Registro TLS
Este es el formato general de todos los registros TLS.
Compensar | Byte +0 | Byte +1 | Byte +2 | Byte +3 |
---|---|---|---|---|
Byte 0 | Tipo de contenido | N / A | ||
Bytes 1..4 | Versión heredada | Largo | ||
(Importante) | (Menor) | (bits 15..8) | (bits 7..0) | |
Bytes 5 .. ( m −1) | Mensaje (s) de protocolo | |||
Bytes m .. ( p −1) | MAC (opcional) | |||
Bytes p .. ( q −1) | Relleno (solo cifrados de bloque) |
- Tipo de contenido
- Este campo identifica el tipo de protocolo de capa de registro contenido en este registro.
Maleficio | dic | Tipo |
---|---|---|
0x14 | 20 | ChangeCipherSpec |
0x15 | 21 | Alerta |
0x16 | 22 | Apretón de manos |
0x17 | 23 | Solicitud |
0x18 | 24 | Latido del corazón |
- Versión heredada
- Este campo identifica la versión principal y secundaria de TLS anterior a TLS 1.3 para el mensaje contenido. Para un mensaje ClientHello, no es necesario que esta sea la versión más alta admitida por el cliente. Para TLS 1.3 y posterior, esto debe establecerse en 0x0303 y la aplicación debe enviar versiones compatibles en un bloque de extensión de mensaje adicional.
Versión principal | Versión menor | Tipo de versión |
---|---|---|
3 | 0 | SSL 3.0 |
3 | 1 | TLS 1.0 |
3 | 2 | TLS 1.1 |
3 | 3 | TLS 1.2 |
3 | 4 | TLS 1.3 |
- Largo
- La longitud de los campos "mensaje (s) de protocolo", "MAC" y "relleno" combinados (es decir, q −5), no debe exceder 2 14 bytes (16 KiB).
- Mensaje (s) de protocolo
- Uno o más mensajes identificados por el campo Protocolo. Tenga en cuenta que este campo puede estar cifrado según el estado de la conexión.
- MAC y acolchado
- Un código de autenticación de mensaje calculado sobre el campo "mensaje (s) de protocolo", con material clave adicional incluido. Tenga en cuenta que este campo puede estar cifrado o no incluido por completo, según el estado de la conexión.
- No puede haber campos "MAC" o "padding" al final de los registros TLS antes de que todos los algoritmos y parámetros de cifrado se hayan negociado y firmado y luego se hayan confirmado mediante el envío de un registro CipherStateChange (ver más abajo) para indicar que estos parámetros tendrán efecto en todos más registros enviados por el mismo par.
Protocolo de apretón de manos
La mayoría de los mensajes intercambiados durante la configuración de la sesión TLS se basan en este registro, a menos que ocurra un error o advertencia y deba ser señalado por un registro de protocolo de alerta (ver más abajo), o el modo de cifrado de la sesión sea modificado por otro registro ( consulte el protocolo ChangeCipherSpec a continuación).
Compensar | Byte +0 | Byte +1 | Byte +2 | Byte +3 |
---|---|---|---|---|
Byte 0 | 22 | N / A | ||
Bytes 1..4 | Versión heredada | Largo | ||
(Importante) | (Menor) | (bits 15..8) | (bits 7..0) | |
Bytes 5..8 | Tipo de mensaje | Longitud de los datos del mensaje de protocolo de enlace | ||
(bits 23..16) | (bits 15..8) | (bits 7..0) | ||
Bytes 9 .. ( n −1) | Datos del mensaje de protocolo de enlace | |||
Bytes n .. ( n +3) | Tipo de mensaje | Longitud de los datos del mensaje de protocolo de enlace | ||
(bits 23..16) | (bits 15..8) | (bits 7..0) | ||
Bytes ( n +4) ... | Datos del mensaje de protocolo de enlace |
- Tipo de mensaje
- Este campo identifica el tipo de mensaje de reconocimiento.
Código | Descripción |
---|---|
0 | HelloRequest |
1 | ClienteHola |
2 | ServidorHola |
4 | NewSessionTicket |
8 | Extensiones cifradas (solo TLS 1.3) |
11 | Certificado |
12 | ServerKeyExchange |
13 | Solicitud de certificado |
14 | ServidorHolaDone |
15 | CertificadoVerificar |
dieciséis | ClientKeyExchange |
20 | Terminado |
- Longitud de los datos del mensaje de protocolo de enlace
- Este es un campo de 3 bytes que indica la longitud de los datos del protocolo de enlace, sin incluir el encabezado.
Tenga en cuenta que se pueden combinar varios mensajes de protocolo de enlace en un registro.
Protocolo de alerta
Normalmente, este registro no debe enviarse durante el intercambio de aplicaciones o el protocolo de enlace normal. Sin embargo, este mensaje se puede enviar en cualquier momento durante el apretón de manos y hasta el cierre de la sesión. Si esto se usa para señalar un error fatal, la sesión se cerrará inmediatamente después de enviar este registro, por lo que este registro se usa para dar una razón para este cierre. Si el nivel de alerta se marca como una advertencia, el control remoto puede decidir cerrar la sesión si decide que la sesión no es lo suficientemente confiable para sus necesidades (antes de hacerlo, el control remoto también puede enviar su propia señal).
Compensar | Byte +0 | Byte +1 | Byte +2 | Byte +3 |
---|---|---|---|---|
Byte 0 | 21 | N / A | ||
Bytes 1..4 | Versión heredada | Largo | ||
(Importante) | (Menor) | 0 | 2 | |
Bytes 5..6 | Nivel | Descripción | N / A | |
Bytes 7 .. ( p −1) | MAC (opcional) | |||
Bytes p .. ( q −1) | Relleno (solo cifrados de bloque) |
- Nivel
- Este campo identifica el nivel de alerta. Si el nivel es fatal, el remitente debe cerrar la sesión inmediatamente. De lo contrario, el destinatario puede decidir terminar la sesión él mismo, enviando su propia alerta fatal y cerrando la sesión inmediatamente después de enviarla. El uso de registros de alerta es opcional, sin embargo, si falta antes del cierre de la sesión, la sesión puede reanudarse automáticamente (con sus apretones de manos).
- El cierre normal de una sesión después de la terminación de la aplicación transportada debe ser alertado preferiblemente con al menos el tipo de Alerta de notificación de cierre (con un nivel de advertencia simple) para evitar la reanudación automática de una nueva sesión. Señalar explícitamente el cierre normal de una sesión segura antes de cerrar efectivamente su capa de transporte es útil para prevenir o detectar ataques (como intentos de truncar los datos transportados de forma segura, si intrínsecamente no tiene una longitud o duración predeterminada que el destinatario de los datos protegidos puede esperar).
Código | Tipo de nivel | Estado de conexión |
---|---|---|
1 | advertencia | la conexión o la seguridad pueden ser inestables. |
2 | fatal | la conexión o la seguridad pueden verse comprometidas, o se ha producido un error irrecuperable. |
- Descripción
- Este campo identifica qué tipo de alerta se envía.
Código | Descripción | Tipos de nivel | Nota |
---|---|---|---|
0 | Cerrar notificar | advertencia / fatal | |
10 | Mensaje inesperado | fatal | |
20 | MAC de registro incorrecto | fatal | Posiblemente una mala implementación de SSL, o la carga útil ha sido alterada, por ejemplo, la regla de firewall FTP en el servidor FTPS. |
21 | Falló el descifrado | fatal | TLS solamente, reservado |
22 | Desbordamiento de registros | fatal | TLS solamente |
30 | Fallo de descompresión | fatal | |
40 | Fallo en el apretón de manos | fatal | |
41 | Sin certificado | advertencia / fatal | Solo SSL 3.0, reservado |
42 | Certificado incorrecto | advertencia / fatal | |
43 | Certificado no admitido | advertencia / fatal | por ejemplo, el certificado solo tiene habilitado el uso de autenticación del servidor y se presenta como un certificado de cliente |
44 | Certificado revocado | advertencia / fatal | |
45 | Certificado caducado | advertencia / fatal | Verifique que el certificado del servidor expire también verifique que ningún certificado en la cadena presentada haya expirado |
46 | Certificado desconocido | advertencia / fatal | |
47 | Parámetro ilegal | fatal | |
48 | CA desconocida ( autoridad certificadora ) | fatal | TLS solamente |
49 | Acceso denegado | fatal | Solo TLS: por ejemplo, no se ha presentado ningún certificado de cliente (TLS: mensaje de certificado en blanco o SSLv3: alerta de no certificado), pero el servidor está configurado para requerir uno. |
50 | Error de decodificación | fatal | TLS solamente |
51 | Descifrar error | advertencia / fatal | TLS solamente |
60 | Restricción de exportación | fatal | TLS solamente, reservado |
70 | Versión del protocolo | fatal | TLS solamente |
71 | Seguridad insuficiente | fatal | TLS solamente |
80 | Error interno | fatal | TLS solamente |
86 | Respaldo inapropiado | fatal | TLS solamente |
90 | Usuario cancelado | fatal | TLS solamente |
100 | Sin renegociación | advertencia | TLS solamente |
110 | Extensión no admitida | advertencia | TLS solamente |
111 | Certificado inalcanzable | advertencia | TLS solamente |
112 | Nombre no reconocido | advertencia / fatal | TLS solamente; El indicador de nombre del servidor del cliente especificó un nombre de host no admitido por el servidor |
113 | Respuesta de estado de certificado incorrecto | fatal | TLS solamente |
114 | Valor hash de certificado incorrecto | fatal | TLS solamente |
115 | Identidad PSK desconocida (utilizada en TLS-PSK y TLS-SRP ) | fatal | TLS solamente |
Protocolo ChangeCipherSpec
Compensar | Byte +0 | Byte +1 | Byte +2 | Byte +3 |
---|---|---|---|---|
Byte 0 | 20 | N / A | ||
Bytes 1..4 | Versión heredada | Largo | ||
(Importante) | (Menor) | 0 | 1 | |
Byte 5 | Tipo de protocolo CCS | N / A |
- Tipo de protocolo CCS
- Actualmente solo 1.
Protocolo de aplicación
Compensar | Byte +0 | Byte +1 | Byte +2 | Byte +3 |
---|---|---|---|---|
Byte 0 | 23 | N / A | ||
Bytes 1..4 | Versión heredada | Largo | ||
(Importante) | (Menor) | (bits 15..8) | (bits 7..0) | |
Bytes 5 .. ( m −1) | Datos de la aplicación | |||
Bytes m .. ( p −1) | MAC (opcional) | |||
Bytes p .. ( q −1) | Relleno (solo cifrados de bloque) |
- Largo
- Longitud de los datos de la aplicación (excluyendo el encabezado del protocolo e incluyendo los trailers MAC y de relleno)
- MAC
- 32 bytes para el HMAC basado en SHA-256 , 20 bytes para el HMAC basado en SHA-1 , 16 bytes para el HMAC basado en MD5 .
- Relleno
- Longitud variable; El último byte contiene la longitud del relleno.
Soporte para servidores virtuales basados en nombres
Desde el punto de vista del protocolo de aplicación, TLS pertenece a una capa inferior, aunque el modelo TCP / IP es demasiado burdo para mostrarlo. Esto significa que el protocolo de enlace TLS se realiza normalmente (excepto en el caso STARTTLS ) antes de que pueda iniciarse el protocolo de aplicación. En la función de servidor virtual basado en nombre que proporciona la capa de aplicación, todos los servidores virtuales cohospedados comparten el mismo certificado porque el servidor tiene que seleccionar y enviar un certificado inmediatamente después del mensaje ClientHello. Este es un gran problema en los entornos de alojamiento porque significa compartir el mismo certificado entre todos los clientes o usar una dirección IP diferente para cada uno de ellos.
Hay dos soluciones alternativas conocidas proporcionadas por X.509 :
- Si todos los servidores virtuales pertenecen al mismo dominio, se puede utilizar un certificado comodín . [311] Además de la selección suelta del nombre de host que podría ser un problema o no, no existe un acuerdo común sobre cómo hacer coincidir los certificados comodín. Se aplican diferentes reglas según el protocolo de aplicación o el software utilizado. [312]
- Agregue cada nombre de host virtual en la extensión subjectAltName. El principal problema es que es necesario volver a emitir el certificado cada vez que se agrega un nuevo servidor virtual.
Para proporcionar el nombre del servidor, Las extensiones RFC 4366 Transport Layer Security (TLS) permiten a los clientes incluir una extensión de indicación de nombre de servidor (SNI) en el mensaje ClientHello extendido. Esta extensión le indica al servidor inmediatamente el nombre al que el cliente desea conectarse, para que el servidor pueda seleccionar el certificado apropiado para enviar a los clientes.
RFC 2817 también documenta un método para implementar alojamiento virtual basado en nombres mediante la actualización de HTTP a TLS a través de un encabezado de actualización HTTP / 1.1 . Normalmente, esto es para implementar de forma segura HTTP sobre TLS dentro del esquema de URI "http" principal (que evita bifurcar el espacio de URI y reduce el número de puertos utilizados), sin embargo, pocas implementaciones actualmente admiten esto. [ cita requerida ]
Estándares
Estándares primarios
La versión aprobada actual de TLS es la versión 1.3, que se especifica en:
- RFC 8446 : "Protocolo de seguridad de la capa de transporte (TLS) versión 1.3".
El estándar actual reemplaza estas versiones anteriores, que ahora se consideran obsoletas:
- RFC 2246 : "El protocolo TLS versión 1.0".
- RFC 4346 : "Protocolo de seguridad de la capa de transporte (TLS) versión 1.1".
- RFC 5246 : "La versión 1.2 del protocolo de seguridad de la capa de transporte (TLS)".
Además de los nunca estandarizados SSL 2.0 y 3.0, que se consideran obsoletos:
- Borrador de Internet (1995) , SSL versión 2.0
- RFC 6101 : "Protocolo de capa de sockets seguros (SSL) versión 3.0".
Extensiones
Posteriormente, otras RFC ampliaron TLS.
Las extensiones de TLS 1.0 incluyen:
- RFC 2595 : "Uso de TLS con IMAP, POP3 y ACAP". Especifica una extensión de los servicios IMAP, POP3 y ACAP que permiten que el servidor y el cliente utilicen la seguridad de la capa de transporte para proporcionar comunicación privada y autenticada a través de Internet.
- RFC 2712 : "Adición de conjuntos de cifrado Kerberos a la seguridad de la capa de transporte (TLS)". Los conjuntos de cifrado de 40 bits definidos en este memo aparecen solo con el propósito de documentar el hecho de que esos códigos de conjunto de cifrado ya han sido asignados.
- RFC 2817 : "Actualización a TLS dentro de HTTP / 1.1", explica cómo utilizar el mecanismo de actualización en HTTP / 1.1 para iniciar Transport Layer Security (TLS) a través de una conexión TCP existente. Esto permite que el tráfico HTTP seguro y no seguro comparta el mismo puerto conocido (en este caso, http: en 80 en lugar de https: en 443).
- RFC 2818 : "HTTP sobre TLS", distingue el tráfico seguro del tráfico inseguro mediante el uso de un "puerto de servidor" diferente.
- RFC 3207 : "Extensión del servicio SMTP para SMTP seguro sobre la seguridad de la capa de transporte". Especifica una extensión del servicio SMTP que permite que un servidor y un cliente SMTP utilicen la seguridad de la capa de transporte para proporcionar comunicación privada y autenticada a través de Internet.
- RFC 3268 : "Conjuntos de cifrado AES para TLS". Agrega conjuntos de cifrado Advanced Encryption Standard (AES) a los cifrados simétricos existentes anteriormente.
- RFC 3546 : "Extensiones de seguridad de la capa de transporte (TLS)", agrega un mecanismo para negociar extensiones de protocolo durante la inicialización de la sesión y define algunas extensiones. Hecho obsoleto por RFC 4366 .
- RFC 3749 : "Métodos de compresión del protocolo de seguridad de la capa de transporte", especifica el marco para los métodos de compresión y el método de compresión DEFLATE .
- RFC 3943 : "Compresión del protocolo de seguridad de la capa de transporte (TLS) mediante Lempel-Ziv-Stac (LZS)".
- RFC 4132 : "Adición de Camellia Cipher Suites a Transport Layer Security (TLS)".
- RFC 4162 : "Adición de conjuntos de cifrado SEED a Transport Layer Security (TLS)".
- RFC 4217 : "Asegurar FTP con TLS ".
- RFC 4279 : "Conjuntos de cifrado de claves precompartidas para la seguridad de la capa de transporte (TLS)", agrega tres conjuntos de nuevos conjuntos de cifrado para que el protocolo TLS admita la autenticación basada en claves previamente compartidas.
Las extensiones de TLS 1.1 incluyen:
- RFC 4347 : " Seguridad de la capa de transporte de datagramas " especifica una variante de TLS que funciona sobre protocolos de datagramas (como UDP).
- RFC 4366 : "Extensiones de seguridad de la capa de transporte (TLS)" describe tanto un conjunto de extensiones específicas como un mecanismo de extensión genérico.
- RFC 4492 : " Conjuntos de cifrado de criptografía de curva elíptica (ECC) para seguridad de la capa de transporte (TLS)".
- RFC 4680 : "Mensaje de protocolo de enlace TLS para datos suplementarios".
- RFC 4681 : "Extensión de asignación de usuarios TLS".
- RFC 4785 : "Conjuntos de cifrado de clave precompartida (PSK) con cifrado NULL para seguridad de la capa de transporte (TLS)".
- RFC 5054 : "Uso del protocolo de contraseña remota segura (SRP) para la autenticación TLS". Define los conjuntos de cifrado TLS-SRP .
- RFC 5077 : "Reanudación de sesión de seguridad de la capa de transporte (TLS) sin estado del lado del servidor".
- RFC 5081 : "Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS)", obsoleto por RFC 6091 .
Las extensiones de TLS 1.2 incluyen:
- RFC 5288 : " Conjuntos de cifrado del modo contador AES Galois (GCM) para TLS".
- RFC 5289 : "Conjuntos de cifrado de curva elíptica TLS con SHA-256/384 y modo de contador AES Galois (GCM)".
- RFC 5746 : "Extensión de indicación de renegociación de seguridad de la capa de transporte (TLS)".
- RFC 5878 : "Extensiones de autorización de seguridad de la capa de transporte (TLS)".
- RFC 5932 : "Camellia Cipher Suites para TLS"
- RFC 6066 : "Extensiones de seguridad de la capa de transporte (TLS): definiciones de extensión", incluye indicación de nombre de servidor y grapado OCSP .
- RFC 6091 : "Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS)".
- RFC 6176 : "Prohibición de la capa de sockets seguros (SSL) versión 2.0".
- RFC 6209 : "Adición de las suites de cifrado ARIA a la seguridad de la capa de transporte (TLS)".
- RFC 6347 : "Seguridad de la capa de transporte de datagramas versión 1.2".
- RFC 6367 : "Adición de Camellia Cipher Suites a Transport Layer Security (TLS)".
- RFC 6460 : "Perfil de Suite B para seguridad de la capa de transporte (TLS)".
- RFC 6655 : "Conjuntos de cifrado AES-CCM para seguridad de la capa de transporte (TLS)".
- RFC 7027 : "Criptografía de curva elíptica (ECC) Curvas de Brainpool para la seguridad de la capa de transporte (TLS)".
- RFC 7251 : " Conjuntos de cifrado de criptografía de curva elíptica (ECC) AES-CCM para TLS".
- RFC 7301 : " Extensión de negociación del protocolo de capa de aplicación de seguridad de la capa de transporte (TLS) ".
- RFC 7366 : "Cifrar y luego MAC para seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS)".
- RFC 7465 : "Prohibición de conjuntos de cifrado RC4".
- RFC 7507 : "Valor de conjunto de cifrado de señalización de reserva de TLS (SCSV) para prevenir ataques de degradación de protocolos".
- RFC 7568 : "Desactivación de la capa de sockets seguros versión 3.0".
- RFC 7627 : "Hash de sesión de seguridad de la capa de transporte (TLS) y extensión secreta maestra extendida".
- RFC 7685 : "Una extensión de relleno ClientHello de seguridad de la capa de transporte (TLS)".
Las encapsulaciones de TLS incluyen:
- RFC 5216 : " Protocolo de autenticación EAP -TLS"
RFC informativas
- RFC 7457 : "Resumen de los ataques conocidos sobre la seguridad de la capa de transporte (TLS) y el datagrama TLS (DTLS)"
- RFC 7525 : "Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS)"
Ver también
- Negociación de protocolo de capa de aplicación : una extensión TLS utilizada para SPDY y TLS False Start
- Bullrun (programa de descifrado) : un programa secreto contra el cifrado gestionado por la Agencia de Seguridad Nacional de EE. UU.
- Autoridad certificada
- Transparencia del certificado
- Seguridad de transporte estricta HTTP - HSTS
- Archivo de llavero
- QUIC (Conexiones rápidas a Internet UDP): "... fue diseñado para proporcionar una protección de seguridad equivalente a TLS / SSL"; El objetivo principal de QUIC es mejorar el rendimiento percibido de las aplicaciones web orientadas a la conexión que actualmente utilizan TCP
- Criptografía controlada por servidor
- tcpcrypt
- DTLS
- Aceleración TLS
Referencias
- ^ Lawrence, Scott; Khare, Rohit. "Actualización a TLS dentro de HTTP / 1.1" . tools.ietf.org . Consultado el 15 de diciembre de 2018 .
- ^ " SSL / TLS en detalle archivado el 6 de febrero de 2015 en la Wayback Machine ". Microsoft TechNet . Actualizado el 30 de julio de 2003.
- ^ a b Hooper, Howard (2012). CCNP Security VPN 642-648 Official Cert Guide (2 ed.). Prensa de Cisco. pag. 22. ISBN 9780132966382.
- ^ a b Spott, Andrew; Puerro, tom; et al. "¿Qué capa es TLS?" . Intercambio de pilas de seguridad de la información .
- ^ a b T. Dierks, E. Rescorla (agosto de 2008). "Introducción" . Protocolo de seguridad de la capa de transporte (TLS) Versión 1.2 . segundo. 1. doi : 10.17487 / RFC5246 . RFC 5246 .
- ^ E. Rescorla (agosto de 2008). "El Protocolo de Seguridad de la Capa de Transporte (TLS) Versión 1.3" .
- ^ a b c d T. Dierks; E. Rescorla (agosto de 2008). "La versión 1.2 del protocolo de seguridad de la capa de transporte (TLS)" . Archivado desde el original el 24 de diciembre de 2017.
- ^ a b c d e Bright, Peter (17 de octubre de 2018). "Apple, Google, Microsoft y Mozilla se unen para acabar con TLS 1.0" . Consultado el 17 de octubre de 2018 .
- ^ a b c d "Esto es lo que es nuevo y cambiado en Firefox 74.0 estable - gHacks Tech News" . www.ghacks.net . Consultado el 10 de marzo de 2020 .
- ^ a b c d "TLS 1.0 y TLS 1.1 - Estado de la plataforma Chrome" . chromestatus.com . Consultado el 10 de marzo de 2020 .
- ^ https://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/
- ^ Thomas YC Woo, Raghuram Bindignavle, Shaowen Su y Simon S. Lam , SNP: una interfaz para la programación de red segura Actas Conferencia técnica de verano de USENIX, junio de 1994
- ^ Messmer, Ellen. "Padre de SSL, Dr. Taher Elgamal, encuentra proyectos de TI de rápido movimiento en el Medio Oriente" . Mundo de la red . Archivado desde el original el 31 de mayo de 2014 . Consultado el 30 de mayo de 2014 .
- ^ Greene, Tim. "El padre de SSL dice que a pesar de los ataques, al eje de la seguridad le queda mucha vida" . Mundo de la red . Archivado desde el original el 31 de mayo de 2014 . Consultado el 30 de mayo de 2014 .
- ^ a b Oppliger, Rolf (2016). "Introducción" . SSL y TLS: teoría y práctica (2ª ed.). Casa Artech . pag. 13. ISBN 978-1-60807-999-5. Consultado el 1 de marzo de 2018 a través de Google Books.
- ^ "EL PROTOCOLO SSL" . Netscape Corporation. 2007. Archivado desde el original el 14 de junio de 1997.
- ^ Rescorla 2001
- ^ "CANICHE: vulnerabilidad SSLv3 (CVE-2014-3566)" . Archivado desde el original el 5 de diciembre de 2014 . Consultado el 21 de octubre de 2014 .
- ^ "Normas de seguridad y cambios de nombre en las guerras de navegadores" . Consultado el 29 de febrero de 2020 .
- ^ Laura K. Gray (18 de diciembre de 2015). "Cambio de fecha para la migración de SSL y TLS temprana" . Blog del Consejo de Normas de Seguridad de la Industria de Tarjetas de Pago . Consultado el 5 de abril de 2018 .
- ^ Company, Newtek - Your Business Solutions. "Los cambios en el cumplimiento de PCI se realizarán el 30 de junio. ¿Está listo su negocio de comercio electrónico?" . Forbes . Consultado el 20 de junio de 2018 .
- ^ Dierks, T. & E. Rescorla (abril de 2006). "El Protocolo de Seguridad de la Capa de Transporte (TLS) Versión 1.1" . RFC 4346 . Archivado desde el original el 24 de diciembre de 2017.
- ^ a b Polk, Tim; McKay, Terry; Chokhani, Santosh (abril de 2014). "Directrices para la selección, configuración y uso de implementaciones de seguridad de la capa de transporte (TLS)" (PDF) . Instituto Nacional de Estándares y Tecnología. pag. 67. Archivado desde el original (PDF) el 8 de mayo de 2014 . Consultado el 7 de mayo de 2014 .Mantenimiento de CS1: utiliza el parámetro de autores ( enlace )
- ^ "Twitter dejará de admitir TLS 1.0, TLS 1.1 el 15 de julio" . Hashed Out por The SSL Store ™ . 2019-07-12 . Consultado el 14 de junio de 2021 .
- ^ Mackie, Kurt. "Microsoft retrasa la finalización del soporte para TLS 1.0 y 1.1 -" . Revista profesional certificada de Microsoft en línea .
- ^ T. Dierks, E. Rescorla (agosto de 2008). "Terminado" . Protocolo de seguridad de la capa de transporte (TLS) Versión 1.2 . segundo. 7.4.9. doi : 10.17487 / RFC5246 . RFC 5246 .
- ^ "Diferencias entre TLS 1.2 y TLS 1.3 (# TLS13)" . WolfSSL . 18 de septiembre de 2019. Archivado desde el original el 19 de septiembre de 2019 . Consultado el 18 de septiembre de 2019 .
- ^ "Notas de la versión de NSS 3.29" . Red de desarrolladores de Mozilla. Febrero de 2017. Archivado desde el original el 22 de febrero de 2017 .
- ^ "Habilitar TLS 1.3 de forma predeterminada" . Bugzilla @ Mozilla. 16 de octubre de 2016 . Consultado el 10 de octubre de 2017 .
- ^ "Firefox - Notas (60.0)" . Mozilla . Consultado el 10 de mayo de 2018 .
- ^ "ProxySG, ASG y WSS interrumpirán las conexiones SSL cuando los clientes que utilicen TLS 1.3 accedan a sitios que también utilicen TLS 1.3" . BlueTouch en línea . 16 de mayo de 2017. Archivado desde el original el 12 de septiembre de 2017 . Consultado el 11 de septiembre de 2017 .
- ^ "TLS 1.3 IETF 100 Hackathon" . Archivado desde el original el 15 de enero de 2018.
- ^ a b IETF - Grupo de trabajo de ingeniería de Internet (2017-11-12), IETF Hackathon Presentations and Awards , consultado el 14 de noviembre de 2017
- ^ "¡Hurra! TLS 1.3 ya está aquí. Ahora para implementarlo y ponerlo en software" . Consultado el 28 de marzo de 2018 .
- ^ IETF - Grupo de trabajo de ingeniería de Internet (2018-07-15), IETF102-HACKATHON-20180715-1400 , consultado el 18 de julio de 2018
- ^ "Lanzamiento de wolfSSL TLS 1.3 BETA ya disponible" . [email protected]. 11 de mayo de 2017 . Consultado el 11 de mayo de 2017 .
- ^ "SOPORTE DEL PROTOCOLO TLS 1.3" . [email protected].
- ^ "Soporte TLS 1.3 Draft 28 en wolfSSL" . [email protected]. 14 de junio de 2018 . Consultado el 14 de junio de 2018 .
- ^ "Lanzamiento de OpenSSL 1.1.1" . Matt Caswell. 11 de septiembre de 2018 . Consultado el 19 de diciembre de 2018 .
- ^ Hoffman-Andrews, Jacob (26 de febrero de 2019). "ETS no es TLS y no debería usarlo" . Fundación Frontera Electrónica . Consultado el 27 de febrero de 2019 .
- ^ TS 103523-3 - V1.1.1 - CIBER; Protocolo de seguridad de Middlebox; Parte 3: Perfil para la red empresarial y el control de acceso al centro de datos ETSI
- ^ Un grupo de la industria financiera está impulsando un "estándar" de criptografía intencionalmente roto llamado ETS Boing Boing
- ^ Rea, Scott (2013). "Alternativas a las autoridades de certificación para una Web segura" (PDF) . Conferencia RSA Asia Pacífico. Archivado (PDF) desde el original el 7 de octubre de 2016 . Consultado el 7 de septiembre de 2016 .
- ^ Contando certificados SSL; netcraft; 13 de mayo de 2015. Archivado el 16 de mayo de 2015 en la Wayback Machine.
- ^ Raymond, Art (3 de agosto de 2017). "DigiCert de Lehi se traga al competidor de seguridad web en un acuerdo de mil millones de dólares" . Deseret News . Consultado el 21 de mayo de 2020 .
- ^ "Tendencias de cuota de mercado para las autoridades de certificación SSL" . W3Techs . Consultado el 21 de mayo de 2020 .
- ^ Dispositivo de aplicación de la ley subvierte SSL Archivado el 15 de marzo de 2014 en la Wayback Machine , con cable, el 3 deabril de 2010.
- ^ Una nueva investigación sugiere que los gobiernos pueden falsificar certificados SSL Archivado 2016-01-04 en Wayback Machine , EFF, 2010-03-24.
- ^ P. Eronen, Ed. "Conjuntos de cifrado de claves precompartidas para la seguridad de la capa de transporte (TLS)" . Grupo de Trabajo de Ingeniería de Internet. RFC 4279 . Archivado desde el original el 5 de septiembre de 2013 . Consultado el 9 de septiembre de 2013 .
- ^ D. Taylor, Ed. "Uso del protocolo de contraseña remota segura (SRP) para la autenticación TLS" . Grupo de Trabajo de Ingeniería de Internet. RFC 5054 . Archivado desde el original el 7 de diciembre de 2014 . Consultado el 21 de diciembre de 2014 .
- ^ Gothard, Peter. "Google actualiza los certificados SSL a un cifrado de 2048 bits" . Computación . Medios incisivos. Archivado desde el original el 22 de septiembre de 2013 . Consultado el 9 de septiembre de 2013 .
- ^ "El valor del cifrado de 2048 bits: por qué es importante la longitud de la clave de cifrado" . SearchSecurity . Archivado desde el original el 16 de enero de 2018 . Consultado el 18 de diciembre de 2017 .
- ^ Sean Turner (17 de septiembre de 2015). "Consenso: eliminar DSA de TLS 1.3" . Archivado desde el original el 3 de octubre de 2015.
- ^ RFC 8422
- ^ a b c d draft-chudov-cryptopro-cptls-04 - GOST 28147-89 Conjuntos de cifrado para seguridad de la capa de transporte (TLS)
- ^ RFC 5288 , 5289
- ^ RFC 6655 , 7251
- ^ RFC 6367
- ^ RFC 5932 , 6367
- ^ a b RFC 6209
- ^ RFC 4162
- ^ "Sobre la (in) seguridad práctica de cifrados en bloque de 64 bits: ataques de colisión en HTTP sobre TLS y OpenVPN" (PDF) . 2016-10-28. Archivado (PDF) desde el original el 24 de abril de 2017 . Consultado el 8 de junio de 2017 .
- ^ " Recomendación de la publicación especial 800-57 del NIST para la gestión de claves - Parte 1: General (revisada) " (PDF) . 2007-03-08. Archivado desde el original (PDF) el 6 de junio de 2014 . Consultado el 3 de julio de 2014 .
- ^ a b c Laboratorios SSL de Qualys. "Mejores prácticas de implementación de SSL / TLS" . Archivado desde el original el 4 de julio de 2015 . Consultado el 2 de junio de 2015 .
- ^ RFC 5469
- ^ RFC 7905
- ^ Cifrados AEAD
- ^ "Http vs https" . Archivado desde el original el 12 de febrero de 2015 . Consultado el 12 de febrero de 2015 .
- ^ a b c d A partir del 11 de abril de 2021. "SSL Pulse: Encuesta sobre la implementación de SSL de los sitios web más populares" . Qualys . Consultado el 25 de abril de 2021 .
- ^ a b ivanr. "RC4 en TLS está roto: ¿y ahora qué?" . Laboratorios de seguridad de Qualsys. Archivado desde el original el 27 de agosto de 2013 . Consultado el 30 de julio de 2013 .
- ^ a b c Bodo Möller, Thai Duong y Krzysztof Kotowicz. "Este CANICHE muerde: Explotando el respaldo de SSL 3.0" (PDF) . Archivado (PDF) desde el original el 14 de octubre de 2014 . Consultado el 15 de octubre de 2014 .
- ^ "¿Qué navegadores admiten Extended Validation (EV) y muestran un indicador EV?" . Symantec . Archivado desde el original el 31 de diciembre de 2015 . Consultado el 28 de julio de 2014 .
- ^ a b c d e f g h yo j k l m n "Compatibilidad SHA-256" . Archivado desde el original el 1 de julio de 2015 . Consultado el 12 de junio de 2015 .
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab "Compatibilidad ECC" . Archivado desde el original el 17 de febrero de 2016 . Consultado el 13 de junio de 2015 .
- ^ a b "Seguimiento del ataque FREAK" . Archivado desde el original el 6 de marzo de 2015 . Consultado el 8 de marzo de 2015 .
- ^ a b "FREAK: Factorización de claves de exportación RSA" . Archivado desde el original el 11 de marzo de 2015 . Consultado el 8 de marzo de 2015 .
- ^ Google (29 de mayo de 2012). "Actualización del canal de desarrollo" . Archivado desde el original el 2 de marzo de 2013 . Consultado el 1 de junio de 2011 .
- ^ Google (21 de agosto de 2012). "Actualización de canal estable" . Archivado desde el original el 25 de agosto de 2012 . Consultado el 22 de agosto de 2012 .
- ^ Proyecto Chromium (30 de mayo de 2013). "Implementación de Chromium TLS 1.2" .
- ^ "El proyecto Chromium: BoringSSL" . Archivado desde el original el 23 de septiembre de 2015 . Consultado el 5 de septiembre de 2015 .
- ^ a b "Lanzamiento estable de Chrome" . Lanzamientos de Chrome . 2011-10-25. Archivado desde el original el 20 de febrero de 2015 . Consultado el 1 de febrero de 2015 .
- ^ "Registro de revisión SVN en Chrome versión 10.0.648.127" . Archivado desde el original el 19 de junio de 2014 . Consultado el 19 de junio de 2014 .
- ^ a b "ImperialViolet - DELITO" . 2012-09-22. Archivado desde el original el 10 de enero de 2015 . Consultado el 18 de octubre de 2014 .
- ^ a b "Descripción general de SSL / TLS" . 2008-08-06. Archivado desde el original el 3 de julio de 2013 . Consultado el 29 de marzo de 2013 .
- ^ a b "Edición de Chromium 90392" . 2008-08-06. Archivado desde el original el 3 de agosto de 2013 . Consultado el 28 de junio de 2013 .
- ^ a b "Problema 23503030 Fusionar 219882" . 2013-09-03. Archivado desde el original el 26 de febrero de 2014 . Consultado el 19 de septiembre de 2013 .
- ^ a b "Problema 278370: no se pueden enviar certificados de cliente a través de TLS 1.2 desde Windows" . 2013-08-23. Archivado desde el original el 5 de octubre de 2013 . Consultado el 3 de octubre de 2013 .
- ^ Möller, Bodo (14 de octubre de 2014). "Este CANICHE muerde: explotando el respaldo de SSL 3.0" . Blog de seguridad en línea de Google . Google (a través de Blogspot). Archivado desde el original el 28 de octubre de 2014 . Consultado el 28 de octubre de 2014 .
- ^ a b c "Una actualización de SSLv3 en Chrome" . Security-dev . 2014-10-31 . Consultado el 4 de noviembre de 2014 .
- ^ "Actualización de canal estable" . Red de desarrolladores de Mozilla . 2014-02-20. Archivado desde el original el 24 de octubre de 2014 . Consultado el 14 de noviembre de 2014 .
- ^ "Registro de cambios para Chrome 33.0.1750.117" . Google . Archivado desde el original el 16 de enero de 2014 . Consultado el 14 de noviembre de 2014 .
- ^ "Problema 318442: actualización a NSS 3.15.3 y NSPR 4.10.2" . Archivado desde el original el 15 de marzo de 2015 . Consultado el 14 de noviembre de 2014 .
- ^ a b c d e "Problema 693963003: Agregar control de versión mínimo de TLS a about: flags y Finch lo abren. - Revisión de código" . Archivado desde el original el 16 de abril de 2015 . Consultado el 22 de enero de 2015 .
- ^ a b c "Problema 375342: Drop RC4 Support" . Archivado desde el original el 12 de septiembre de 2015 . Consultado el 22 de mayo de 2015 .
- ^ a b "Problema 436391: agregar información sobre el final de la vida útil de la política SSLVersionFallbackMin y SSLVersionMin en la documentación" . Archivado desde el original el 18 de abril de 2015 . Consultado el 19 de abril de 2015 .
- ^ "Problema 490240: Aumente el tamaño mínimo de DH a 1024 bits (error de seguimiento)" . Archivado desde el original el 12 de septiembre de 2015 . Consultado el 29 de mayo de 2015 .
- ^ a b c d e f g h yo j k l "Intención de desaprobar: RC4" . Consultado el 21 de diciembre de 2015 .
- ^ a b c d e f g h yo j k l "Una actualización de los certificados SHA-1 en Chrome" . 2015-12-18. Archivado desde el original el 18 de diciembre de 2015 . Consultado el 21 de diciembre de 2015 .
- ^ a b https://support.google.com/chrome/a/answer/7679408?hl=es
- ^ a b https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#sslversionmin
- ^ a b c d "Seguridad en Firefox 2" . 2008-08-06. Archivado desde el original el 14 de julio de 2014 . Consultado el 31 de marzo de 2009 .
- ^ a b "Ataque contra comunicaciones protegidas por TLS" . Blog de seguridad de Mozilla . Mozilla. 2011-09-27. Archivado desde el original el 4 de marzo de 2015 . Consultado el 1 de febrero de 2015 .
- ^ a b "Introducción a SSL" . MDN. Archivado desde el original el 14 de julio de 2014 . Consultado el 19 de junio de 2014 .
- ^ a b "Notas de la versión NSS 3.15.3" . Red de desarrolladores de Mozilla . Mozilla. Archivado desde el original el 5 de junio de 2014 . Consultado el 13 de julio de 2014 .
- ^ a b "MFSA 2013-103: vulnerabilidades de varios servicios de seguridad de red (NSS)" . Mozilla . Mozilla. Archivado desde el original el 14 de julio de 2014 . Consultado el 13 de julio de 2014 .
- ^ "Error 565047 - (RFC4346) Implementar TLS 1.1 (RFC 4346)" . Consultado el 29 de octubre de 2013 .
- ^ "Error 480514 - Implementar soporte para TLS 1.2 (RFC 5246)" . Consultado el 29 de octubre de 2013 .
- ^ "Error 733647 - Implementar TLS 1.1 (RFC 4346) en Gecko (Firefox, Thunderbird), por defecto" . Consultado el 4 de diciembre de 2013 .
- ^ a b "Notas de Firefox - Escritorio" . 2014-02-04. Archivado desde el original el 7 de febrero de 2014 . Consultado el 4 de febrero de 2014 .
- ^ "Error 861266 - Implementar TLS 1.2 (RFC 5246) en Gecko (Firefox, Thunderbird), activado de forma predeterminada" . Consultado el 18 de noviembre de 2013 .
- ^ a b c "El ataque POODLE y el fin de SSL 3.0" . Blog de Mozilla . Mozilla. 2014-10-14. Archivado desde el original el 18 de octubre de 2014 . Consultado el 28 de octubre de 2014 .
- ^ "Firefox - Notas (34.0) - Mozilla" . mozilla.org. 2014-12-01. Archivado desde el original el 9 de abril de 2015 . Consultado el 3 de abril de 2015 .
- ^ "Error 1083058 - Una preferencia para controlar el respaldo de la versión TLS" . bugzilla.mozilla.org . Consultado el 6 de noviembre de 2014 .
- ^ "Error 1036737: agregar soporte para draft-ietf-tls-downgrade-scsv a Gecko / Firefox" . bugzilla.mozilla.org . Consultado el 29 de octubre de 2014 .
- ^ a b c "Error 1166031: actualización a NSS 3.19.1" . bugzilla.mozilla.org . Consultado el 29 de mayo de 2015 .
- ^ "Error 1088915 - Dejar de ofrecer RC4 en los primeros apretones de manos" . bugzilla.mozilla.org . Consultado el 4 de noviembre de 2014 .
- ^ "Firefox - Notas (39.0) - Mozilla" . mozilla.org. 2015-06-30. Archivado desde el original el 3 de julio de 2015 . Consultado el 3 de julio de 2015 .
- ^ "Google, Microsoft y Mozilla eliminarán el cifrado RC4 en Chrome, Edge, IE y Firefox el próximo año" . VentureBeat . 2015-09-01. Archivado desde el original el 5 de septiembre de 2015 . Consultado el 5 de septiembre de 2015 .
- ^ "Intención de envío: RC4 deshabilitado por defecto en Firefox 44" . Archivado desde el original el 22 de enero de 2011 . Consultado el 18 de octubre de 2015 .
- ^ "RC4 ahora solo se permite en los sitios de la lista blanca (revertido)" . Consultado el 2 de noviembre de 2015 .
- ^ "Firefox - Notas (44.0) - Mozilla" . mozilla.org. 2016-01-26. Archivado desde el original el 4 de marzo de 2016 . Consultado el 9 de marzo de 2016 .
- ^ "Error 1342082 - Deshabilitar TLS 1.3 para la versión FF52" . Consultado el 29 de marzo de 2017 .
- ^ a b https://www.mozilla.org/en-US/firefox/78.0/releasenotes/
- ^ "Registro de cambios de Opera 9.0 para Windows" . Archivado desde el original el 10 de septiembre de 2012.
- ^ "Serie Opera 2" . Archivado desde el original el 23 de octubre de 2014 . Consultado el 20 de septiembre de 2014 .
- ^ "Serie Opera 3" . Archivado desde el original el 23 de octubre de 2014 . Consultado el 20 de septiembre de 2014 .
- ^ "Serie Opera 4" . Archivado desde el original el 23 de octubre de 2014 . Consultado el 20 de septiembre de 2014 .
- ^ "Registro de cambios de Opera 5.x para Windows" . Archivado desde el original el 19 de octubre de 2014 . Consultado el 19 de junio de 2014 .
- ^ "Registro de cambios de Opera [8] Beta 2 para Windows" . Archivado desde el original el 23 de noviembre de 2005 . Consultado el 19 de junio de 2014 .
- ^ "Especificaciones web compatibles con Opera 9" . Archivado desde el original el 26 de octubre de 2014 . Consultado el 19 de junio de 2014 .
- ^ a b "Opera: Opera 10 beta para registro de cambios de Windows" . Archivado desde el original el 23 de octubre de 2014 . Consultado el 19 de junio de 2014 .
- ^ "Acerca de Opera 11.60 y nuevos problemas con algunos servidores seguros" . 2011-12-11. Archivado desde el original el 18 de enero de 2012.
- ^ a b c "Cambios de seguridad en Opera 25; los ataques de caniche" . 2014-10-15. Archivado desde el original el 20 de octubre de 2014 . Consultado el 28 de octubre de 2014 .
- ^ a b c d "Deshazte del atasco" . 2015-06-09. Archivado desde el original el 14 de junio de 2015 . Consultado el 11 de junio de 2015 .
- ^ "Aviso: el protocolo de cifrado RC4 es vulnerable a ciertos ataques de fuerza bruta" . 2013-04-04. Archivado desde el original el 15 de marzo de 2015 . Consultado el 14 de noviembre de 2014 .
- ^ "Sobre la precariedad de RC4" . 2013-03-20. Archivado desde el original el 12 de noviembre de 2013 . Consultado el 17 de noviembre de 2014 .
- ^ a b c d e "Actualización de seguridad de Opera 12 y Opera Mail" . 2016-02-16. Archivado desde el original el 16 de febrero de 2016 . Consultado el 17 de febrero de 2016 .
- ^ "Dev.Opera - ¡Opera 14 para Android ya está disponible!" . 2013-05-21. Archivado desde el original el 30 de enero de 2015 . Consultado el 23 de septiembre de 2014 .
- ^ "Dev.Opera - Presentación de Opera 15 para computadoras y un ciclo de lanzamiento rápido" . 2013-07-02. Archivado desde el original el 2 de septiembre de 2014 . Consultado el 23 de septiembre de 2014 .
- ^ igual que Chrome 26-29
- ^ igual que Chrome 30 y posterior
- ^ a b igual que Chrome 33 y posterior
- ^ Microsoft (5 de septiembre de 2012). "Canal seguro" . Archivado desde el original el 29 de agosto de 2012 . Consultado el 18 de octubre de 2012 .
- ^ Microsoft (27 de febrero de 2009). "Apéndice A de MS-TLSP" . Archivado desde el original el 27 de septiembre de 2013 . Consultado el 19 de marzo de 2009 .
- ^ a b "¿Qué navegadores solo admiten SSLv2?" . Consultado el 19 de junio de 2014 .
- ^ a b c d "SHA2 y Windows - Blog de PKI de Windows - Página principal del sitio - Blogs de TechNet" . 2010-09-30. Archivado desde el original el 16 de julio de 2014 . Consultado el 29 de julio de 2014 .
- ^ a b c d e "Mejoras de seguridad HTTPS en Internet Explorer 7" . Archivado desde el original el 10 de octubre de 2013 . Consultado el 29 de octubre de 2013 .
- ^ "Suites de cifrado TLS" . Microsoft. Archivado desde el original el 13 de marzo de 2017.
- ^ "Copia archivada" . Archivado desde el original el 11 de marzo de 2015 . Consultado el 19 de julio de 2017 .CS1 maint: copia archivada como título ( enlace )
- ^ a b c d e f g "Vulnerabilidad en Schannel podría permitir la omisión de funciones de seguridad (3046049)" . 2015-03-10. Archivado desde el original el 13 de marzo de 2017 . Consultado el 11 de marzo de 2015 .
- ^ a b c d e f g "Vulnerabilidad en Schannel podría permitir la divulgación de información (3061518)" . 2015-05-12. Archivado desde el original el 8 de octubre de 2016 . Consultado el 22 de mayo de 2015 .
- ^ a b c d "Actualización para agregar soporte para TLS 1.1 y TLS 1.2 en Windows Server 2008 SP2, Windows Embedded POSReady 2009 y Windows Embedded Standard 2009" . Consultado el 19 de julio de 2017 .
- ^ a b "Windows 7 agrega soporte para TLSv1.1 y TLSv1.2 - IEInternals - Inicio del sitio - Blogs de MSDN" . Archivado desde el original el 26 de diciembre de 2013 . Consultado el 29 de octubre de 2013 .
- ^ Thomlinson, Matt (11 de noviembre de 2014). "Cientos de millones de clientes de Microsoft se benefician ahora del mejor cifrado de su clase" . Seguridad de Microsoft. Archivado desde el original el 14 de noviembre de 2014 . Consultado el 14 de noviembre de 2014 .
- ^ Aviso de seguridad de Microsoft: Actualización para deshabilitar RC4 Archivado 2015-03-11 en Wayback Machine
- ^ a b c d Microsoft (24 de septiembre de 2013). "Cambios de IE11" . Archivado desde el original el 30 de octubre de 2013 . Consultado el 1 de noviembre de 2013 .
- ^ "Actualizaciones de seguridad de febrero de 2015 para Internet Explorer" . 2015-02-11. Archivado desde el original el 11 de febrero de 2015 . Consultado el 11 de febrero de 2015 .
- ^ "La actualización activa la configuración para deshabilitar el respaldo de SSL 3.0 para sitios en modo protegido de forma predeterminada en Internet Explorer 11" . Archivado desde el original el 14 de febrero de 2015 . Consultado el 11 de febrero de 2015 .
- ^ "La vulnerabilidad en SSL 3.0 podría permitir la divulgación de información" . 2015-04-14. Archivado desde el original el 8 de octubre de 2016 . Consultado el 14 de abril de 2015 .
- ^ Equipo de Microsoft Edge (9 de agosto de 2016). "RC4 ahora está deshabilitado en Microsoft Edge e Internet Explorer 11" . Microsoft. Archivado desde el original el 21 de agosto de 2016.
- ^ "Internet Explorer 11 para Windows Server 2012 y Windows Embedded 8 Standard" . Soporte de Microsoft . 2019-04-16.
- ^ a b c d e "TLS (Schannel SSP) cambios en Windows 10 y Windows Server 2016" . Microsoft. 2017-03-21. Archivado desde el original el 30 de marzo de 2017 . Consultado el 29 de marzo de 2017 .
- ^ a b "Protocolos en TLS / SSL (Schannel SSP)" .
- ^ a b c d "Qué navegadores funcionan con Universal SSL" . Archivado desde el original el 4 de marzo de 2016 . Consultado el 15 de junio de 2015 .
- ^ "Vulnerabilidad de POODLE SSL - proteja su Windo ... - Desarrollo y piratería de Windows Phone 8" . Desarrolladores XDA . Archivado desde el original el 23 de septiembre de 2016.
- ^ a b "¿Qué versión de TLS se utiliza en Windows Phone 8 para conexiones HTTP seguras?" . Microsoft. Archivado desde el original el 4 de marzo de 2016 . Consultado el 7 de noviembre de 2014 .
- ^ "Qualys SSL Labs - Proyectos / Capacidades del agente de usuario: Desconocido" . Archivado desde el original el 1 de marzo de 2017.
- ^ a b "Seguridad de la plataforma" . Microsoft. 2014-06-25. Archivado desde el original el 13 de marzo de 2017 . Consultado el 7 de noviembre de 2014 .
- ^ "Notas de la versión: problemas importantes en la vista previa de Windows 8.1" . Microsoft. 2013-06-24. Archivado desde el original el 4 de noviembre de 2014 . Consultado el 4 de noviembre de 2014 .
- ^ "W8.1 (IE11) frente a RC4" . Comunidad Qualys . Archivado desde el original el 4 de noviembre de 2014 . Consultado el 4 de noviembre de 2014 .
- ^ Adrian, Dimcev. "Navegadores / bibliotecas / servidores comunes y las suites de cifrado asociadas implementadas" . Proyecto TLS Cipher Suites . Archivado desde el original el 17 de abril de 2013.
- ^ "Características" . Safari . Manzana. 2009-06-10. Archivado desde el original el 17 de abril de 2013 . Consultado el 10 de junio de 2009 .
- ^ "Curl: parche para agregar compatibilidad con TLS 1.1 y 1.2 y reemplazar funciones obsoletas en SecureTransport" . Suecia: haxx.se. Archivado desde el original el 1 de marzo de 2017.
- ^ Informe SSL de Qualys: google.co.uk Archivado 2017-03-20 en Wayback Machine (simulación Safari 5.1.9 TLS 1.0)
- ^ "Apple asegura Mac OS X con lanzamiento de Mavericks" . eSecurity Planet. 2013-10-25. Archivado desde el original el 8 de julio de 2014 . Consultado el 23 de junio de 2014 .
- ^ Ristic, Ivan (10 de septiembre de 2013). "¿BESTIA sigue siendo una amenaza?" . Qualys. Archivado desde el original el 12 de octubre de 2014.
- ^ a b Ristić, Ivan (31 de octubre de 2013). "Apple habilitó las mitigaciones de BEAST en OS X 10.9 Mavericks" . Archivado desde el original el 7 de noviembre de 2013 . Consultado el 7 de noviembre de 2013 .
- ^ Ristić, Ivan (26 de febrero de 2014). "Apple finalmente lanza parche para BEAST" . Qualys. Archivado desde el original el 14 de julio de 2014 . Consultado el 1 de julio de 2014 .
- ^ "Acerca de la actualización de seguridad 2014-005" . Artículo de la base de conocimientos de soporte técnico de Apple . Manzana. Archivado desde el original el 24 de octubre de 2014.
- ^ "Acerca del contenido de seguridad de iOS 8.1" . Artículo de la base de conocimientos de soporte técnico de Apple . Manzana. Archivado desde el original el 23 de octubre de 2014.
- ^ a b c "Acerca de la actualización de seguridad 2015-002" . Artículo de la base de conocimientos de soporte técnico de Apple . Manzana. Archivado desde el original el 16 de marzo de 2015 . Consultado el 9 de marzo de 2015 .
- ^ a b "Acerca del contenido de seguridad de OS X Mavericks v10.9" . Archivado desde el original el 4 de julio de 2014 . Consultado el 20 de junio de 2014 .
- ^ "Capacidades del agente de usuario: Safari 8 / OS X 10.10" . Laboratorios SSL de Qualys. Archivado desde el original el 6 de septiembre de 2015 . Consultado el 7 de marzo de 2015 .
- ^ "Sobre el contenido de seguridad de OS X Yosemite v10.10.4 y la Actualización de seguridad 2015-005" . Archivado desde el original el 2 de julio de 2015 . Consultado el 3 de julio de 2015 .
- ^ a b Pauly, Tommy (29 de enero de 2019). "TLS 1.3 en iOS" . [email protected] (lista de correo).
- ^ a b c "Nota técnica TN2287 - Problemas de interoperabilidad de iOS 5 y TLS 1.2" . Manzana. 2011-10-14. Archivado desde el original el 7 de septiembre de 2011 . Consultado el 10 de diciembre de 2012 .
- ^ Liebowitz, Matt (13 de octubre de 2011). "Apple emite enormes parches de seguridad de software" . NBC News . Consultado el 10 de diciembre de 2012 .
- ^ Seguridad de la información MWR (2012-04-16). "Aventuras con iOS UIWebviews" . Archivado desde el original el 17 de abril de 2013 . Consultado el 10 de diciembre de 2012 ., sección "HTTPS (SSL / TLS)"
- ^ "Referencia de transporte seguro" . Archivado desde el original el 4 de junio de 2014 . Consultado el 23 de junio de 2014 .
kSSLProtocol2
está obsoleto en iOS - ^ "iPhone 3.0: Mobile Safari obtiene visualización de certificados de seguridad mejorada" . El blog de iPhone . 2009-03-31. Archivado desde el original el 3 de abril de 2009.
- ^ "Proyectos / Capacidades de agente de usuario: Safari 7 / iOS 7.1" . Laboratorios SSL de Qualys. Archivado desde el original el 13 de marzo de 2017.
- ^ schurtertom (11 de octubre de 2013). "La solicitud SOAP falla aleatoriamente en un servidor pero funciona en otro en iOS7" . Desbordamiento de pila . Consultado el 5 de enero de 2014 .
- ^ "Capacidades del agente de usuario: Safari 8 / iOS 8.1.2" . Laboratorios SSL de Qualys. Archivado desde el original el 4 de marzo de 2016 . Consultado el 7 de marzo de 2015 .
- ^ "Acerca del contenido de seguridad de iOS 8.2" . Artículo de la base de conocimientos de soporte técnico de Apple . Manzana. Archivado desde el original el 9 de marzo de 2015 . Consultado el 9 de marzo de 2015 .
- ^ "Sobre el contenido de seguridad de iOS 8.4" . Archivado desde el original el 3 de julio de 2015 . Consultado el 3 de julio de 2015 .
- ^ "SSLSocket | Desarrolladores de Android" . Archivado desde el original el 18 de marzo de 2015 . Consultado el 11 de marzo de 2015 .
- ^ a b c d "SSLSocket | Desarrolladores de Android" . Archivado desde el original el 4 de marzo de 2016 . Consultado el 17 de diciembre de 2015 .
- ^ a b "Cambios de comportamiento de Android 5.0 | Desarrolladores de Android" . Archivado desde el original el 9 de marzo de 2015 . Consultado el 11 de marzo de 2015 .
- ^ "Cambios de comportamiento de Android 8.0" . Archivado desde el original el 1 de diciembre de 2017.
- ^ Oráculo. "7093640: Habilitar TLS 1.2 del lado del cliente de forma predeterminada" . Consultado el 30 de agosto de 2018 .
- ^ Oráculo. "JEP 332: Seguridad de la capa de transporte (TLS) 1.3" . Consultado el 30 de agosto de 2018 .
- ^ Ben Smyth (2019). "TLS 1.3 para ingenieros: una exploración de la especificación TLS 1.3 y la implementación de Java de OpenJDK" . arXiv : 1904.02148 . Consultado el 29 de enero de 2021 .
- ^ "Versión 1.11.13, 2015-01-11 - Botan" . 2015-01-11. Archivado desde el original el 9 de enero de 2015 . Consultado el 16 de enero de 2015 .
- ^ "[gnutls-devel] GnuTLS 3.4.0 lanzado" . 2015-04-08. Archivado desde el original el 16 de abril de 2015 . Consultado el 16 de abril de 2015 .
- ^ "[gnutls-devel] gnutls 3.6.4" . 2018-09-24 . Consultado el 18 de mayo de 2020 .
- ^ "Notas de la versión del kit de desarrollo 8 de Java ™ SE, actualización 31" . Archivado desde el original el 21 de enero de 2015 . Consultado el 22 de enero de 2015 .
- ^ "Lanzamiento de OpenBSD 5.6" . 2014-11-01 . Consultado el 20 de enero de 2015 .
- ^ "LibreSSL 2.3.0 lanzado" . 2015-09-23 . Consultado el 24 de septiembre de 2015 .
- ^ https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.2.2-relnotes.txt
- ^ https://github.com/libressl-portable/portable/issues/228
- ^ "MatrixSSL - Noticias" . Archivado desde el original el 14 de febrero de 2015 . Consultado el 9 de noviembre de 2014 .
- ^ "mbed TLS 2.0.0 lanzado" . 2015-07-10. Archivado desde el original el 25 de septiembre de 2015 . Consultado el 14 de julio de 2015 .
- ^ "Notas de la versión NSS 3.19" . Red de desarrolladores de Mozilla . Mozilla. Archivado desde el original el 5 de junio de 2015 . Consultado el 6 de mayo de 2015 .
- ^ "Notas de la versión NSS 3.14" . Red de desarrolladores de Mozilla . Mozilla. Archivado desde el original el 17 de enero de 2013 . Consultado el 27 de octubre de 2012 .
- ^ "Notas de la versión NSS 3.15.1" . Red de desarrolladores de Mozilla . Mozilla. Archivado desde el original el 22 de septiembre de 2013 . Consultado el 10 de agosto de 2013 .
- ^ "Notas de la versión de NSS 3.39" . 2018-08-31 . Consultado el 14 de septiembre de 2018 .
- ^ "Notas de la versión de la serie OpenSSL 1.1.0" . Archivado desde el original el 25 de agosto de 2016 . Consultado el 2 de octubre de 2016 .
- ^ a b "Grandes cambios entre OpenSSL 1.0.0h y OpenSSL 1.0.1 [14 de marzo de 2012]" . 2012-03-14. Archivado desde el original el 20 de enero de 2015 . Consultado el 20 de enero de 2015 .
- ^ "Lanzamiento de OpenSSL 1.1.1" . 2018-09-11 . Consultado el 14 de septiembre de 2018 .
- ^ Conjuntos de cifrado TLS en Microsoft Windows XP y 2003 Archivado el 18 de enero de 2015 en Wayback Machine
- ^ a b SChannel Cipher Suites en Microsoft Windows Vista Archivado el 12 de enero de 2015 en Wayback Machine
- ^ a b c TLS Cipher Suites en SChannel para Windows 7, 2008R2, 8, 2012 Archivado el 19 de marzo de 2015 en Wayback Machine
- ^ "Referencia de soporte de Microsoft TLS 1.3" . Microsoft. 2020-01-30 . Consultado el 1 de enero de 2021 ."Novedades de Windows 10, versión 1909 para profesionales de TI" . Microsoft. 2020-10-03 . Consultado el 1 de enero de 2021 .
- ^ "Protocolos en TLS / SSL (Schannel SSP)" . Microsoft. 2020-12-17 . Consultado el 1 de enero de 2021 .
- ^ "[wolfssl] wolfSSL 3.6.6 lanzado" . 2015-08-20. Archivado desde el original el 17 de octubre de 2015 . Consultado el 25 de agosto de 2015 .
- ^ "Soporte de protocolo TLS 1.3" . Consultado el 15 de mayo de 2021 .
- ^ "Notas de la versión de NSS 3.24" . Red de desarrolladores de Mozilla . Mozilla. Archivado desde el original el 26 de agosto de 2016 . Consultado el 19 de junio de 2016 .
- ^ "Nota técnica TN2287: problemas de interoperabilidad de iOS 5 y TLS 1.2" . Biblioteca para desarrolladores de iOS . Apple Inc. Archivado desde el original el 3 de abril de 2015 . Consultado el 3 de mayo de 2012 .
- ^ Qualys SSL Labs - Proyectos / Capacidades de agente de usuario archivado el 19 de septiembre de 2015 en Wayback Machine.
- ^ Georgiev, Martin e Iyengar, Subodh y Jana, Suman y Anubhai, Rishita y Boneh, Dan y Shmatikov, Vitaly (2012). El código más peligroso del mundo: validar certificados SSL en software que no sea navegador. Actas de la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones (PDF) . págs. 38–49. ISBN 978-1-4503-1651-4. Archivado (PDF) desde el original el 22 de octubre de 2017.CS1 maint: varios nombres: lista de autores ( enlace )
- ^ "El uso del esquema SIPS URI en el Protocolo de inicio de sesión (SIP)" . RFC 5630 .
- ^ Joris Claessens; Valentin Dem; Danny De Cock; Bart Preneel; Joos Vandewalle (2002). "Sobre la seguridad de los sistemas bancarios electrónicos en línea de hoy" (PDF) . Computadoras y seguridad . 21 (3): 253-265. doi : 10.1016 / S0167-4048 (02) 00312-7 .
- ^ A. Freier; P. Karlton; P. Kocher (agosto de 2011). "El protocolo de capa de sockets seguros (SSL) versión 3.0" . Archivado desde el original el 15 de enero de 2012.
- ^ Lawrence, Eric (22 de octubre de 2005). "IEBlog: próximas mejoras HTTPS en Internet Explorer 7 Beta 2" . Blogs de MSDN . Archivado desde el original el 17 de abril de 2013 . Consultado el 25 de noviembre de 2007 .
- ^ "Bugzilla @ Mozilla - Error 236933 - Deshabilitar SSL2 y otros cifrados débiles" . Mozilla Corporation . Consultado el 25 de noviembre de 2007 .
- ^ " Registro de cambios de Opera 9.5 para Windows" Archivado el 26 de junio de 2009 en Wayback Machine en Opera.com : "SSL v2 deshabilitado y cifrados débiles".
- ^ " Registro de cambios de Opera 10 para Windows" Archivado el 26 de marzo de 2013 en Wayback Machine en Opera.com : "Se eliminó el soporte para SSL v2 y cifrados débiles"
- ^ Pettersen, Yngve (30 de abril de 2007). "10 años de SSL en Opera - Notas del implementador" . Opera Software . Archivado desde el original el 12 de octubre de 2007 . Consultado el 25 de noviembre de 2007 .
- ^ Instituto Nacional de Estándares y Tecnología (diciembre de 2010). "Guía de implementación para FIPS PUB 140-2 y el programa de validación del módulo criptográfico" (PDF) . Archivado desde el original (PDF) el 6 de noviembre de 2010.
- ^ "Resumen de los ataques conocidos sobre la seguridad de la capa de transporte (TLS) y el datagrama TLS (DTLS)" . RFC 7457 . Archivado desde el original el 4 de marzo de 2016.
- ^ "CVE - CVE-2009-3555" . Archivado desde el original el 4 de enero de 2016.
- ^ Eric Rescorla (5 de noviembre de 2009). "Comprensión del ataque de renegociación TLS" . Conjetura educada . Archivado desde el original el 9 de febrero de 2012 . Consultado el 27 de noviembre de 2009 .
- ^ "SSL_CTX_set_options SECURE_RENEGOTIATION" . Documentos de OpenSSL . 2010-02-25. Archivado desde el original el 26 de noviembre de 2010 . Consultado el 18 de noviembre de 2010 .
- ^ "Lanzamiento de GnuTLS 2.10.0" . Notas de la versión de GnuTLS . 2010-06-25. Archivado desde el original el 9 de febrero de 2012 . Consultado el 24 de julio de 2011 .
- ^ "Notas de la versión NSS 3.12.6" . Notas de la versión de NSS . 2010-03-03. Archivado desde el original el 6 de marzo de 2012 . Consultado el 24 de julio de 2011 .
- ^ A. Langley; N. Modadugu; B. Moeller (2 de junio de 2010). "Inicio en falso de seguridad de la capa de transporte (TLS)" . Grupo de trabajo de ingeniería de Internet . IETF. Archivado desde el original el 5 de septiembre de 2013 . Consultado el 31 de julio de 2013 .
- ^ Gruener, Wolfgang. "Inicio en falso: Google propone una Web más rápida, Chrome ya lo admite" . Archivado desde el original el 7 de octubre de 2010 . Consultado el 9 de marzo de 2011 .
- ^ Smith, Brian. "Ataques de retroceso limitado en False Start y Snap Start" . Archivado desde el original el 4 de mayo de 2011 . Consultado el 9 de marzo de 2011 .
- ^ Dimcev, Adrian. "Inicio en falso" . SSL / TLS 101 aleatorio . Archivado desde el original el 4 de mayo de 2011 . Consultado el 9 de marzo de 2011 .
- ^ Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). Un ataque de protocolo cruzado al protocolo TLS. Actas de la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones (PDF) . págs. 62–72. ISBN 978-1-4503-1651-4. Archivado (PDF) desde el original el 6 de julio de 2015.
- ^ "SMACK: Ataques de máquinas de estado" . Archivado desde el original el 12 de marzo de 2015.
- ^ Goodin, Dan (20 de mayo de 2015). "El ataque paralizante de HTTPS amenaza a decenas de miles de servidores web y de correo" . Ars Technica . Archivado desde el original el 19 de mayo de 2017.
- ^ Leyden, John (1 de marzo de 2016). "Un tercio de todos los sitios web HTTPS abiertos al ataque DROWN" . El registro . Archivado desde el original el 1 de marzo de 2016 . Consultado el 2 de marzo de 2016 .
- ^ a b "Más de 11 millones de sitios web HTTPS en peligro por un nuevo ataque de descifrado" . Ars Technica . Archivado desde el original el 1 de marzo de 2016 . Consultado el 2 de marzo de 2016 .
- ^ Thai Duong y Juliano Rizzo (13 de mayo de 2011). "Aquí vienen los ⊕ Ninjas" . Archivado desde el original el 3 de junio de 2014.
- ^ Dan Goodin (19 de septiembre de 2011). "Los piratas informáticos rompen el cifrado SSL utilizado por millones de sitios" . Archivado desde el original el 9 de febrero de 2012.
- ^ "Y Combinator comenta sobre el tema" . 2011-09-20. Archivado desde el original el 17 de abril de 2013.
- ^ "Seguridad de CBC Ciphersuites en SSL / TLS: Problemas y Contramedidas" . 2004-05-20. Archivado desde el original el 30 de junio de 2012.
- ^ Ristic, Ivan (10 de septiembre de 2013). "¿BESTIA sigue siendo una amenaza?" . Archivado desde el original el 12 de octubre de 2014 . Consultado el 8 de octubre de 2014 .
- ^ Brian Smith (30 de septiembre de 2011). "(CVE-2011-3389) Rizzo / Duong eligió ataque de texto plano (BEAST) en SSL / TLS 1.0 (facilitado por websockets -76)" .
- ^ "Vulnerabilidad en SSL / TLS podría permitir la divulgación de información (2643584)" . 2012-01-10. Archivado desde el original el 15 de agosto de 2014.
- ^ Ristic, Ivan (31 de octubre de 2013). "Apple habilitó las mitigaciones de BEAST en OS X 10.9 Mavericks" . Archivado desde el original el 12 de octubre de 2014 . Consultado el 8 de octubre de 2014 .
- ^ Dan Goodin (13 de septiembre de 2012). "La ruptura de la base de confianza de Internet permite el secuestro de sesiones HTTPS" . Ars Technica . Archivado desde el original el 1 de agosto de 2013 . Consultado el 31 de julio de 2013 .
- ^ Dennis Fisher (13 de septiembre de 2012). "CRIME Attack utiliza la relación de compresión de las solicitudes TLS como canal lateral para secuestrar sesiones seguras" . ThreatPost. Archivado desde el original el 15 de septiembre de 2012 . Consultado el 13 de septiembre de 2012 .
- ^ a b Goodin, Dan (1 de agosto de 2013). "Desaparecido en 30 segundos: nuevo ataque extrae secretos de páginas protegidas por HTTPS" . Ars Technica . Conde Nast. Archivado desde el original el 3 de agosto de 2013 . Consultado el 2 de agosto de 2013 .
- ^ Leyden, John (2 de agosto de 2013). "Ingrese al INCUMPLIMIENTO: Nuevo ataque desarrollado para leer datos web encriptados" . El registro . Archivado desde el original el 5 de agosto de 2013 . Consultado el 2 de agosto de 2013 .
- ^ P. Gutmann (septiembre de 2014). "Encrypt-then-MAC para Transport Layer Security (TLS) y Datagram Transport Layer Security (DTLS)" . Archivado desde el original el 12 de mayo de 2015.
- ^ Langley, Adam (8 de diciembre de 2014). "El CANICHE vuelve a morder" . Archivado desde el original el 8 de diciembre de 2014 . Consultado el 8 de diciembre de 2014 .
- ^ seguridad - ¿Cifras más seguras para usar con BEAST? (Explotación TLS 1.0) He leído que RC4 es inmune - Fallo del servidor
- ^ Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). "Descubrimiento y explotación de nuevos sesgos en RC4". En Alex Biryukov; Guang Gong; Douglas R. Stinson (eds.). Áreas seleccionadas en criptografía: 17º Taller Internacional, SAC 2010, Waterloo, Ontario, Canadá, 12-13 de agosto de 2010, artículos seleccionados revisados . Apuntes de conferencias en Ciencias de la Computación. 6544 . págs. 74–91. doi : 10.1007 / 978-3-642-19574-7_5 . ISBN 978-3-642-19573-0.
- ^ Green, Matthew. "Ataque de la semana: RC4 está algo roto en TLS" . Ingeniería de Criptografía . Archivado desde el original el 14 de marzo de 2013 . Consultado el 12 de marzo de 2013 .
- ^ Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering y Jacob Schuldt. "Sobre la seguridad de RC4 en TLS" . Universidad Royal Holloway de Londres. Archivado desde el original el 15 de marzo de 2013 . Consultado el 13 de marzo de 2013 .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ AlFardan, Nadhem J .; Bernstein, Daniel J .; Paterson, Kenneth G .; Poettering, Bertram; Schuldt, Jacob CN (8 de julio de 2013). "Sobre la seguridad de RC4 en TLS y WPA" (PDF) . Archivado (PDF) desde el original el 22 de septiembre de 2013 . Consultado el 2 de septiembre de 2013 . Cite journal requiere
|journal=
( ayuda ) - ^ AlFardan, Nadhem J .; Bernstein, Daniel J .; Paterson, Kenneth G .; Poettering, Bertram; Schuldt, Jacob CN (15 de agosto de 2013). Sobre la seguridad de RC4 en TLS (PDF) . 22º Simposio de Seguridad de USENIX . pag. 51. Archivado (PDF) desde el original el 22 de septiembre de 2013 . Consultado el 2 de septiembre de 2013 .
Los ataques de recuperación de texto sin formato contra RC4 en TLS son factibles aunque no realmente prácticos
- ^ Bien, Dan. "El ataque criptográfico una vez teórico contra HTTPS ahora roza la practicidad" . Ars Technical . Conde Nast. Archivado desde el original el 16 de julio de 2015 . Consultado el 16 de julio de 2015 .
- ^ "Configuraciones recomendadas de TLS del lado del servidor de seguridad de Mozilla" . Mozilla. Archivado desde el original el 3 de enero de 2015 . Consultado el 3 de enero de 2015 .
- ^ "Aviso de seguridad 2868725: Recomendación para deshabilitar RC4" . Microsoft. 2013-11-12. Archivado desde el original el 18 de noviembre de 2013 . Consultado el 4 de diciembre de 2013 .
- ^ "Finalización del soporte para el cifrado RC4 en Microsoft Edge e Internet Explorer 11" . Equipo de Microsoft Edge. 1 de septiembre de 2015. Archivado desde el original el 2 de septiembre de 2015.
- ^ Langley, Adam (1 de septiembre de 2015). "Intención de desaprobar: RC4" .
- ^ Barnes, Richard (1 de septiembre de 2015). "Intención de envío: RC4 deshabilitado por defecto en Firefox 44" . Archivado desde el original el 22 de enero de 2011.
- ^ a b John Leyden (1 de agosto de 2013). "Gmail, Outlook.com y el voto electrónico 'pwned' en el escenario en el hack de crypto-dodge" . El registro . Archivado desde el original el 1 de agosto de 2013 . Consultado el 1 de agosto de 2013 .
- ^ "Sesiones informativas de BlackHat USA" . Sombrero Negro 2013 . Archivado desde el original el 30 de julio de 2013 . Consultado el 1 de agosto de 2013 .
- ^ Smyth, Ben; Pironti, Alfredo (2013). "Truncar conexiones TLS para violar creencias en aplicaciones web" . VII Workshop de USENIX sobre Tecnologías Ofensivas . Archivado desde el original el 6 de noviembre de 2015 . Consultado el 15 de febrero de 2016 .
- ^ Bien, Dan. "Nuevo ataque pasa por alto la protección HTTPS en Mac, Windows y Linux" . Ars Technica . Conde Nast. Archivado desde el original el 27 de julio de 2016 . Consultado el 28 de julio de 2016 .
- ^ Goodin, Dan (24 de agosto de 2016). "HTTPS y OpenVPN enfrentan un nuevo ataque que puede descifrar cookies secretas" . Ars Technica . Archivado desde el original el 24 de agosto de 2016 . Consultado el 24 de agosto de 2016 .
- ^ "¿Por qué se llama el 'Error Heartbleed'?" . The Washington Post . 2014-04-09. Archivado desde el original el 9 de octubre de 2014.
- ^ "Vulnerabilidad de error Heartbleed [9 de abril de 2014]" . Grupo Comodo . Archivado desde el original el 5 de julio de 2014.
- ^ Bleichenbacher, Daniel (agosto de 2006). "Falsificación de firma RSA de Bleichenbacher basada en error de implementación" . Archivado desde el original el 16 de diciembre de 2014.
- ^ "BERserk" . Seguridad de Intel: investigación avanzada de amenazas. Septiembre de 2014. Archivado desde el original el 12 de enero de 2015.
- ^ Goodin, Dan (19 de febrero de 2015). "Las PC de Lenovo se envían con adware man-in-the-middle que rompe las conexiones HTTPS" . Ars Technica . Archivado desde el original el 12 de septiembre de 2017 . Consultado el 10 de diciembre de 2017 .
- ^ Valsorda, Filippo (20 de febrero de 2015). "La validación SSL de Komodia / Superfish está rota" . Filippo.io. Archivado desde el original el 24 de febrero de 2015.
- ^ a b Bien, Dan. "El " ataque prohibido "hace que decenas de sitios de Visa HTTPS sean vulnerables a la manipulación" . Ars Technica . Archivado desde el original el 26 de mayo de 2016 . Consultado el 26 de mayo de 2016 .
- ^ Clark Estes, Adam. "Todo lo que necesita saber sobre Cloudbleed, el último desastre de seguridad en Internet" . Gizmodo . Archivado desde el original el 25 de febrero de 2017 . Consultado el 24 de febrero de 2017 .
- ^ Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (junio de 1992). "Autenticación e intercambios de claves autenticadas" . Diseños, Códigos y Criptografía . 2 (2): 107–125. CiteSeerX 10.1.1.59.6682 . doi : 10.1007 / BF00124891 . S2CID 7356608 . Archivado desde el original el 13 de marzo de 2008 . Consultado el 11 de febrero de 2008 .
- ^ Discusión sobre la lista de correo de TLS en octubre de 2007 Archivado el 22 de septiembre de 2013 en Wayback Machine.
- ^ "Protección de datos a largo plazo con sigilo hacia adelante" . Archivado desde el original el 6 de mayo de 2013 . Consultado el 5 de noviembre de 2012 .
- ^ Bernat, Vincent. "SSL / TLS y Perfect Forward Secrecy" . Archivado desde el original el 27 de agosto de 2012 . Consultado el 5 de noviembre de 2012 .
- ^ "Laboratorios SSL: implementación de la confidencialidad hacia adelante" . Qualys.com. 2013-06-25. Archivado desde el original el 26 de junio de 2013 . Consultado el 10 de julio de 2013 .
- ^ Ristic, Ivan (5 de agosto de 2013). "Laboratorios SSL: implementación de la confidencialidad hacia adelante" . Qualsys. Archivado desde el original el 20 de septiembre de 2013 . Consultado el 31 de agosto de 2013 .
- ^ a b Langley, Adam (27 de junio de 2013). "Cómo arruinar el secreto de TLS hacia adelante" . imperialviolet.org . Archivado desde el original el 8 de agosto de 2013.
- ^ a b Daignière, Florent. "TLS" Secrets ": Documento técnico que presenta las implicaciones de seguridad de la implementación de tickets de sesión (RFC 5077) tal como se implementa en OpenSSL" (PDF) . Matta Consulting Limited. Archivado (PDF) desde el original el 6 de agosto de 2013 . Consultado el 7 de agosto de 2013 .
- ^ a b Daignière, Florent. "TLS" Secrets ": Lo que todos se olvidaron de decirte ..." (PDF) . Matta Consulting Limited. Archivado (PDF) desde el original el 5 de agosto de 2013 . Consultado el 7 de agosto de 2013 .
- ^ LS Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "Un estudio experimental de las implementaciones de TLS Forward Secrecy" . Computación por Internet IEEE . 18 (6): 43–51. CiteSeerX 10.1.1.663.4653 . doi : 10.1109 / MIC.2014.86 . S2CID 11264303 . Archivado desde el original el 20 de septiembre de 2015 . Consultado el 16 de octubre de 2015 .
- ^ "Protección de datos a largo plazo con sigilo hacia adelante" . Archivado desde el original el 12 de febrero de 2014 . Consultado el 7 de marzo de 2014 .
- ^ Hoffman-Andrews, Jacob. "Reenviar el secreto en Twitter" . Gorjeo. Archivado desde el original el 16 de febrero de 2014 . Consultado el 7 de marzo de 2014 .
- ^ a b c Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 de septiembre de 2017). "El impacto de seguridad de la interceptación HTTPS" . Simposio NDSS . doi : 10.14722 / ndss.2017.23456 . ISBN 978-1-891562-46-4.
- ^ a b Estos certificados son actualmente X.509 , pero RFC 6091 también especifica el uso de certificados basados en OpenPGP .
- ^ "tls: ¿diferencias entre los términos" secreto anterior al maestro "," secreto maestro "," clave privada "y" secreto compartido "?" . Intercambio de pila de criptografía . Consultado el 1 de octubre de 2020 .
- ^ Chris (18 de febrero de 2009). "vsftpd-2.1.0 lanzado - Utilizando la reanudación de la sesión TLS para la autenticación de la conexión de datos FTPS" . Scarybeastsecurity. blogspot.com. Archivado desde el original el 7 de julio de 2012 . Consultado el 17 de mayo de 2012 .
- ^ Valsorda, Filippo. "Una descripción general de TLS 1.3 y preguntas y respuestas" . El blog de Cloudflare .
- ^ Visión general certificado SSL comodín , archivada desde el original, el 06/23/2015 , recuperado 02/07/2015
- ^ Hosts virtuales SSL basados en nombre: cómo abordar el problema (PDF) , archivado (PDF) del original el 2012-08-03 , consultado el 2012-05-17
Este artículo se basa en material extraído del Diccionario gratuito de informática en línea antes del 1 de noviembre de 2008 e incorporado bajo los términos de "renovación de licencias" de la GFDL , versión 1.3 o posterior.
Otras lecturas
- Wagner, David; Schneier, Bruce (noviembre de 1996). "Análisis del Protocolo SSL 3.0" (PDF) . El Segundo Taller de USENIX sobre Procedimientos de Comercio Electrónico . Prensa USENIX. págs. 29–40.
- Eric Rescorla (2001). SSL y TLS: diseño y construcción de sistemas seguros . Estados Unidos: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
- Stephen A. Thomas (2000). Conceptos básicos de SSL y TLS para proteger la Web . Nueva York: Wiley. ISBN 978-0-471-38354-3.
- Bard, Gregory (2006). "Un desafiante pero factible ataque de texto sin formato adaptable en bloque en SSL" . Asociación Internacional para la Investigación Criptológica (136) . Consultado el 23 de septiembre de 2011 .
- Canvel, Brice. "Intercepción de contraseña en un canal SSL / TLS" . Consultado el 20 de abril de 2007 .
- Autores múltiples de IETF. "RFC de cambio para la renegociación de TLS" . Consultado el 11 de diciembre de 2009 .
- Creación de VPN con IPsec y SSL / TLS Linux Journal artículo de Rami Rosen
- Joshua Davies (2010). Implementación de SSL / TLS . Wiley. ISBN 978-0470920411.
- Polk, Tim; McKay, Kerry; Chokhani, Santosh (abril de 2014). "Directrices para la selección, configuración y uso de implementaciones de seguridad de la capa de transporte (TLS)" (PDF) . Instituto Nacional de Estándares y Tecnología. Archivado desde el original (PDF) el 8 de mayo de 2014 . Consultado el 7 de mayo de 2014 .
- Abdou, AbdelRahman; van Oorschot, Paul (agosto de 2017). "Verificación de la ubicación del servidor (SLV) y fijación de la ubicación del servidor: Aumento de la autenticación TLS" . Transacciones sobre privacidad y seguridad . ACM.
enlaces externos
Especificaciones (consulte § Estándares para enlaces SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 más antiguos)
- Protocolo de seguridad de la capa de transporte (TLS) versión 1.2RFC 5246
- Grupo de trabajo TLS de IETF (Grupo de trabajo de ingeniería de Internet)
- Intolerancia a la versión TLS
- Intolerancia a la versión TLS
- TLS 1.3 e intolerancia a la versión
- Otro
- OWASP: Hoja de referencia de protección de la capa de transporte
- Una charla sobre SSL / TLS que intenta explicar las cosas en términos que la gente pueda entender.
- Vulnerabilidad de renegociación de TLS: herramientas IETF
- Laboratorios SSL de Qualys - SSL Pulse
- Cómo generar CSR para SSL
- Cómo funciona TLS Handshake en un navegador privado