Transport Layer Security

Conjunto de protocolos de internet
Capa de aplicación
BGP DHCP (v6) DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP MÚSICA POP PTP ONC / RPC RTP RTSP ROTURA sorbo SMTP SNMP SSH Telnet TLS / SSL XMPP más...
Capa de transporte
TCP UDP DCCP SCTP RSVP más...
Capa de internet
IP IPv4 IPv6 ICMP (v6) ECN IGMP IPsec más...
Capa de enlace
ARP NDP OSPF Túneles L2TP PPP MAC Ethernet Wifi DSL RDSI FDDI más...
v t mi

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.

El protocolo TLS consta 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 [ editar ]

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 directo: 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 [ editar ]

Protocolos SSL y TLS
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 ^[8]^[9]^[10]
TLS 1.1	2006	En desuso en 2020 ^[8]^[9]^[10]
TLS 1.2	2008
TLS 1.3	2018

Sistema de red de datos seguro [ editar ]

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 [ editar ]

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 [ editar ]

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 Kochertrabajando 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 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 [ editar ]

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 fue 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 [ editar ]

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}

TLS 1.2 [ editar ]

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 . ^[24]
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 refinaron aún más en RFC 6176 en marzo de 2011, eliminando su retrocompatibilidad con SSL, de modo que las sesiones de TLS nunca negocian el uso de Secure Sockets Layer (SSL) versión 2.0.

TLS 1.3 [ editar ]

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: ^[25]

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 boletos
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
Agrega soporte para enviar múltiples respuestas OCSP
Cifra 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. ^[26] 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 ^[27] - 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 . ^[28]

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 . ^[29]

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. ^[30]^[31] El grupo TLS estaba formado por personas de Japón , Reino Unido y Mauricio a través del equipo cyberstorm.mu. ^[31] Este trabajo continuó en el IETF 101 Hackathon en Londres , ^[32] y el IETF 102 Hackathon en Montreal. ^[33]

wolfSSL permitió el uso de TLS 1.3 a partir de la versión 3.11.1, lanzada en mayo de 2017. ^[34] 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, ^[35] 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. ^[36]

En Septiembre de 2018, 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". ^[37]

Seguridad del transporte empresarial [ editar ]

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. ^[38] 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. ^[39]^[40] 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 [ editar ]

Ejemplo de un sitio web con certificado digital

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.

Autoridades de certificación [ editar ]

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, ^[41] 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. ^[42] En 2017, Symantec vendió su negocio TLS / SSL a DigiCert. ^[43] 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.^[44]

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). ^[45]^[46]

Algoritmos [ editar ]

Intercambio de claves o acuerdo de claves [ editar ]

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) ^[47] y Contraseña remota segura (TLS_SRP). ^[48]

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. . ^[49]^[50]

Intercambio / acuerdo y autenticación de claves
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 ^[51]
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) ^[52]	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 ^[53]	No	No	sí	sí	sí		Propuesto en borradores de RFC

Cifrado [ editar ]

Seguridad de cifrado contra ataques factibles conocidos públicamente
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	Estado
Cifrado en bloque con modo de operación	AES GCM ^[54]^{[n 5]}	256, 128	N / A	N / A	N / A	N / A	Seguro	Seguro	Definido para TLS 1.2 en RFC
	AES CCM ^[55]^{[n 5]}		N / A	N / A	N / A	N / A	Seguro	Seguro
	AES CBC ^{[n 6]}		N / A	Inseguro	Depende de las mitigaciones	Depende de las mitigaciones	Depende de las mitigaciones	N / A
	Camellia GCM ^[56]^{[n 5]}	256, 128	N / A	N / A	N / A	N / A	Seguro	N / A
	CBC de camelia ^[57]^{[n 6]}	256, 128	N / A	Inseguro	Depende de las mitigaciones	Depende de las mitigaciones	Depende de las mitigaciones	N / A
	ARIA GCM ^[58]^{[n 5]}	256, 128	N / A	N / A	N / A	N / A	Seguro	N / A
	ARIA CBC ^[58]^{[n 6]}	256, 128	N / A	N / A	Depende de las mitigaciones	Depende de las mitigaciones	Depende de las mitigaciones	N / A
	SEMILLA CBC ^[59]^{[n 6]}	128	N / A	Inseguro	Depende de las mitigaciones	Depende de las mitigaciones	Depende de las mitigaciones	N / A
	3DES EDE CBC ^{[n 6]}^{[n 7]}	112 ^{[n 8]}	Inseguro	Inseguro	Inseguro	Inseguro	Inseguro	N / A
	GOST 28147-89 CNT ^[53]^{[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]}	0 56	Inseguro	Inseguro	Inseguro	Inseguro	N / A	N / A	Eliminado de TLS 1.2
	DES CBC ^{[n 6]}^{[n 7]}^{[n 9]}	0 40 ^{[n 10]}	Inseguro	Inseguro	Inseguro	N / A	N / A	N / A	Prohibido en TLS 1.1 y posterior
	RC2 CBC ^{[n 6]}^{[n 7]}	0 40 ^{[n 10]}	Inseguro	Inseguro	Inseguro	N / A	N / A	N / A	Prohibido en TLS 1.1 y posterior
Cifrado de flujo	ChaCha20 - Poly1305 ^[64]^{[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
	RC4 ^{[n 11]}	0 40 ^{[n 10]}	Inseguro	Inseguro	Inseguro	N / A	N / A	N / A	Prohibido en todas las versiones de TLS por RFC 7465
Ninguno	Nulo ^{[n 12]}	-	Inseguro	Inseguro	Inseguro	Inseguro	Inseguro	N / A	Definido para TLS 1.2 en RFC

Notas

^ a b c d RFC 5746 debe implementarse 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 y no tienen en cuenta 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. ^[60]
^ Aunque la longitud de la clave de 3DES es de 168 bits, la fuerza de seguridad efectiva de 3DES es de solo 112 bits,^[61] que está por debajo del mínimo recomendado de 128 bits. ^[62]
^ a b IDEA y DES se han eliminado de TLS 1.2. ^[63]
^ a b c Los conjuntos de cifrado de fuerza de 40 bits 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 de RC4 debilitan o rompen el RC4 utilizado en SSL / TLS).
^ Solo autenticación, sin cifrado.

Integridad de datos [ editar ]

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 . ^[65] PRF basado en HMAC , o HKDF se utiliza para el protocolo de enlace TLS.

Integridad de los datos
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 ^[53]	No	No	sí	sí	sí		Propuesto en borradores de RFC
GOST R 34.11-94 ^[53]	No	No	sí	sí	sí		Propuesto en borradores de RFC

Aplicaciones y adopción [ editar ]

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 [ editar ]

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 . ^[66]

Compatibilidad con el protocolo del sitio web (abril de 2021)
Versión del protocolo	Soporte del sitio web ^[67]	Seguridad ^[67]^[68]
SSL 2.0	0,5%	Inseguro
SSL 3.0	3,4%	Inseguro ^[69]
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 [ editar ]

A partir de abril de 2016 ^[update], 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 de 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á soporte técnico y actualizaciones de 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 implementó 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 posteriores 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.

Historial de compatibilidad con TLS / SSL de los navegadores web
Navegador	Versión		Plataformas	Protocolos SSL		Protocolos TLS				Soporte de certificado			Vulnerabilidades solucionadas ^{[n 1]}						Selección de protocolo por usuario ^{[n 2]}
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]}^[70]	SHA-2 ^[71]	ECDSA ^[72]	BESTIA ^{[n 4]}	DELITO ^{[n 5]}	CANICHE (SSLv3) ^{[n 6]}	RC4 ^{[n 7]}	FREAK ^[73]^[74]	Atolladero	Selección de protocolo por usuario ^{[n 2]}
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 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	No afectado ^[79]	Vulnerable (HTTPS)	Vulnerable	Vulnerable	Vulnerable (excepto Windows)	Vulnerable	Sí ^{[n 10]}
	10-20			No ^[80]	Habilitado por defecto	sí	No	No	No	Sí (solo escritorio)	necesita SO compatible con SHA-2 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	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 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado ^[81]	Vulnerable	Vulnerable	Vulnerable (excepto Windows)	Vulnerable	Sí ^{[n 10]}
	22-29			No	Habilitado por defecto	sí	Sí ^[82]	No ^[82]^[83]^[84]^[85]	No	Sí (solo escritorio)	necesita SO compatible con SHA-2 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	Vulnerable	Vulnerable	Vulnerable (excepto Windows)	Vulnerable	Temporal ^{[n 11]}
	30–32			No	Habilitado por defecto	sí	sí	Sí ^[83]^[84]^[85]	No	Sí (solo escritorio)	necesita SO compatible con SHA-2 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	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 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	Mitigado parcialmente ^{[n 12]}	Prioridad más baja ^[88]^[89]^[90]	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 ^[72]	No afectado	Mitigado	Parcialmente mitigado	Prioridad más baja	Vulnerable (excepto Windows)	Vulnerable	Temporal ^{[n 11]}
	40			No	Desactivado por defecto ^[87]^[91]	sí	sí	sí	No	Sí (solo escritorio)	sí	necesita un sistema operativo compatible con ECC ^[72]	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 ^[72]	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 ^[72]	No afectado	Mitigado	Mitigado	Solo como alternativa ^{[n 15]}^[92]	Mitigado	Vulnerable	Sí ^{[n 14]}
	44–47			No	No ^[93]	sí	sí	sí	No	Sí (solo escritorio)	sí	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	No afectado	Solo como alternativa ^{[n 15]}	Mitigado	Mitigada ^[94]	Temporal ^{[n 11]}
	48, 49			No	No	sí	sí	sí	No	Sí (solo escritorio)	sí	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	No afectado	Desactivado por defecto ^{[n 16]}^[95]^[96]	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]}^[95]^[96]	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]}^[95]^[96]	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]}^[95]^[96]	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]}^[95]^[96]	Mitigado	Mitigado	Temporal ^{[n 11]}
	84–89	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]}^[95]^[96]	Mitigado	Mitigado	Temporal ^{[n 11]}
	91 ^[97]			No	No	No	No	sí	sí	Sí (solo escritorio)	sí	sí	No afectado	Mitigado	No afectado	Desactivado por defecto ^{[n 16]}^[95]^[96]	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–89	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 ^[98]			No	No	No	No	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+) ~~Firefox OS~~ ~~Maemo~~ ESR solo para: Windows (7+) macOS (10.9+) Linux	Habilitado de forma predeterminada ^[99]	Habilitado de forma predeterminada ^[99]	Sí ^[99]	No	No	No	No	Sí ^[71]	No	No afectado ^[100]	No afectado	Vulnerable	Vulnerable	No afectado	Vulnerable	Sí ^{[n 10]}
	2			Deshabilitado de forma predeterminada ^[99]^[101]	Habilitado por defecto	sí	No	No	No	No	sí	Sí ^[72]	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 ^[101]	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) ^[81]	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 ^[102]^[103]	No afectado	Vulnerable	Sí ^{[n 10]}
	23			No	Habilitado por defecto	sí	Deshabilitado por defecto ^[104]	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 ^[105]	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 ^[102]^[103]	No afectado	Vulnerable	Sí ^{[n 18]}
	27–33 ESR 31,0–31,2			No	Habilitado por defecto	sí	Sí ^[106]^[107]	Sí ^[108]^[107]	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 ^[109]^[110]	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 ^[113]	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]}^[114]	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 ^[113]	Sí ^{[n 18]}
	39–43			No	No ^[115]	sí	sí	sí	No	sí	sí	sí	No afectado	Mitigado	No afectado	Solo como alternativa ^{[n 15]}	No afectado	Mitigada ^[113]	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]}^[116]^[117]^[118]^[119]	No afectado	Mitigado	Sí ^{[n 18]}
	49–59 ESR 52			No	No	sí	sí	sí	Desactivado por defecto (versión en borrador) ^[120]	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 a 87 ESR 78,0 a 78,9			No	No	Desactivado de forma predeterminada ^[121]	Desactivado de forma predeterminada ^[121]	sí	sí	sí	sí	sí	No afectado	Mitigado	No afectado	Desactivado por defecto ^{[n 16]}	No afectado	Mitigado	Sí ^{[n 18]}
	ESR 78,10	88		No	No	Desactivado de forma predeterminada ^[121]	Desactivado de forma predeterminada ^[121]	sí	sí	sí	sí	sí	No afectado	Mitigado	No afectado	Desactivado por defecto ^{[n 16]}	No afectado	Mitigado	Sí ^{[n 18]}
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		~~Windows~~ ~~macOS~~ ~~Linux~~ ~~Android~~ ~~Symbian S60~~ ~~Maemo~~ ~~Windows Mobile~~	No es compatible con SSL / TLS ^[123]
	3			Sí ^[124]	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í ^[125]	No	No	No	No	No	No	No	Vulnerable	No afectado	Vulnerable	Vulnerable	Desconocido	Desconocido	Desconocido
	5			Habilitado por defecto	Habilitado por defecto	Sí ^[126]	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í ^[71]	No	Vulnerable	No afectado	Vulnerable	Vulnerable	Desconocido	Desconocido	Sí ^{[n 10]}
	8			Habilitado por defecto	Habilitado por defecto	sí	Desactivado por defecto ^[127]	No	No	No	sí	No	Vulnerable	No afectado	Vulnerable	Vulnerable	Desconocido	Desconocido	Sí ^{[n 10]}
	9			Deshabilitado por defecto ^[128]	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 ^[129]	Habilitado por defecto	sí	Desactivado por defecto	Deshabilitado por defecto ^[129]	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 ^[130]	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 ^[132]	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 ^[133]^[134]	Desconocido	Mitigada ^[132]	Sí ^{[n 10]}
	12.18			No	Desactivado por defecto	sí	Sí ^[135]	Sí ^[135]	No	Sí (solo escritorio)	sí	Sí ^[135]	Mitigado	No afectado	Mitigado	Desactivado por defecto ^{[n 16]}^[135]	Mitigada ^[135]	Mitigada ^[132]	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í ^[138]	No	No	Sí (solo escritorio)	necesita SO compatible con SHA-2 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	Vulnerable	Vulnerable	Vulnerable (excepto Windows)	Vulnerable	Temporal ^{[n 11]}
	17-19			No	Habilitado por defecto	sí	sí	Sí ^[139]	No	Sí (solo escritorio)	necesita SO compatible con SHA-2 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	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 ^[71]	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	Mitigado parcialmente ^{[n 23]}	Prioridad más baja ^[140]	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 ^[72]	No afectado	Mitigado	Mitigado ^{[n 25]}	Prioridad más baja	Vulnerable (excepto Windows)	Vulnerable	Temporal ^{[n 11]}
	27			No	Deshabilitado de forma predeterminada ^[91]	sí	sí	sí	No	Sí (solo escritorio)	sí	necesita un sistema operativo compatible con ECC ^[72]	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 ^[72]	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 ^[72]	No afectado	Mitigado	Mitigado	Solo como alternativa ^{[n 15]}^[92]	Mitigado	Mitigada ^[132]	Sí ^{[n 27]} (solo escritorio)
	31–34			No	No ^[93]	sí	sí	sí	No	Sí (solo escritorio)	sí	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	No afectado	Solo como alternativa ^{[n 15]}^[92]	Mitigado	Mitigado	Temporal ^{[n 11]}
	35, 36			No	No	sí	sí	sí	No	Sí (solo escritorio)	sí	necesita un sistema operativo compatible con ECC ^[72]	No afectado	Mitigado	No afectado	Desactivado por defecto ^{[n 16]}^[95]^[96]	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]}^[95]^[96]	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]}^[95]^[96]	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]}^[95]^[96]	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]}^[95]^[96]	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í ^[143]	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 por defecto ^[143]	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]}^[144]	No	Mitigado	No afectado	Vulnerable	Vulnerable	Vulnerable	Vulnerable	Sí ^{[n 10]}
	7 , 8		Windows XP ^{[n 30]}	Deshabilitado de forma predeterminada ^[145]	Habilitado por defecto	Sí ^[145]	No	No	No	sí	Sí ^{[n 31]}^[144]	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]}^[144]	No	Mitigado	No afectado	Vulnerable	Vulnerable	Mitigado ^[148]	Mitigado ^[149]	Sí ^{[n 10]}
	7 , 8		Servidor 2003 ^{[n 30]}	Deshabilitado de forma predeterminada ^[145]	Habilitado por defecto	Sí ^[145]	No	No	No	sí	Sí ^{[n 31]}^[144]	No	Mitigado	No afectado	Vulnerable	Vulnerable	Mitigado ^[148]	Mitigado ^[149]	Sí ^{[n 10]}
	7 , 8 , 9		Windows Vista	Desactivado por defecto	Habilitado por defecto	sí	No	No	No	sí	sí	Sí ^[72]	Mitigado	No afectado	Vulnerable	Vulnerable	Mitigado ^[148]	Mitigado ^[149]	Sí ^{[n 10]}
	7 , 8 , 9		Servidor 2008	Desactivado por defecto	Habilitado por defecto	sí	Desactivado por defecto ^[150] (KB4019276)	Desactivado por defecto ^[150] (KB4019276)	No	sí	sí	Sí ^[72]	Mitigado	No afectado	Vulnerable	Vulnerable	Mitigado ^[148]	Mitigado ^[149]	Sí ^{[n 10]}
	8 , 9 , 10		De Windows 7 / 8 Servidor 2008 R2 / 2012	Desactivado por defecto	Habilitado por defecto	sí	Deshabilitado de forma predeterminada ^[151]	Deshabilitado de forma predeterminada ^[151]	No	sí	sí	sí	Mitigado	No afectado	Vulnerable	Prioridad más baja ^[152]^{[n 32]}	Mitigado ^[148]	Mitigado ^[149]	Sí ^{[n 10]}
Internet Explorer 11 ^{[n 28]}	11		Windows 7 Server 2008 R2	Desactivado por defecto	Deshabilitado por defecto ^{[n 33]}	sí	Sí ^[154]	Sí ^[154]	No	sí	sí	sí	Mitigado	No afectado	Mitigado ^{[n 33]}	Desactivado por defecto ^[158]	Mitigado ^[148]	Mitigado ^[149]	Sí ^{[n 10]}
	11 ^[159]		Windows 8.1	Desactivado por defecto	Deshabilitado por defecto ^{[n 33]}	sí	Sí ^[154]	Sí ^[154]	No	sí	sí	sí	Mitigado	No afectado	Mitigado ^{[n 33]}	Desactivado por defecto ^{[n 16]}	Mitigado ^[148]	Mitigado ^[149]	Sí ^{[n 10]}
	11 ^[159]		Servidor 2012 Servidor 2012 R2	Desactivado por defecto	Deshabilitado por defecto ^{[n 33]}	sí	Sí ^[154]	Sí ^[154]	No	sí	sí	sí	Mitigado	No afectado	Mitigado ^{[n 33]}	Desactivado por defecto ^{[n 16]}	Mitigado ^[148]	Mitigado ^[149]	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 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 ^[160]	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]}
Internet Explorer 11 ^{[n 28]}	11		Windows 10 21H1 Servidor de Windows (SAC) 21H1	No	Desactivado por defecto	sí	sí	sí	Sí ^[161]	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 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 ^[160]	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 ^[160]	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 Server 2022 (LTSC / 21H?)	No	Desactivado por defecto	sí	sí	sí	Sí ^[161]	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	Deshabilitado de forma predeterminada ^[145]	Habilitado por defecto	sí	No ^{[ cita requerida ]}	No ^{[ cita requerida ]}	No	No ^{[ cita requerida ]}	sí	Sí ^[162]	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 ^[164]	Deshabilitado por defecto ^[164]	No	No ^{[ cita requerida ]}	sí	Sí ^[165]	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í ^[166]	Sí ^[166]	No	No ^{[ cita requerida ]}	sí	sí	Mitigado	No afectado	Vulnerable	Solo como alternativa ^{[n 15]}^[167]^[168]	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
Microsoft Edge (13-15) (basado en EdgeHTML) ^{[n 35]}	14, 15		Windows 10 Mobile 1607–1709	No ^[160]	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 ^[173]	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í ^[162]	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í ^[71]	Sí ^[72]	Vulnerable	No afectado	Vulnerable	Vulnerable	Vulnerable	Vulnerable	No
	6		OS X 10.8	No	sí	sí	No	No	No	sí	sí	Sí ^[72]	Mitigado ^{[n 37]}	No afectado	Mitigado ^{[n 38]}	Vulnerable ^{[n 38]}	Mitigado ^[179]	Vulnerable	No
	7, 9		OS X 10.9	No	sí	sí	Sí ^[180]	Sí ^[180]	No	sí	sí	sí	Mitigado ^[175]	No afectado	Mitigado ^{[n 38]}	Vulnerable ^{[n 38]}	Mitigado ^[179]	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 ^[181]^{[n 38]}	Mitigado ^[179]	Mitigado ^[182]	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) ^[183]	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
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 ^[187]	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í ^[188]	sí	desde iOS 4 ^[162]	Vulnerable	No afectado	Vulnerable	Vulnerable	Vulnerable	Vulnerable	No
	5, 6		iOS 5 , 6	No	sí	sí	Sí ^[184]	Sí ^[184]	No	sí	sí	sí	Vulnerable	No afectado	Vulnerable	Vulnerable	Vulnerable	Vulnerable	No
	7		ios 7	No	sí	sí	sí	sí	No	sí	sí	Sí ^[189]	Mitigado ^[190]	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 ^[191]^{[n 38]}	Mitigado ^[192]	Mitigado ^[193]	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) ^[183]	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
	13		iPadOS 13	No	No	sí	sí	sí	sí	sí	sí	sí	Mitigado	No afectado	No afectado	Desactivado por defecto ^{[n 16]}	Mitigado	Mitigado	No
	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
	14		iPadOS 14	No	No	sí	sí	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	EV ^{[n 3]}	SHA-2	ECDSA	BESTIA ^{[n 4]}	DELITO ^{[n 5]}	CANICHE (SSLv3) ^{[n 6]}	RC4 ^{[n 7]}	FREAK ^[73]^[74]	Atolladero	Selección de protocolo por usuario
Sistema operativo Android de Google ^[194]	Android 1.0–4.0.4			No	Habilitado por defecto	sí	No	No	No	Desconocido	Sí ^[71]	desde 3.0 ^[162]^[72]	Desconocido	Desconocido	Vulnerable	Vulnerable	Vulnerable	Vulnerable	No
	Android 4.1–4.4.4			No	Habilitado por defecto	sí	Desactivado por defecto ^[195]	Desactivado por defecto ^[195]	No	Desconocido	sí	sí	Desconocido	Desconocido	Vulnerable	Vulnerable	Vulnerable	Vulnerable	No
	Android 5.0–5.0.2			No	Habilitado por defecto	sí	Sí ^[195]^[196]	Sí ^[195]^[196]	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 ^[197]	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	Significado
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)
	~~Sistema operativo~~	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 es compatible con TLS_FALLBACK_SCSV, el ataque POODLE fallará contra esta combinación de servidor y navegador, pero las conexiones donde el servidor no es compatible con TLS_FALLBACK_SCSV y es compatible con 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.^[75]^[76]^[77]
^ Utiliza la implementación de TLS proporcionada por BoringSSL para Android, OS X y Windows^[78] 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 configurar habilitación / deshabilitación de cada protocolo mediante 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. ^{[86] El} respaldo a SSL 3.0 está deshabilitado desde la versión 39.^[87]
^ Además de TLS_FALLBACK_SCSV y deshabilitar una alternativa a SSL 3.0, SSL 3.0 en sí está deshabilitado de forma predeterminada. ^[87]
^ a b c configure la versión mínima de los protocolos de habilitación a través de chrome: // flags ^[91] (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 Todos los conjuntos de cifrado RC4 están deshabilitados de forma predeterminada.
^ 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. ^[109] Además, el respaldo a SSL 3.0 está deshabilitado desde la versión 34,^[111] y TLS_FALLBACK_SCSV está implementado desde 35.0 y ESR 31.3. ^[109]^[112]
^ 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^[122] 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 ^[131]
^ 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 ,^[136] y Opera 15 y superior se basan en Chromium 28 y superior con Blink ^[137] ).
^ TLS_FALLBACK_SCSV está implementado. ^[140]
^ SSL 3.0 está habilitado de forma predeterminada, con algunas mitigaciones contra vulnerabilidades conocidas como BEAST y POODLE implementadas. ^[131]
^ Además de TLS_FALLBACK_SCSV, se implementa la "división de registros anti-POODLE". ^[131]
^ Además de TLS_FALLBACK_SCSV y la "división de registros anti-POODLE", SSL 3.0 está deshabilitado de forma predeterminada. ^[91]
^ a b c configure la versión mínima de los protocolos de habilitación a través de opera: // flags ^[91] (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. ^[141]^[142]
^ 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. ^[146] 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 ^[147]
^ 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 reserva).^[153]
^ 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. ^[155]^[156] SSL 3.0 está deshabilitado de forma predeterminada en Internet Explorer 11 desde abril de 2015. ^[157]
^ a b c Se puede desactivar mediante la edición del registro, pero se necesitan herramientas de terceros para hacerlo. ^[163]
^ Edge (anteriormente conocido como Project Spartan) se basa en una bifurcación del motor de renderizado de Internet Explorer 11.
^ Safari utiliza la implementación del sistema operativo en Mac OS X, Windows (XP, Vista, 7)^[169] con versión desconocida,^[170] 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^{[171] El} informe SSL de Qualys simula Safari 5.1.9 conectando con TLS 1.0 no 1.1 o 1.2^[172]
^ 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. ^[174]^{[175] La} mitigación de BEAST se ha habilitado de forma predeterminada desde OS X 10.8.5 actualizado en febrero de 2014.^[176]
^ 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, ^[177]^[178] 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. ^[184]^[185]^[186]

Bibliotecas [ editar ]

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. ^[198] ) Java 11 es compatible con TLS 1.3. ^[199]^[200]
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.

Soporte de biblioteca para TLS / SSL
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 ^[201]	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 por defecto ^[202]	sí	sí	sí	Sí ^[203]
Extensión de Java Secure Socket	No ^[a]	Deshabilitado de forma predeterminada ^[204]	sí	sí	sí	sí
LibreSSL	No ^[205]	No ^[206]	sí	sí	sí	A partir de la versión 3.2.2 ^[207]^[208]
MatrixSSL	No	Desactivado de forma predeterminada en el momento de la compilación ^[209]	sí	sí	sí	sí (versión borrador)
mbed TLS (anteriormente PolarSSL)	No	Deshabilitado de forma predeterminada ^[210]	sí	sí	sí
Servicios de seguridad de red	No ^[b]	Deshabilitado de forma predeterminada ^[211]	sí	Sí ^[212]	Sí ^[213]	Sí ^[214]
OpenSSL	No ^[215]	Habilitado por defecto	sí	Sí ^[216]	Sí ^[216]	Sí ^[217]
SChannel XP / 2003 ^[218]	Deshabilitado por defecto por MSIE 7	Habilitado por defecto	Habilitado por defecto por MSIE 7	No	No	No
SChannel Vista ^[219]	Desactivado por defecto	Habilitado por defecto	sí	No	No	No
SChannel 2008 ^[219]	Desactivado por defecto	Habilitado por defecto	sí	Deshabilitado de forma predeterminada (KB4019276) ^[150]	Deshabilitado de forma predeterminada (KB4019276) ^[150]	No
SCanal 7/2008 R2 ^[220]	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 ^[220]	Desactivado por defecto	Habilitado por defecto	sí	Desactivado por defecto	Desactivado por defecto	No
SCanal 8.1 / 2012 R2, 10 v1507 y v1511 ^[220]	Desactivado por defecto	Deshabilitado por defecto en MSIE 11	sí	sí	sí	No
SCanal 10 v1607 / 2016 ^[160]	No	Desactivado por defecto	sí	sí	sí	No
SCanal 10 v1903 ^[221]	No	Desactivado por defecto	sí	sí	sí	No
SCanal 10 v21H1 ^[222]	No	Desactivado por defecto	sí	sí	sí	sí
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í	Sí ^[c]	Sí ^[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 ^[223]	sí	sí	sí	sí (versión borrador) ^[224]
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. ^[225]
^
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. ^[226]

^[227]

Un documento presentado en la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones ^[228] 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 [ editar ]

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. ^[229]

Seguridad [ editar ]

SSL 2.0 [ editar ]

SSL 2.0 tenía varias fallas: ^[230]

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 rotas. ^[231] )
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 afectados por el uso de SSL.

SSL 2.0 estaba deshabilitado de forma predeterminada, comenzando con Internet Explorer 7 , ^[232] Mozilla Firefox 2, ^[233] Opera 9.5, ^[234] 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. ^[235]^[236]

SSL 3.0 [ editar ]

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. ^[237]

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 [ editar ]

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 basada en hash diferente).
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 [ editar ]

Los ataques importantes contra TLS / SSL se enumeran a continuación.

En febrero de 2015, IETF emitió una RFC informativa ^{[238] que} resume los diversos ataques conocidos contra TLS / SSL.

Ataque de renegociación [ editar ]

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. ^[239] 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 el certificado del clientese utiliza la autenticación. 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. ^[240] 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. ^[241]^[242]^[243]

Ataques de degradación: FREAK ataque y Ataque atasco [ editar ]

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 ^[244] (adoptado y habilitado por Google Chrome ^[245] ) o Snap Start , supuestamente introdujeron ataques limitados de degradación del protocolo TLS ^[246] 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. ^[247] Documento presentado en una conferencia de la ACM sobre seguridad informática y de las 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. ^[248]

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 . ^[249] 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. ^[250] 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 [ editar ]

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. ^[251]^[252] 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. ^[252]

BESTIA ataque [ editar ]

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 ) ^[253] utilizando un subprograma 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: ^[254]^[255] un atacante que observe 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 $\oplus$ $\oplus$ $\oplus$ $\oplus$ $\oplus$ $\oplus$ $\oplus$ 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 ^[256] 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. ^[257]

Los propios Chrome y Firefox no son vulnerables a los ataques BEAST, ^[79]^[100] 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. ^[258]

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. ^[259] 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 corrigió 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. ^[260]

Ataques de CRIMEN e INCUMPLIMIENTO [ editar ]

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. ^[261]^[262] Cuando se utiliza para recuperar el contenido de las cookies de autenticación secretas , permite a un atacante realizar 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, una nueva instancia del ataque CRIME contra la compresión HTTP, denominado BREACH, fue anunciado. 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). ^[263] Todas las versiones de TLS y SSL corren el riesgo de INCUMPLIMIENTO, independientemente del algoritmo de cifrado o cifrado utilizado. ^[264]A diferencia de las instancias anteriores de CRIME, contra 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 forma realista, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para los usuarios. ^[263] 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 relleno [ editar ]

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 ^[62] 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 . ^[265] El ataque Lucky Thirteen se puede mitigar en TLS 1.2 utilizando únicamente cifrados AES_GCM; AES_CBC sigue siendo vulnerable. ^[^{cita requerida}^]

Ataque de CANICHE [ editar ]

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. ^[69]

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. ^[69]

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. ^[266]

Ataques RC4 [ editar ]

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 . ^{[267] 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. ^[68] 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 ^[268] para recuperar partes del texto plano con un gran número de cifrados TLS.^[269]^[270] El8 de julio de 2013 se dio a conocerun ataque a RC4 en TLS y SSL que requierecifrados de13 × 2²⁰ para romper RC4 y posteriormente se describió como "factible" en la presentación adjunta en unSimposio de seguridad de USENIX en agosto de 2013.^[271]^[272] 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.^[273]

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. ^[62] Mozilla y Microsoft recomiendan deshabilitar RC4 siempre que sea posible. ^[274]^[275] 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. ^{[276 ]}^[277]^[278]

Ataque de truncamiento [ editar ]

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. ^[279]

Publicado en julio de 2013, ^[280]^[281] el ataque hace que los servicios web como Gmail y Hotmail muestren una página que informa al usuario que se ha desconectado 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). ^[279]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 [ editar ]

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. ^{[282] 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 [ editar ]

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. ^[283]

Errores de implementación: Error de sangrado del corazón, Ataque BERserk, error de Cloudflare [ editar ]

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. ^[284] 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.se utiliza 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. ^[285] 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 ^[286] . 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. ^[287]

En febrero de 2015, después de que los medios informaran sobre la preinstalación oculta del adware Superfish en algunos portátiles Lenovo, ^[288] 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. ^[289] La biblioteca Komodia fue diseñada para interceptar el tráfico TLS / SSL del lado del cliente para el control parental y la vigilancia, 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. ^[290] 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. ^[290]

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. ^[291]

Encuesta de sitios web vulnerables a ataques [ editar ]

En agosto de 2019 ^[update], Trustworthy Internet Movement estimó la proporción de sitios web que son vulnerables a los ataques TLS. ^[67]

Encuesta de las vulnerabilidades TLS de los sitios web más populares
Ataques	Seguridad
Ataques	Inseguro	Depende	Seguro	Otro
Ataque de renegociación	0.3% apoya la renegociación insegura	0.1% apoya ambos	98,4% apoya la renegociación segura	1,1% sin apoyo
Ataques RC4	1.2% admite suites RC4 utilizadas con navegadores modernos	12,1% admite algunas suites RC4	86,7% sin apoyo	N / A
Compresión TLS (ataque CRIME)	0,6% vulnerable	N / A	N / A	N / A
Heartbleed	<0,1% vulnerable	N / A	N / A	N / A
Ataque de inyección ChangeCipherSpec	0,2% vulnerable y explotable	1.2% vulnerable, no explotable	96,9% no vulnerable	1,7% desconocido
Ataque POODLE contra TLS (no se incluye POODLE original contra SSL 3.0)	0.3% vulnerable y explotable	N / A	99,5% no vulnerable	0,2% desconocido
Protocolo de degradación	11,3% Defensa de degradación no compatible	N / A	71.6% Defensa de degradación apoyada	17,0% desconocido

Reenviar el secreto [ editar ]

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. ^[292] 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 las sesiones pasadas que lo hayan usado (siempre y cuando estas sesiones pasadas fueran interceptados y almacenados en el momento de la transmisión). ^[293] 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 utilizan OpenSSL . ^[294] Sin embargo, muchos clientes y servidores que admiten TLS (incluidos navegadores y servidores web) no están configurados para implementar tales restricciones. ^[295]^[296] 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. ^[297]

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. ^[298]^[299]^[300]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. ^[301]

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. ^[302] Desde noviembre de 2013, Twitter ha proporcionado confidencialidad directa con TLS a los usuarios de su servicio. ^[303] En agosto de 2019 ^[update], alrededor del 80% de los sitios web habilitados para TLS están configurados para usar conjuntos de cifrado que brindan confidencialidad directa a la mayoría de los navegadores web. ^[67]

Intercepción de TLS [ editar ]

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. ^[304]

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 . ^{[304] De} lo contrario, dicho contenido no podría detectarse siempre que esté protegido por cifrado, 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". ^[304]

Detalles del protocolo [ editar ]

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 tipo de contenidocampo 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 [ editar ]

Ilustración simplificada del protocolo de enlace TLS 1.2 completo con información de tiempo.

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 [ editar ]

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). ^[305]
- 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 ^[306] ) 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 [ editar ]

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). ^[305]
- 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 [ editar ]

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. ^[307]

Apretón de manos de TLS 1.3 [ editar ]

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. ^[308]

ID de sesión [ editar ]

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 ClientHello y ServerHelloLos mensajes 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 [ editar ]

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. ^[299] Esto significa que la información de estado (el ticket de 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-SHA256tickets 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). ^[300]^[298]

Registro TLS [ editar ]

Este es el formato general de todos los registros TLS.

Formato de registro TLS, general
Compensar	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	Tipo de contenido	N / A
Bytes 1..4	Versión heredada		Largo
Bytes 1..4	(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.

Tipos de contenido
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.

Versiones
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 ¹⁴ 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 [ editar ]

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).

Formato de registro TLS para protocolo de protocolo de enlace
Compensar	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	22	N / A
Bytes 1..4	Versión heredada		Largo
Bytes 1..4	(Importante)	(Menor)	(bits 15..8)	(bits 7..0)
Bytes 5..8	Tipo de mensaje	Longitud de los datos del mensaje de protocolo de enlace
Bytes 5..8	Tipo de mensaje	(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
Bytes n .. ( n +3)	Tipo de mensaje	(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.

Tipos de mensajes
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 [ editar ]

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).

Formato de registro TLS para el protocolo de alerta
Compensar	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	21	N / A
Bytes 1..4	Versión heredada		Largo
Bytes 1..4	(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).

Tipos de niveles de alerta
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.

Tipos de descripción de alerta
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	SSL 3.0 solamente, 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 [ editar ]

Formato de registro TLS para el protocolo ChangeCipherSpec
Compensar	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	20	N / A
Bytes 1..4	Versión heredada		Largo
Bytes 1..4	(Importante)	(Menor)	0	1
Byte 5	Tipo de protocolo CCS	N / A

Tipo de protocolo CCS: Actualmente solo 1.

Protocolo de aplicación [ editar ]

Formato de registro TLS para el 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
Bytes 1..4	(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 [ editar ]

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 . ^[309] 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. ^[310]
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 [ editar ]

Estándares primarios [ editar ]

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 [ editar ]

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 [ editar ]

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 [ editar ]

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 [ editar ]

^ 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. "Changes to PCI Compliance are Coming June 30. Is Your Ecommerce Business Ready?". Forbes. Retrieved 2018-06-20.
^ Dierks, T. & E. Rescorla (April 2006). "The Transport Layer Security (TLS) Protocol Version 1.1". RFC 4346. Archived from the original on 2017-12-24.
^ a b Polk, Tim; McKay, Terry; Chokhani, Santosh (April 2014). "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" (PDF). National Institute of Standards and Technology. p. 67. Archived from the original (PDF) on 2014-05-08. Retrieved 2014-05-07.CS1 maint: uses authors parameter (link)
^ T. Dierks, E. Rescorla (August 2008). "Finished". The Transport Layer Security (TLS) Protocol Version 1.2. sec. 7.4.9. doi:10.17487/RFC5246. RFC 5246.
^ "Differences between TLS 1.2 and TLS 1.3 (#TLS13)". WolfSSL. 18 September 2019. Archived from the original on 19 September 2019. Retrieved 18 September 2019.
^ "NSS 3.29 release notes". Mozilla Developer Network. February 2017. Archived from the original on 2017-02-22.
^ "Enable TLS 1.3 by default". Bugzilla@Mozilla. 16 October 2016. Retrieved 10 October 2017.
^ "Firefox — Notes (60.0)". Mozilla. Retrieved 2018-05-10.
^ "ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3". BlueTouch Online. 16 May 2017. Archived from the original on 12 September 2017. Retrieved 11 September 2017.
^ "TLS 1.3 IETF 100 Hackathon". Archived from the original on 2018-01-15.
^ a b IETF – Internet Engineering Task Force (2017-11-12), IETF Hackathon Presentations and Awards, retrieved 2017-11-14
^ "Hurrah! TLS 1.3 is here. Now to implement it and put it into software". Retrieved 2018-03-28.
^ IETF - Internet Engineering Task Force (2018-07-15), IETF102-HACKATHON-20180715-1400, retrieved 2018-07-18
^ "wolfSSL TLS 1.3 BETA Release Now Available". [email protected]. 11 May 2017. Retrieved 11 May 2017.
^ "TLS 1.3 PROTOCOL SUPPORT". [email protected].
^ "TLS 1.3 Draft 28 Support in wolfSSL". [email protected]. 14 June 2018. Retrieved 14 June 2018.
^ "OpenSSL 1.1.1 Is Released". Matt Caswell. 11 Sep 2018. Retrieved 19 Dec 2018.
^ Hoffman-Andrews, Jacob (2019-02-26). "ETS Isn't TLS and You Shouldn't Use It". Electronic Frontier Foundation. Retrieved 2019-02-27.
^ TS 103 523-3 - V1.1.1 - CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control ETSI
^ A finance industry group is pushing an intentionally broken cryptography "standard" called ETS Boing Boing
^ Rea, Scott (2013). "Alternatives to Certification Authorities for a Secure Web" (PDF). RSA Conference Asia Pacific. Archived (PDF) from the original on 7 October 2016. Retrieved 7 September 2016.
^ Counting SSL certificates; netcraft; May 13, 2015. Archived May 16, 2015, at the Wayback Machine
^ Raymond, Art (3 August 2017). "Lehi's DigiCert swallows web security competitor in $1 billion deal". Deseret News. Retrieved 21 May 2020.
^ "Market share trends for SSL certificate authorities". W3Techs. Retrieved 21 May 2020.
^ Law Enforcement Appliance Subverts SSL Archived 2014-03-15 at the Wayback Machine, Wired, 2010-04-03.
^ New Research Suggests That Governments May Fake SSL Certificates Archived 2016-01-04 at the Wayback Machine, EFF, 2010-03-24.
^ P. Eronen, Ed. "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)". Internet Engineering Task Force. RFC 4279. Archived from the original on 5 September 2013. Retrieved 9 September 2013.
^ D. Taylor, Ed. "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". Internet Engineering Task Force. RFC 5054. Archived from the original on December 7, 2014. Retrieved December 21, 2014.
^ Gothard, Peter. "Google updates SSL certificates to 2048-bit encryption". Computing. Incisive Media. Archived from the original on 22 September 2013. Retrieved 9 September 2013.
^ "The value of 2,048-bit encryption: Why encryption key length matters". SearchSecurity. Archived from the original on 2018-01-16. Retrieved 2017-12-18.
^ Sean Turner (September 17, 2015). "Consensus: remove DSA from TLS 1.3". Archived from the original on October 3, 2015.
^ RFC 8422
^ a b c d draft-chudov-cryptopro-cptls-04 – GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)
^ RFC 5288, 5289
^ RFC 6655, 7251
^ RFC 6367
^ RFC 5932, 6367
^ a b RFC 6209
^ RFC 4162
^ "On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN" (PDF). 2016-10-28. Archived (PDF) from the original on 2017-04-24. Retrieved 2017-06-08.
^ "NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised)" (PDF). 2007-03-08. Archived from the original (PDF) on June 6, 2014. Retrieved 2014-07-03.
^ a b c Qualys SSL Labs. "SSL/TLS Deployment Best Practices". Archived from the original on 4 July 2015. Retrieved 2 June 2015.
^ RFC 5469
^ RFC 7905
^ AEAD Ciphers
^ "Http vs https". Archived from the original on 2015-02-12. Retrieved 2015-02-12.
^ a b c d As of April 11, 2021. "SSL Pulse: Survey of the SSL Implementation of the Most Popular Websites". Qualys. Retrieved 2021-04-25.
^ a b ivanr. "RC4 in TLS is Broken: Now What?". Qualsys Security Labs. Archived from the original on 2013-08-27. Retrieved 2013-07-30.
^ a b c Bodo Möller, Thai Duong & Krzysztof Kotowicz. "This POODLE Bites: Exploiting The SSL 3.0 Fallback" (PDF). Archived (PDF) from the original on 2014-10-14. Retrieved 2014-10-15.
^ "What browsers support Extended Validation (EV) and display an EV indicator?". Symantec. Archived from the original on 2015-12-31. Retrieved 2014-07-28.
^ a b c d e f g h i j k l m n "SHA-256 Compatibility". Archived from the original on 2015-07-01. Retrieved 2015-06-12.
^ 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 "ECC Compatibility". Archived from the original on 2016-02-17. Retrieved 2015-06-13.
^ a b "Tracking the FREAK Attack". Archived from the original on 2015-03-06. Retrieved 2015-03-08.
^ a b "FREAK: Factoring RSA Export Keys". Archived from the original on 2015-03-11. Retrieved 2015-03-08.
^ Google (2012-05-29). "Dev Channel Update". Archived from the original on 2013-03-02. Retrieved 2011-06-01.
^ Google (2012-08-21). "Stable Channel Update". Archived from the original on 2012-08-25. Retrieved 2012-08-22.
^ Chromium Project (2013-05-30). "Chromium TLS 1.2 Implementation".
^ "The Chromium Project: BoringSSL". Archived from the original on 2015-09-23. Retrieved 2015-09-05.
^ a b "Chrome Stable Release". Chrome Releases. 2011-10-25. Archived from the original on 2015-02-20. Retrieved 2015-02-01.
^ "SVN revision log on Chrome 10.0.648.127 release". Archived from the original on 2014-06-19. Retrieved 2014-06-19.
^ a b "ImperialViolet – CRIME". 2012-09-22. Archived from the original on 2015-01-10. Retrieved 2014-10-18.
^ a b "SSL/TLS Overview". 2008-08-06. Archived from the original on 2013-07-03. Retrieved 2013-03-29.
^ a b "Chromium Issue 90392". 2008-08-06. Archived from the original on 2013-08-03. Retrieved 2013-06-28.
^ a b "Issue 23503030 Merge 219882". 2013-09-03. Archived from the original on 2014-02-26. Retrieved 2013-09-19.
^ a b "Issue 278370: Unable to submit client certificates over TLS 1.2 from Windows". 2013-08-23. Archived from the original on 2013-10-05. Retrieved 2013-10-03.
^ Möller, Bodo (2014-10-14). "This POODLE bites: exploiting the SSL 3.0 fallback". Google Online Security blog. Google (via Blogspot). Archived from the original on 2014-10-28. Retrieved 2014-10-28.
^ a b c "An update on SSLv3 in Chrome". Security-dev. 2014-10-31. Retrieved 2014-11-04.
^ "Stable Channel Update". Mozilla Developer Network. 2014-02-20. Archived from the original on 2014-10-24. Retrieved 2014-11-14.
^ "Changelog for Chrome 33.0.1750.117". Google. Archived from the original on 2014-01-16. Retrieved 2014-11-14.
^ "Issue 318442: Update to NSS 3.15.3 and NSPR 4.10.2". Archived from the original on 2015-03-15. Retrieved 2014-11-14.
^ a b c d e "Issue 693963003: Add minimum TLS version control to about:flags and Finch gate it. – Code Review". Archived from the original on 2015-04-16. Retrieved 2015-01-22.
^ a b c "Issue 375342: Drop RC4 Support". Archived from the original on 2015-09-12. Retrieved 2015-05-22.
^ a b "Issue 436391: Add info on end of life of SSLVersionFallbackMin & SSLVersionMin policy in documentation". Archived from the original on 2015-04-18. Retrieved 2015-04-19.
^ "Issue 490240: Increase minimum DH size to 1024 bits (tracking bug)". Archived from the original on 2015-09-12. Retrieved 2015-05-29.
^ a b c d e f g h i j k l "Intent to deprecate: RC4". Retrieved 2015-12-21.
^ a b c d e f g h i j k l "An update on SHA-1 certificates in Chrome". 2015-12-18. Archived from the original on 2015-12-18. Retrieved 2015-12-21.
^ https://support.google.com/chrome/a/answer/7679408?hl=en
^ https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#sslversionmin
^ a b c d "Security in Firefox 2". 2008-08-06. Archived from the original on 2014-07-14. Retrieved 2009-03-31.
^ a b "Attack against TLS-protected communications". Mozilla Security Blog. Mozilla. 2011-09-27. Archived from the original on 2015-03-04. Retrieved 2015-02-01.
^ a b "Introduction to SSL". MDN. Archived from the original on 2014-07-14. Retrieved 2014-06-19.
^ a b "NSS 3.15.3 Release Notes". Mozilla Developer Network. Mozilla. Archived from the original on 2014-06-05. Retrieved 2014-07-13.
^ a b "MFSA 2013-103: Miscellaneous Network Security Services (NSS) vulnerabilities". Mozilla. Mozilla. Archived from the original on 2014-07-14. Retrieved 2014-07-13.
^ "Bug 565047 – (RFC4346) Implement TLS 1.1 (RFC 4346)". Retrieved 2013-10-29.
^ "Bug 480514 – Implement support for TLS 1.2 (RFC 5246)". Retrieved 2013-10-29.
^ "Bug 733647 – Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default". Retrieved 2013-12-04.
^ a b "Firefox Notes – Desktop". 2014-02-04. Archived from the original on 2014-02-07. Retrieved 2014-02-04.
^ "Bug 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default". Retrieved 2013-11-18.
^ a b c "The POODLE Attack and the End of SSL 3.0". Mozilla blog. Mozilla. 2014-10-14. Archived from the original on 2014-10-18. Retrieved 2014-10-28.
^ "Firefox — Notes (34.0) — Mozilla". mozilla.org. 2014-12-01. Archived from the original on 2015-04-09. Retrieved 2015-04-03.
^ "Bug 1083058 – A pref to control TLS version fallback". bugzilla.mozilla.org. Retrieved 2014-11-06.
^ "Bug 1036737 – Add support for draft-ietf-tls-downgrade-scsv to Gecko/Firefox". bugzilla.mozilla.org. Retrieved 2014-10-29.
^ a b c "Bug 1166031 – Update to NSS 3.19.1". bugzilla.mozilla.org. Retrieved 2015-05-29.
^ "Bug 1088915 – Stop offering RC4 in the first handshakes". bugzilla.mozilla.org. Retrieved 2014-11-04.
^ "Firefox — Notes (39.0) — Mozilla". mozilla.org. 2015-06-30. Archived from the original on 2015-07-03. Retrieved 2015-07-03.
^ "Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year". VentureBeat. 2015-09-01. Archived from the original on 2015-09-05. Retrieved 2015-09-05.
^ "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22. Retrieved 2015-10-18.
^ "RC4 is now allowed only on whitelisted sites (Reverted)". Retrieved 2015-11-02.
^ "Firefox — Notes (44.0) — Mozilla". mozilla.org. 2016-01-26. Archived from the original on 2016-03-04. Retrieved 2016-03-09.
^ "Bug 1342082 – Disable TLS 1.3 for FF52 Release". Retrieved 2017-03-29.
^ a b https://www.mozilla.org/en-US/firefox/78.0/releasenotes/
^ "Opera 9.0 for Windows Changelog". Archived from the original on 2012-09-10.
^ "Opera 2 series". Archived from the original on 2014-10-23. Retrieved 2014-09-20.
^ "Opera 3 series". Archived from the original on 2014-10-23. Retrieved 2014-09-20.
^ "Opera 4 series". Archived from the original on 2014-10-23. Retrieved 2014-09-20.
^ "Changelog for Opera 5.x for Windows". Archived from the original on 2014-10-19. Retrieved 2014-06-19.
^ "Changelog for Opera [8] Beta 2 for Windows". Archived from the original on 2005-11-23. Retrieved 2014-06-19.
^ "Web Specifications Supported in Opera 9". Archived from the original on 2014-10-26. Retrieved 2014-06-19.
^ a b "Opera: Opera 10 beta for Windows changelog". Archived from the original on 2014-10-23. Retrieved 2014-06-19.
^ "About Opera 11.60 and new problems with some secure servers". 2011-12-11. Archived from the original on 2012-01-18.
^ a b c "Security changes in Opera 25; the poodle attacks". 2014-10-15. Archived from the original on 2014-10-20. Retrieved 2014-10-28.
^ a b c d "Unjam the logjam". 2015-06-09. Archived from the original on 2015-06-14. Retrieved 2015-06-11.
^ "Advisory: RC4 encryption protocol is vulnerable to certain brute force attacks". 2013-04-04. Archived from the original on 2015-03-15. Retrieved 2014-11-14.
^ "On the Precariousness of RC4". 2013-03-20. Archived from the original on 2013-11-12. Retrieved 2014-11-17.
^ a b c d e "Opera 12 and Opera Mail security update". 2016-02-16. Archived from the original on 2016-02-16. Retrieved 2016-02-17.
^ "Dev.Opera — Opera 14 for Android Is Out!". 2013-05-21. Archived from the original on 2015-01-30. Retrieved 2014-09-23.
^ "Dev.Opera — Introducing Opera 15 for Computers, and a Fast Release Cycle". 2013-07-02. Archived from the original on 2014-09-02. Retrieved 2014-09-23.
^ same as Chrome 26–29
^ same as Chrome 30 and later
^ a b same as Chrome 33 and later
^ Microsoft (2012-09-05). "Secure Channel". Archived from the original on 2012-08-29. Retrieved 2012-10-18.
^ Microsoft (2009-02-27). "MS-TLSP Appendix A". Archived from the original on 2013-09-27. Retrieved 2009-03-19.
^ a b "What browsers only support SSLv2?". Retrieved 2014-06-19.
^ a b c d "SHA2 and Windows – Windows PKI blog – Site Home – TechNet Blogs". 2010-09-30. Archived from the original on 2014-07-16. Retrieved 2014-07-29.
^ a b c d e "HTTPS Security Improvements in Internet Explorer 7". Archived from the original on 2013-10-10. Retrieved 2013-10-29.
^ "TLS Cipher Suites". Microsoft. Archived from the original on 2017-03-13.
^ "Archived copy". Archived from the original on 2015-03-11. Retrieved 2017-07-19.CS1 maint: archived copy as title (link)
^ a b c d e f g "Vulnerability in Schannel Could Allow Security Feature Bypass (3046049)". 2015-03-10. Archived from the original on 2017-03-13. Retrieved 2015-03-11.
^ a b c d e f g "Vulnerability in Schannel Could Allow Information Disclosure (3061518)". 2015-05-12. Archived from the original on 2016-10-08. Retrieved 2015-05-22.
^ a b c d "Update to add support for TLS 1.1 and TLS 1.2 in Windows Server 2008 SP2, Windows Embedded POSReady 2009, and Windows Embedded Standard 2009". Retrieved 2017-07-19.
^ a b "Windows 7 adds support for TLSv1.1 and TLSv1.2 – IEInternals – Site Home – MSDN Blogs". Archived from the original on 2013-12-26. Retrieved 2013-10-29.
^ Thomlinson, Matt (2014-11-11). "Hundreds of Millions of Microsoft Customers Now Benefit from Best-in-Class Encryption". Microsoft Security. Archived from the original on 2014-11-14. Retrieved 2014-11-14.
^ Microsoft security advisory: Update for disabling RC4 Archived 2015-03-11 at the Wayback Machine
^ a b c d Microsoft (2013-09-24). "IE11 Changes". Archived from the original on 2013-10-30. Retrieved 2013-11-01.
^ "February 2015 security updates for Internet Explorer". 2015-02-11. Archived from the original on 2015-02-11. Retrieved 2015-02-11.
^ "Update turns on the setting to disable SSL 3.0 fallback for protected mode sites by default in Internet Explorer 11". Archived from the original on 2015-02-14. Retrieved 2015-02-11.
^ "Vulnerability in SSL 3.0 Could Allow Information Disclosure". 2015-04-14. Archived from the original on 2016-10-08. Retrieved 2015-04-14.
^ Microsoft Edge Team (2016-08-09). "RC4 is now disabled in Microsoft Edge and Internet Explorer 11". Microsoft. Archived from the original on 2016-08-21.
^ "Internet Explorer 11 for Windows Server 2012 and Windows Embedded 8 Standard". Microsoft Support. 2019-04-16.
^ a b c d e "TLS (Schannel SSP) changes in Windows 10 and Windows Server 2016". Microsoft. 2017-03-21. Archived from the original on 2017-03-30. Retrieved 2017-03-29.
^ a b "Protocols in TLS/SSL (Schannel SSP)".
^ a b c d "What browsers work with Universal SSL". Archived from the original on 2016-03-04. Retrieved 2015-06-15.
^ "POODLE SSL vulnerability – secure your Windo… – Windows Phone 8 Development and Hacking". XDA Developers. Archived from the original on 2016-09-23.
^ a b "What TLS version is used in Windows Phone 8 for secure HTTP connections?". Microsoft. Archived from the original on 2016-03-04. Retrieved 2014-11-07.
^ "Qualys SSL Labs – Projects / User Agent Capabilities: Unknown". Archived from the original on 2017-03-01.
^ a b "Platform Security". Microsoft. 2014-06-25. Archived from the original on 2017-03-13. Retrieved 2014-11-07.
^ "Release Notes: Important Issues in Windows 8.1 Preview". Microsoft. 2013-06-24. Archived from the original on 2014-11-04. Retrieved 2014-11-04.
^ "W8.1(IE11) vs RC4". Qualys Community. Archived from the original on 2014-11-04. Retrieved 2014-11-04.
^ Adrian, Dimcev. "Common browsers/libraries/servers and the associated cipher suites implemented". TLS Cipher Suites Project. Archived from the original on 2013-04-17.
^ "Features". Safari. Apple. 2009-06-10. Archived from the original on 2013-04-17. Retrieved 2009-06-10.
^ "Curl: Patch to add TLS 1.1 and 1.2 support & replace deprecated functions in SecureTransport". Sweden: haxx.se. Archived from the original on 2017-03-01.
^ Qualys SSL Report: google.co.uk Archived 2017-03-20 at the Wayback Machine (simulation Safari 5.1.9 TLS 1.0)
^ "Apple Secures Mac OS X with Mavericks Release". eSecurity Planet. 2013-10-25. Archived from the original on 2014-07-08. Retrieved 2014-06-23.
^ Ristic, Ivan (2013-09-10). "Is BEAST Still a Threat?". Qualys. Archived from the original on 2014-10-12.
^ a b Ristić, Ivan (2013-10-31). "Apple enabled BEAST mitigations in OS X 10.9 Mavericks". Archived from the original on 2013-11-07. Retrieved 2013-11-07.
^ Ristić, Ivan (2014-02-26). "Apple finally releases patch for BEAST". Qualys. Archived from the original on 2014-07-14. Retrieved 2014-07-01.
^ "About Security Update 2014-005". Apple Support knowledge base article. Apple. Archived from the original on 2014-10-24.
^ "About the security content of iOS 8.1". Apple Support knowledge base article. Apple. Archived from the original on 2014-10-23.
^ a b c "About Security Update 2015-002". Apple Support knowledge base article. Apple. Archived from the original on 2015-03-16. Retrieved 2015-03-09.
^ a b "About the security content of OS X Mavericks v10.9". Archived from the original on 2014-07-04. Retrieved 2014-06-20.
^ "User Agent Capabilities: Safari 8 / OS X 10.10". Qualys SSL Labs. Archived from the original on 2015-09-06. Retrieved 2015-03-07.
^ "About the security content of OS X Yosemite v10.10.4 and Security Update 2015-005". Archived from the original on 2015-07-02. Retrieved 2015-07-03.
^ a b Pauly, Tommy (2019-01-29). "TLS 1.3 in iOS". [email protected] (Mailing list).
^ a b c "Technical Note TN2287 – iOS 5 and TLS 1.2 Interoperability Issues". Apple. 2011-10-14. Archived from the original on 2011-09-07. Retrieved 2012-12-10.
^ Liebowitz, Matt (2011-10-13). "Apple issues huge software security patches". NBC News. Retrieved 2012-12-10.
^ MWR Info Security (2012-04-16). "Adventures with iOS UIWebviews". Archived from the original on 2013-04-17. Retrieved 2012-12-10., section "HTTPS (SSL/TLS)"
^ "Secure Transport Reference". Archived from the original on 2014-06-04. Retrieved 2014-06-23. kSSLProtocol2 is deprecated in iOS
^ "iPhone 3.0: Mobile Safari Gets Enhanced Security Certificate Visualization". The iPhone Blog. 2009-03-31. Archived from the original on 2009-04-03.
^ "Projects / User Agent Capabilities: Safari 7 / iOS 7.1". Qualys SSL Labs. Archived from the original on 2017-03-13.
^ schurtertom (2013-10-11). "SOAP Request fails randomly on one Server but works on another on iOS7". Stack Overflow. Retrieved 2014-01-05.
^ "User Agent Capabilities: Safari 8 / iOS 8.1.2". Qualys SSL Labs. Archived from the original on 2016-03-04. Retrieved 2015-03-07.
^ "About the security content of iOS 8.2". Apple Support knowledge base article. Apple. Archived from the original on 2015-03-09. Retrieved 2015-03-09.
^ "About the security content of iOS 8.4". Archived from the original on 2015-07-03. Retrieved 2015-07-03.
^ "SSLSocket | Android Developers". Archived from the original on 2015-03-18. Retrieved 2015-03-11.
^ a b c d "SSLSocket | Android Developers". Archived from the original on 2016-03-04. Retrieved 2015-12-17.
^ a b "Android 5.0 Behavior Changes | Android Developers". Archived from the original on 2015-03-09. Retrieved 2015-03-11.
^ "Android 8.0 Behavior Changes". Archived from the original on 2017-12-01.
^ Oracle. "7093640: Enable client-side TLS 1.2 by default". Retrieved 2018-08-30.
^ Oracle. "JEP 332: Transport Layer Security (TLS) 1.3". Retrieved 2018-08-30.
^ Ben Smyth (2019). "TLS 1.3 for engineers: An exploration of the TLS 1.3 specification and OpenJDK's Java implementation". arXiv:1904.02148. Retrieved 2021-01-29.
^ "Version 1.11.13, 2015-01-11 — Botan". 2015-01-11. Archived from the original on 2015-01-09. Retrieved 2015-01-16.
^ "[gnutls-devel] GnuTLS 3.4.0 released". 2015-04-08. Archived from the original on 2015-04-16. Retrieved 2015-04-16.
^ "[gnutls-devel] gnutls 3.6.4". 2018-09-24. Retrieved 2020-05-18.
^ "Java™ SE Development Kit 8, Update 31 Release Notes". Archived from the original on 2015-01-21. Retrieved 2015-01-22.
^ "OpenBSD 5.6 Released". 2014-11-01. Retrieved 2015-01-20.
^ "LibreSSL 2.3.0 Released". 2015-09-23. Retrieved 2015-09-24.
^ https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.2.2-relnotes.txt
^ https://github.com/libressl-portable/portable/issues/228
^ "MatrixSSL – News". Archived from the original on 2015-02-14. Retrieved 2014-11-09.
^ "mbed TLS 2.0.0 released". 2015-07-10. Archived from the original on 2015-09-25. Retrieved 2015-07-14.
^ "NSS 3.19 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2015-06-05. Retrieved 2015-05-06.
^ "NSS 3.14 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2013-01-17. Retrieved 2012-10-27.
^ "NSS 3.15.1 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2013-09-22. Retrieved 2013-08-10.
^ "NSS 3.39 release notes". 2018-08-31. Retrieved 2018-09-14.
^ "OpenSSL 1.1.0 Series Release Notes". Archived from the original on 2016-08-25. Retrieved 2016-10-02.
^ a b "Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1 [14 Mar 2012]". 2012-03-14. Archived from the original on January 20, 2015. Retrieved 2015-01-20.
^ "OpenSSL 1.1.1 Is Released". 2018-09-11. Retrieved 2018-09-14.
^ TLS cipher suites in Microsoft Windows XP and 2003 Archived 2015-01-18 at the Wayback Machine
^ a b SChannel Cipher Suites in Microsoft Windows Vista Archived 2015-01-12 at the Wayback Machine
^ a b c TLS Cipher Suites in SChannel for Windows 7, 2008R2, 8, 2012 Archived 2015-03-19 at the Wayback Machine
^ "Microsoft TLS 1.3 Support Reference". Microsoft. 2020-01-30. Retrieved 2021-01-01."What's new in Windows 10, version 1909 for IT Pros". Microsoft. 2020-10-03. Retrieved 2021-01-01.
^ "Protocols in TLS/SSL (Schannel SSP)". Microsoft. 2020-12-17. Retrieved 2021-01-01.
^ "[wolfssl] wolfSSL 3.6.6 Released". 2015-08-20. Archived from the original on 2015-10-17. Retrieved 2015-08-25.
^ "[wolfssl] wolfSSL TLS1.3 support". 2017-02-13. Retrieved 2017-02-13.
^ "NSS 3.24 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2016-08-26. Retrieved 2016-06-19.
^ "Technical Note TN2287: iOS 5 and TLS 1.2 Interoperability Issues". iOS Developer Library. Apple Inc. Archived from the original on 2015-04-03. Retrieved 2012-05-03.
^ Qualys SSL Labs – Projects / User Agent Capabilities Archived 2015-09-19 at the Wayback Machine
^ Georgiev, Martin and Iyengar, Subodh and Jana, Suman and Anubhai, Rishita and Boneh, Dan and Shmatikov, Vitaly (2012). The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). pp. 38–49. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2017-10-22.CS1 maint: multiple names: authors list (link)
^ "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)". RFC 5630.
^ Joris Claessens; Valentin Dem; Danny De Cock; Bart Preneel; Joos Vandewalle (2002). "On the Security of Today's Online Electronic Banking Systems" (PDF). Computers & Security. 21 (3): 253–265. doi:10.1016/S0167-4048(02)00312-7.
^ A. Freier; P. Karlton; P. Kocher (August 2011). "The Secure Sockets Layer (SSL) Protocol Version 3.0". Archived from the original on 2012-01-15.
^ Lawrence, Eric (2005-10-22). "IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2". MSDN Blogs. Archived from the original on 2013-04-17. Retrieved 2007-11-25.
^ "Bugzilla@Mozilla — Bug 236933 – Disable SSL2 and other weak ciphers". Mozilla Corporation. Retrieved 2007-11-25.
^ "Opera 9.5 for Windows Changelog" Archived 2009-06-26 at the Wayback Machine at Opera.com: "Disabled SSL v2 and weak ciphers."
^ "Opera 10 for Windows changelog" Archived 2013-03-26 at the Wayback Machine at Opera.com: "Removed support for SSL v2 and weak ciphers"
^ Pettersen, Yngve (2007-04-30). "10 years of SSL in Opera — Implementer's notes". Opera Software. Archived from the original on October 12, 2007. Retrieved 2007-11-25.
^ National Institute of Standards and Technology (December 2010). "Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program" (PDF). Archived from the original (PDF) on November 6, 2010.
^ "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)". RFC 7457. Archived from the original on 2016-03-04.
^ "CVE – CVE-2009-3555". Archived from the original on 2016-01-04.
^ Eric Rescorla (2009-11-05). "Understanding the TLS Renegotiation Attack". Educated Guesswork. Archived from the original on 2012-02-09. Retrieved 2009-11-27.
^ "SSL_CTX_set_options SECURE_RENEGOTIATION". OpenSSL Docs. 2010-02-25. Archived from the original on 2010-11-26. Retrieved 2010-11-18.
^ "GnuTLS 2.10.0 released". GnuTLS release notes. 2010-06-25. Archived from the original on 2012-02-09. Retrieved 2011-07-24.
^ "NSS 3.12.6 release notes". NSS release notes. 2010-03-03. Archived from the original on March 6, 2012. Retrieved 2011-07-24.
^ A. Langley; N. Modadugu; B. Moeller (2010-06-02). "Transport Layer Security (TLS) False Start". Internet Engineering Task Force. IETF. Archived from the original on 2013-09-05. Retrieved 2013-07-31.
^ Gruener, Wolfgang. "False Start: Google Proposes Faster Web, Chrome Supports It Already". Archived from the original on 2010-10-07. Retrieved 2011-03-09.
^ Smith, Brian. "Limited rollback attacks in False Start and Snap Start". Archived from the original on 2011-05-04. Retrieved 2011-03-09.
^ Dimcev, Adrian. "False Start". Random SSL/TLS 101. Archived from the original on 2011-05-04. Retrieved 2011-03-09.
^ Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). pp. 62–72. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2015-07-06.
^ "SMACK: State Machine AttaCKs". Archived from the original on 2015-03-12.
^ Goodin, Dan (2015-05-20). "HTTPS-crippling attack threatens tens of thousands of Web and mail servers". Ars Technica. Archived from the original on 2017-05-19.
^ Leyden, John (1 March 2016). "One-third of all HTTPS websites open to DROWN attack". The Register. Archived from the original on 1 March 2016. Retrieved 2016-03-02.
^ a b "More than 11 million HTTPS websites imperiled by new decryption attack". Ars Technica. Archived from the original on 2016-03-01. Retrieved 2016-03-02.
^ Thai Duong & Juliano Rizzo (2011-05-13). "Here Come The ⊕ Ninjas". Archived from the original on 2014-06-03.
^ Dan Goodin (2011-09-19). "Hackers break SSL encryption used by millions of sites". Archived from the original on 2012-02-09.
^ "Y Combinator comments on the issue". 2011-09-20. Archived from the original on 2013-04-17.
^ "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures". 2004-05-20. Archived from the original on 2012-06-30.
^ Ristic, Ivan (Sep 10, 2013). "Is BEAST Still a Threat?". Archived from the original on 12 October 2014. Retrieved 8 October 2014.
^ Brian Smith (2011-09-30). "(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)".
^ "Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)". 2012-01-10. Archived from the original on 2014-08-15.
^ Ristic, Ivan (Oct 31, 2013). "Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks". Archived from the original on 12 October 2014. Retrieved 8 October 2014.
^ Dan Goodin (2012-09-13). "Crack in Internet's foundation of trust allows HTTPS session hijacking". Ars Technica. Archived from the original on 2013-08-01. Retrieved 2013-07-31.
^ Dennis Fisher (September 13, 2012). "CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions". ThreatPost. Archived from the original on September 15, 2012. Retrieved 2012-09-13.
^ a b Goodin, Dan (1 August 2013). "Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages". Ars Technica. Condé Nast. Archived from the original on 3 August 2013. Retrieved 2 August 2013.
^ Leyden, John (2 August 2013). "Step into the BREACH: New attack developed to read encrypted web data". The Register. Archived from the original on 5 August 2013. Retrieved 2 August 2013.
^ P. Gutmann (September 2014). "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". Archived from the original on 2015-05-12.
^ Langley, Adam (December 8, 2014). "The POODLE bites again". Archived from the original on December 8, 2014. Retrieved 2014-12-08.
^ security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault
^ Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). "Discovery and Exploitation of New Biases in RC4". In Alex Biryukov; Guang Gong; Douglas R. Stinson (eds.). Selected Areas in Cryptography: 17th International Workshop, SAC 2010, Waterloo, Ontario, Canada, August 12-13, 2010, Revised Selected Papers. Lecture Notes in Computer Science. 6544. pp. 74–91. doi:10.1007/978-3-642-19574-7_5. ISBN 978-3-642-19573-0.
^ Green, Matthew. "Attack of the week: RC4 is kind of broken in TLS". Cryptography Engineering. Archived from the original on March 14, 2013. Retrieved March 12, 2013.
^ Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt. "On the Security of RC4 in TLS". Royal Holloway University of London. Archived from the original on March 15, 2013. Retrieved March 13, 2013.CS1 maint: multiple names: authors list (link)
^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 July 2013). "On the Security of RC4 in TLS and WPA" (PDF). Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013. Cite journal requires |journal= (help)
^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 August 2013). On the Security of RC4 in TLS (PDF). 22nd USENIX Security Symposium. p. 51. Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013. Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical
^ Goodin, Dan. "Once-theoretical crypto attack against HTTPS now verges on practicality". Ars Technical. Conde Nast. Archived from the original on 16 July 2015. Retrieved 16 July 2015.
^ "Mozilla Security Server Side TLS Recommended Configurations". Mozilla. Archived from the original on 2015-01-03. Retrieved 2015-01-03.
^ "Security Advisory 2868725: Recommendation to disable RC4". Microsoft. 2013-11-12. Archived from the original on 2013-11-18. Retrieved 2013-12-04.
^ "Ending support for the RC4 cipher in Microsoft Edge and Internet Explorer 11". Microsoft Edge Team. September 1, 2015. Archived from the original on September 2, 2015.
^ Langley, Adam (Sep 1, 2015). "Intent to deprecate: RC4".
^ Barnes, Richard (Sep 1, 2015). "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22.
^ a b John Leyden (1 August 2013). "Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack". The Register. Archived from the original on 1 August 2013. Retrieved 1 August 2013.
^ "BlackHat USA Briefings". Black Hat 2013. Archived from the original on 30 July 2013. Retrieved 1 August 2013.
^ Smyth, Ben; Pironti, Alfredo (2013). "Truncating TLS Connections to Violate Beliefs in Web Applications". 7th USENIX Workshop on Offensive Technologies. Archived from the original on 6 November 2015. Retrieved 15 February 2016.
^ Goodin, Dan. "New attack bypasses HTTPS protection on Macs, Windows, and Linux". Ars Technica. Condé Nast. Archived from the original on 27 July 2016. Retrieved 28 July 2016.
^ Goodin, Dan (August 24, 2016). "HTTPS and OpenVPN face new attack that can decrypt secret cookies". Ars Technica. Archived from the original on August 24, 2016. Retrieved August 24, 2016.
^ "Why is it called the 'Heartbleed Bug'?". The Washington Post. 2014-04-09. Archived from the original on 2014-10-09.
^ "Heartbleed Bug vulnerability [9 April 2014]". Comodo Group. Archived from the original on 5 July 2014.
^ Bleichenbacher, Daniel (August 2006). "Bleichenbacher's RSA signature forgery based on implementation error". Archived from the original on 2014-12-16.
^ "BERserk". Intel Security: Advanced Threat Research. September 2014. Archived from the original on 2015-01-12.
^ Goodin, Dan (February 19, 2015). "Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections". Ars Technica. Archived from the original on September 12, 2017. Retrieved December 10, 2017.
^ Valsorda, Filippo (2015-02-20). "Komodia/Superfish SSL validation is broken". Filippo.io. Archived from the original on 2015-02-24.
^ a b Goodin, Dan. ""Forbidden attack" makes dozens of HTTPS Visa sites vulnerable to tampering". Ars Technica. Archived from the original on 26 May 2016. Retrieved 26 May 2016.
^ Clark Estes, Adam. "Everything You Need to Know About Cloudbleed, the Latest Internet Security Disaster". Gizmodo. Archived from the original on 2017-02-25. Retrieved 2017-02-24.
^ Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (June 1992). "Authentication and Authenticated Key Exchanges". Designs, Codes and Cryptography. 2 (2): 107–125. CiteSeerX 10.1.1.59.6682. doi:10.1007/BF00124891. S2CID 7356608. Archived from the original on 2008-03-13. Retrieved 2008-02-11.
^ Discussion on the TLS mailing list in October 2007 Archived 2013-09-22 at the Wayback Machine
^ "Protecting data for the long term with forward secrecy". Archived from the original on 2013-05-06. Retrieved 2012-11-05.
^ Bernat, Vincent. "SSL/TLS & Perfect Forward Secrecy". Archived from the original on 2012-08-27. Retrieved 2012-11-05.
^ "SSL Labs: Deploying Forward Secrecy". Qualys.com. 2013-06-25. Archived from the original on 2013-06-26. Retrieved 2013-07-10.
^ Ristic, Ivan (2013-08-05). "SSL Labs: Deploying Forward Secrecy". Qualsys. Archived from the original on 2013-09-20. Retrieved 2013-08-31.
^ a b Langley, Adam (27 June 2013). "How to botch TLS forward secrecy". imperialviolet.org. Archived from the original on 8 August 2013.
^ a b Daignière, Florent. "TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL" (PDF). Matta Consulting Limited. Archived (PDF) from the original on 6 August 2013. Retrieved 7 August 2013.
^ a b Daignière, Florent. "TLS "Secrets": What everyone forgot to tell you..." (PDF). Matta Consulting Limited. Archived (PDF) from the original on 5 August 2013. Retrieved 7 August 2013.
^ L.S. Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "An Experimental Study of TLS Forward Secrecy Deployments". IEEE Internet Computing. 18 (6): 43–51. CiteSeerX 10.1.1.663.4653. doi:10.1109/MIC.2014.86. S2CID 11264303. Archived from the original on 20 September 2015. Retrieved 16 October 2015.
^ "Protecting data for the long term with forward secrecy". Archived from the original on 2014-02-12. Retrieved 2014-03-07.
^ Hoffman-Andrews, Jacob. "Forward Secrecy at Twitter". Twitter. Archived from the original on 2014-02-16. Retrieved 2014-03-07.
^ a b c Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 September 2017). "The Security Impact of HTTPS Interception". NDSS Symposium. doi:10.14722/ndss.2017.23456. ISBN 978-1-891562-46-4.
^ a b These certificates are currently X.509, but RFC 6091 also specifies the use of OpenPGP-based certificates.
^ "tls - Differences between the terms "pre-master secret", "master secret", "private key", and "shared secret"?". Cryptography Stack Exchange. Retrieved 2020-10-01.
^ Chris (2009-02-18). "vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication". Scarybeastsecurity. blogspot.com. Archived from the original on 2012-07-07. Retrieved 2012-05-17.
^ Valsorda, Filippo. "An overview of TLS 1.3 and Q&A". The Cloudflare Blog.
^ Wildcard SSL Certificate overview, archived from the original on 2015-06-23, retrieved 2015-07-02
^ Named-based SSL virtual hosts: how to tackle the problem (PDF), archived (PDF) from the original on 2012-08-03, retrieved 2012-05-17

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

External links[edit]

Wikimedia Commons has media related to SSL and TLS.

Specifications (see § Standards for older SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 links)

The Transport Layer Security (TLS) Protocol Version 1.2 RFC 5246
IETF (Internet Engineering Task Force) TLS Workgroup

TLS version intolerance

TLS version intolerance
TLS 1.3 and Version Intolerance

Other

OWASP: Transport Layer Protection Cheat Sheet
A talk on SSL/TLS that tries to explain things in terms that people might understand.
TLS Renegotiation Vulnerability – IETF Tools
Qualys SSL Labs – SSL Pulse
How to Generate CSR for SSL
How TLS Handshake works in private browser

[rfc5746-54] RFC 5746 debe implementarse para corregir una falla de renegociación que de otra manera rompería este protocolo.

[renegotiation-55] 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 y no tienen en cuenta la infracción que esto provoca.

[BEAST-56] 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 .

[POODLEciphertable-57] 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 .

[aead-59] Los cifrados AEAD (como GCM y CCM ) solo se pueden usar en TLS 1.2 o posterior.

[Lucky13-61] 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.

[Sweet32-67] El ataque Sweet32 rompe los cifrados de bloque con un tamaño de bloque de 64 bits. ^[60]

[3des-70] Aunque la longitud de la clave de 3DES es de 168 bits, la fuerza de seguridad efectiva de 3DES es de solo 112 bits,^[61] que está por debajo del mínimo recomendado de 128 bits. ^[62]

[removal_from_tls1.2-72] IDEA y DES se han eliminado de TLS 1.2. ^[63]

[EXPORT-73] Los conjuntos de cifrado de fuerza de 40 bits 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.

[RC4-75] ^ El uso de RC4 en todas las versiones de TLS está prohibido por RFC 7465 (porque los ataques de RC4 debilitan o rompen el RC4 utilizado en SSL / TLS).

[76] Solo autenticación, sin cifrado.

[ciphers-82] ver § Tabla de cifrado arriba

[mitigations-83] ver § Navegadores web y § Ataques contra las secciones TLS / SSL

[note-sec-84] ¿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 ).

[note-poodle-85] 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).

[note-evssl-86] Si EV SSL y DV SSL (SSL normal) se pueden distinguir mediante indicadores (icono de candado verde, barra de direcciones verde, etc.) o no.

[note-BEASTmitigation-90] . ej. División de registros 1 / n-1.

[note-CRIMEmitigation-91] . ej. Deshabilitar la compresión de encabezado en HTTPS / SPDY.

[note-POODLEmitigation-92] 
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 es compatible con TLS_FALLBACK_SCSV, el ataque POODLE fallará contra esta combinación de servidor y navegador, pero las conexiones donde el servidor no es compatible con TLS_FALLBACK_SCSV y es compatible con 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á.

[21] 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.

[22] 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 es compatible con TLS_FALLBACK_SCSV, el ataque POODLE fallará contra esta combinación de servidor y navegador, pero las conexiones donde el servidor no es compatible con TLS_FALLBACK_SCSV y es compatible con 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.

[23] Al deshabilitar SSL 3.0 manualmente, el ataque POODLE fallará.

[note-RC4mitigation-93] 
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.

[25] Mitigación completa; deshabilitar conjuntos de cifrado con RC4.

[26] Mitigaciones parciales para mantener la compatibilidad con sistemas antiguos; estableciendo la prioridad de RC4 a menor.

[note-a-99] 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.^[75]^[76]^[77]

[note-b-101] Utiliza la implementación de TLS proporcionada por BoringSSL para Android, OS X y Windows^[78] o por NSS para Linux. Google está cambiando la biblioteca TLS utilizada en Chrome a BoringSSL de NSS por completo.

[viasetting-103] ^ 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 configurar habilitación / deshabilitación de cada protocolo mediante configuración / opción (el nombre del menú depende de los navegadores)

[viacommandline-110] ^ 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

[note-Chrome33-POODLE-113] TLS_FALLBACK_SCSV está implementado. ^{[86] El} respaldo a SSL 3.0 está deshabilitado desde la versión 39.^[87]

[note-Chrome40-POODLE-118] Además de TLS_FALLBACK_SCSV y deshabilitar una alternativa a SSL 3.0, SSL 3.0 en sí está deshabilitado de forma predeterminada. ^[87]

[chromeflags-119] ure la versión mínima de los protocolos de habilitación a través de chrome: // flags ^[91] (la versión máxima se puede configurar con la opción de línea de comandos)

[RC4fallback-120] ^ 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.

[RC4-disabled-124] ^ 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 Todos los conjuntos de cifrado RC4 están deshabilitados de forma predeterminada.

[note-c-129] 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.

[aboutconfig-136] ^ 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

[Fx-POODLE-145] SSL 3.0 en sí está deshabilitado de forma predeterminada. ^[109] Además, el respaldo a SSL 3.0 está deshabilitado desde la versión 34,^[111] y TLS_FALLBACK_SCSV está implementado desde 35.0 y ESR 31.3. ^[109]^[112]

[note-e-156] 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^[122] que habilitó TLS 1.1 de forma predeterminada).

[note-Opera12-POODLE-165] SSL 3.0 está deshabilitado de forma remota de forma predeterminada desde el 15 de octubre de 2014 ^[131]

[note-f-173] ^ 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 ,^[136] y Opera 15 y superior se basan en Chromium 28 y superior con Blink ^[137] ).

[note-Opera20-POODLE-177] TLS_FALLBACK_SCSV está implementado. ^[140]

[Opera25-SSL3.0-178] SSL 3.0 está habilitado de forma predeterminada, con algunas mitigaciones contra vulnerabilidades conocidas como BEAST y POODLE implementadas. ^[131]

[note-opera25-179] Además de TLS_FALLBACK_SCSV, se implementa la "división de registros anti-POODLE". ^[131]

[note-opera27-180] Además de TLS_FALLBACK_SCSV y la "división de registros anti-POODLE", SSL 3.0 está deshabilitado de forma predeterminada. ^[91]

[operaflags-181] ure la versión mínima de los protocolos de habilitación a través de opera: // flags ^[91] (la versión máxima se puede configurar con la opción de línea de comandos)

[note-d-184] 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. ^[141]^[142]

[note-oldieonnt-185] 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

[note-k-186] Windows XP, así como Server 2003 y versiones anteriores, solo admiten cifrados débiles como 3DES y RC4 listos para usar. ^[146] 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 ^[147]

[Win2003SHA2-188] MS13-095 o MS14-049 para 2003 y XP-64 o SP3 para XP (32 bits)

[RC4fallbackWin7-199] 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 reserva).^[153]

[ie11_ssl3-200] El respaldo a SSL 3.0 son los sitios bloqueados de forma predeterminada en Internet Explorer 11 para el modo protegido. ^[155]^[156] SSL 3.0 está deshabilitado de forma predeterminada en Internet Explorer 11 desde abril de 2015. ^[157]

[viaregistry-211] Se puede desactivar mediante la edición del registro, pero se necesitan herramientas de terceros para hacerlo. ^[163]

[Edge_engine-217] Edge (anteriormente conocido como Project Spartan) se basa en una bifurcación del motor de renderizado de Internet Explorer 11.

[note-g-222] Safari utiliza la implementación del sistema operativo en Mac OS X, Windows (XP, Vista, 7)^[169] con versión desconocida,^[170] 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^{[171] El} informe SSL de Qualys simula Safari 5.1.9 conectando con TLS 1.0 no 1.1 o 1.2^[172]

[note-i-227] 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. ^[174]^{[175] La} mitigación de BEAST se ha habilitado de forma predeterminada desde OS X 10.8.5 actualizado en febrero de 2014.^[176]

[note-safari-poodle-230] Debido a que Apple eliminó el soporte para todos los protocolos CBC en SSL 3.0 para mitigar POODLE, ^[177]^[178] esto deja solo RC4, que también está completamente roto por los ataques RC4 en SSL 3.0.

[note-h-239] 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. ^[184]^[185]^[186]

[cnote_a_grp_protocollibrary-table] 
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.

[cnote_b_grp_protocolsupport] 
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. ^[225]

[cnote_c_grp_protocollibrary-table] 
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. ^[226]

[1] Lawrence, Scott; Khare, Rohit. "Actualización a TLS dentro de HTTP / 1.1" . tools.ietf.org . Consultado el 15 de diciembre de 2018 .

[2] " SSL / TLS en detalle archivado el 6 de febrero de 2015 en la Wayback Machine ". Microsoft TechNet . Actualizado el 30 de julio de 2003.

[ccnp-3] Hooper, Howard (2012). CCNP Security VPN 642-648 Official Cert Guide (2 ed.). Prensa de Cisco. pag. 22. ISBN 9780132966382.

[stackex_layer-4] Spott, Andrew; Puerro, tom; et al. "¿Qué capa es TLS?" . Intercambio de pilas de seguridad de la información .

[rfc_intro-5] 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 .

[RFC8446-6] E. Rescorla (agosto de 2008). "El Protocolo de Seguridad de la Capa de Transporte (TLS) Versión 1.3" .

[RFC5246-7] 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.

[:2-8] 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 .

[:3-9] "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 .

[:4-10] "TLS 1.0 y TLS 1.1 - Estado de la plataforma Chrome" . chromestatus.com . Consultado el 10 de marzo de 2020 .

[11] ttps://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/

[Woo94-12] 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-13] 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-14] 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 .

[Oppliger-15] 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.

[16] "EL PROTOCOLO SSL" . Netscape Corporation. 2007. Archivado desde el original el 14 de junio de 1997.

[17] Rescorla 2001

[Poodle-18] "CANICHE: vulnerabilidad SSLv3 (CVE-2014-3566)" . Archivado desde el original el 5 de diciembre de 2014 . Consultado el 21 de octubre de 2014 .

[19] "Normas de seguridad y cambios de nombre en las guerras de navegadores" . Consultado el 29 de febrero de 2020 .

[20] 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 .

[21] Company, Newtek - Your Business Solutions. "Changes to PCI Compliance are Coming June 30. Is Your Ecommerce Business Ready?". Forbes. Retrieved 2018-06-20.

[22] Dierks, T. & E. Rescorla (April 2006). "The Transport Layer Security (TLS) Protocol Version 1.1". RFC 4346. Archived from the original on 2017-12-24.

[urlnvlpubs.nist.gov-23] Polk, Tim; McKay, Terry; Chokhani, Santosh (April 2014). "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" (PDF). National Institute of Standards and Technology. p. 67. Archived from the original (PDF) on 2014-05-08. Retrieved 2014-05-07.CS1 maint: uses authors parameter (link)

[24] T. Dierks, E. Rescorla (August 2008). "Finished". The Transport Layer Security (TLS) Protocol Version 1.2. sec. 7.4.9. doi:10.17487/RFC5246. RFC 5246.

[WolfSSL,_2019-25] "Differences between TLS 1.2 and TLS 1.3 (#TLS13)". WolfSSL. 18 September 2019. Archived from the original on 19 September 2019. Retrieved 18 September 2019.

[NSS-3.29-26] "NSS 3.29 release notes". Mozilla Developer Network. February 2017. Archived from the original on 2017-02-22.

[27] "Enable TLS 1.3 by default". Bugzilla@Mozilla. 16 October 2016. Retrieved 10 October 2017.

[28] "Firefox — Notes (60.0)". Mozilla. Retrieved 2018-05-10.

[29] "ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3". BlueTouch Online. 16 May 2017. Archived from the original on 12 September 2017. Retrieved 11 September 2017.

[30] "TLS 1.3 IETF 100 Hackathon". Archived from the original on 2018-01-15.

[:1-31] IETF – Internet Engineering Task Force (2017-11-12), IETF Hackathon Presentations and Awards, retrieved 2017-11-14

[32] "Hurrah! TLS 1.3 is here. Now to implement it and put it into software". Retrieved 2018-03-28.

[33] IETF - Internet Engineering Task Force (2018-07-15), IETF102-HACKATHON-20180715-1400, retrieved 2018-07-18

[34] "wolfSSL TLS 1.3 BETA Release Now Available". [email protected]. 11 May 2017. Retrieved 11 May 2017.

[35] "TLS 1.3 PROTOCOL SUPPORT". [email protected].

[36] "TLS 1.3 Draft 28 Support in wolfSSL". [email protected]. 14 June 2018. Retrieved 14 June 2018.

[37] "OpenSSL 1.1.1 Is Released". Matt Caswell. 11 Sep 2018. Retrieved 19 Dec 2018.

[38] Hoffman-Andrews, Jacob (2019-02-26). "ETS Isn't TLS and You Shouldn't Use It". Electronic Frontier Foundation. Retrieved 2019-02-27.

[39] TS 103 523-3 - V1.1.1 - CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control ETSI

[40] A finance industry group is pushing an intentionally broken cryptography "standard" called ETS Boing Boing

[41] Rea, Scott (2013). "Alternatives to Certification Authorities for a Secure Web" (PDF). RSA Conference Asia Pacific. Archived (PDF) from the original on 7 October 2016. Retrieved 7 September 2016.

[42] Counting SSL certificates; netcraft; May 13, 2015. Archived May 16, 2015, at the Wayback Machine

[43] Raymond, Art (3 August 2017). "Lehi's DigiCert swallows web security competitor in $1 billion deal". Deseret News. Retrieved 21 May 2020.

[44] "Market share trends for SSL certificate authorities". W3Techs. Retrieved 21 May 2020.

[45] Law Enforcement Appliance Subverts SSL Archived 2014-03-15 at the Wayback Machine, Wired, 2010-04-03.

[46] New Research Suggests That Governments May Fake SSL Certificates Archived 2016-01-04 at the Wayback Machine, EFF, 2010-03-24.

[RFC4279-47] P. Eronen, Ed. "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)". Internet Engineering Task Force. RFC 4279. Archived from the original on 5 September 2013. Retrieved 9 September 2013.

[RFC5054-48] D. Taylor, Ed. "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". Internet Engineering Task Force. RFC 5054. Archived from the original on December 7, 2014. Retrieved December 21, 2014.

[:0-49] Gothard, Peter. "Google updates SSL certificates to 2048-bit encryption". Computing. Incisive Media. Archived from the original on 22 September 2013. Retrieved 9 September 2013.

[50] "The value of 2,048-bit encryption: Why encryption key length matters". SearchSecurity. Archived from the original on 2018-01-16. Retrieved 2017-12-18.

[51] Sean Turner (September 17, 2015). "Consensus: remove DSA from TLS 1.3". Archived from the original on October 3, 2015.

[52] RFC 8422

[gostlink-53] raft-chudov-cryptopro-cptls-04 – GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)

[aes-gcm-58] RFC 5288, 5289

[aes-ccm-60] RFC 6655, 7251

[camellia-gcm-62] RFC 6367

[camellia-cbc-63] RFC 5932, 6367

[aria-64] RFC 6209

[seed-cbc-65] RFC 4162

[sweet32-66] "On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN" (PDF). 2016-10-28. Archived (PDF) from the original on 2017-04-24. Retrieved 2017-06-08.

[NIST_SP_800-57-68] "NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised)" (PDF). 2007-03-08. Archived from the original (PDF) on June 6, 2014. Retrieved 2014-07-03.

[best-practices-69] Qualys SSL Labs. "SSL/TLS Deployment Best Practices". Archived from the original on 4 July 2015. Retrieved 2 June 2015.

[71] RFC 5469

[chacha20poly1305-74] RFC 7905

[77] AEAD Ciphers

[78] "Http vs https". Archived from the original on 2015-02-12. Retrieved 2015-02-12.

[trustworthy_ssl_pulse-79] As of April 11, 2021. "SSL Pulse: Survey of the SSL Implementation of the Most Popular Websites". Qualys. Retrieved 2021-04-25.

[community.qualys-80] vanr. "RC4 in TLS is Broken: Now What?". Qualsys Security Labs. Archived from the original on 2013-08-27. Retrieved 2013-07-30.

[poodle_pdf-81] Bodo Möller, Thai Duong & Krzysztof Kotowicz. "This POODLE Bites: Exploiting The SSL 3.0 Fallback" (PDF). Archived (PDF) from the original on 2014-10-14. Retrieved 2014-10-15.

[EVSSLbrowser-87] "What browsers support Extended Validation (EV) and display an EV indicator?". Symantec. Archived from the original on 2015-12-31. Retrieved 2014-07-28.

[SHA-2-88] ^ a b c d e f g h i j k l m n "SHA-256 Compatibility". Archived from the original on 2015-07-01. Retrieved 2015-06-12.

[ECC-89] ^ 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 "ECC Compatibility". Archived from the original on 2016-02-17. Retrieved 2015-06-13.

[note-FREAK-1-94] "Tracking the FREAK Attack". Archived from the original on 2015-03-06. Retrieved 2015-03-08.

[note-FREAK-2-95] "FREAK: Factoring RSA Export Keys". Archived from the original on 2015-03-11. Retrieved 2015-03-08.

[Google-96] Google (2012-05-29). "Dev Channel Update". Archived from the original on 2013-03-02. Retrieved 2011-06-01.

[googlechromereleases.blogspot.co.uk-97] Google (2012-08-21). "Stable Channel Update". Archived from the original on 2012-08-25. Retrieved 2012-08-22.

[Chromium_Project-98] Chromium Project (2013-05-30). "Chromium TLS 1.2 Implementation".

[The_Chromium_Project:_BoringSSL-100] "The Chromium Project: BoringSSL". Archived from the original on 2015-09-23. Retrieved 2015-09-05.

[ChromeBEAST-102] "Chrome Stable Release". Chrome Releases. 2011-10-25. Archived from the original on 2015-02-20. Retrieved 2015-02-01.

[build.chromium.org-104] "SVN revision log on Chrome 10.0.648.127 release". Archived from the original on 2014-06-19. Retrieved 2014-06-19.

[CRIME-Chrome=Firefox-105] "ImperialViolet – CRIME". 2012-09-22. Archived from the original on 2015-01-10. Retrieved 2014-10-18.

[SSL/TLS_Overview-106] "SSL/TLS Overview". 2008-08-06. Archived from the original on 2013-07-03. Retrieved 2013-03-29.

[Chromium_Issue_90392-107] "Chromium Issue 90392". 2008-08-06. Archived from the original on 2013-08-03. Retrieved 2013-06-28.

[Issue_23503030_Merge_219882-108] "Issue 23503030 Merge 219882". 2013-09-03. Archived from the original on 2014-02-26. Retrieved 2013-09-19.

[Issue_278370-109] "Issue 278370: Unable to submit client certificates over TLS 1.2 from Windows". 2013-08-23. Archived from the original on 2013-10-05. Retrieved 2013-10-03.

[chrome-scsv-111] Möller, Bodo (2014-10-14). "This POODLE bites: exploiting the SSL 3.0 fallback". Google Online Security blog. Google (via Blogspot). Archived from the original on 2014-10-28. Retrieved 2014-10-28.

[chrome-poodle-112] "An update on SSLv3 in Chrome". Security-dev. 2014-10-31. Retrieved 2014-11-04.

[Chrome33RC4-114] "Stable Channel Update". Mozilla Developer Network. 2014-02-20. Archived from the original on 2014-10-24. Retrieved 2014-11-14.

[Chrome33changelog-115] "Changelog for Chrome 33.0.1750.117". Google. Archived from the original on 2014-01-16. Retrieved 2014-11-14.

[Issue318442-116] "Issue 318442: Update to NSS 3.15.3 and NSPR 4.10.2". Archived from the original on 2015-03-15. Retrieved 2014-11-14.

[chromium693963003-117] "Issue 693963003: Add minimum TLS version control to about:flags and Finch gate it. – Code Review". Archived from the original on 2015-04-16. Retrieved 2015-01-22.

[chromeissue375342-121] "Issue 375342: Drop RC4 Support". Archived from the original on 2015-09-12. Retrieved 2015-05-22.

[chromeissue436391-122] "Issue 436391: Add info on end of life of SSLVersionFallbackMin & SSLVersionMin policy in documentation". Archived from the original on 2015-04-18. Retrieved 2015-04-19.

[chromeissue490240-123] "Issue 490240: Increase minimum DH size to 1024 bits (tracking bug)". Archived from the original on 2015-09-12. Retrieved 2015-05-29.

[RC4-Chrome48-1-125] ^ a b c d e f g h i j k l "Intent to deprecate: RC4". Retrieved 2015-12-21.

[RC4-Chrome48-2-126] ^ a b c d e f g h i j k l "An update on SHA-1 certificates in Chrome". 2015-12-18. Archived from the original on 2015-12-18. Retrieved 2015-12-21.

[127] ttps://support.google.com/chrome/a/answer/7679408?hl=en

[128] ttps://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#sslversionmin

[SecurityinFirefox-130] "Security in Firefox 2". 2008-08-06. Archived from the original on 2014-07-14. Retrieved 2009-03-31.

[FirefoxBEAST-131] "Attack against TLS-protected communications". Mozilla Security Blog. Mozilla. 2011-09-27. Archived from the original on 2015-03-04. Retrieved 2015-02-01.

[FxSSL2-132] "Introduction to SSL". MDN. Archived from the original on 2014-07-14. Retrieved 2014-06-19.

[NSS-3.15.3-133] "NSS 3.15.3 Release Notes". Mozilla Developer Network. Mozilla. Archived from the original on 2014-06-05. Retrieved 2014-07-13.

[mfsa2013-103-134] "MFSA 2013-103: Miscellaneous Network Security Services (NSS) vulnerabilities". Mozilla. Mozilla. Archived from the original on 2014-07-14. Retrieved 2014-07-13.

[Bug565047-135] "Bug 565047 – (RFC4346) Implement TLS 1.1 (RFC 4346)". Retrieved 2013-10-29.

[Bug480514-137] "Bug 480514 – Implement support for TLS 1.2 (RFC 5246)". Retrieved 2013-10-29.

[Bug733647-138] "Bug 733647 – Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default". Retrieved 2013-12-04.

[Fx27-139] "Firefox Notes – Desktop". 2014-02-04. Archived from the original on 2014-02-07. Retrieved 2014-02-04.

[Bug861266-140] "Bug 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default". Retrieved 2013-11-18.

[firefox-poodle-141] "The POODLE Attack and the End of SSL 3.0". Mozilla blog. Mozilla. 2014-10-14. Archived from the original on 2014-10-18. Retrieved 2014-10-28.

[Fx34-142] "Firefox — Notes (34.0) — Mozilla". mozilla.org. 2014-12-01. Archived from the original on 2015-04-09. Retrieved 2015-04-03.

[firefox-fallback-disabled-143] "Bug 1083058 – A pref to control TLS version fallback". bugzilla.mozilla.org. Retrieved 2014-11-06.

[bugzilla.mozilla.org-144] "Bug 1036737 – Add support for draft-ietf-tls-downgrade-scsv to Gecko/Firefox". bugzilla.mozilla.org. Retrieved 2014-10-29.

[FxLogjam-146] "Bug 1166031 – Update to NSS 3.19.1". bugzilla.mozilla.org. Retrieved 2015-05-29.

[https-147] "Bug 1088915 – Stop offering RC4 in the first handshakes". bugzilla.mozilla.org. Retrieved 2014-11-04.

[Fx39-148] "Firefox — Notes (39.0) — Mozilla". mozilla.org. 2015-06-30. Archived from the original on 2015-07-03. Retrieved 2015-07-03.

[RC4Fx-149] "Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year". VentureBeat. 2015-09-01. Archived from the original on 2015-09-05. Retrieved 2015-09-05.

[RC4Fx-2-150] "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22. Retrieved 2015-10-18.

[RC4Fx-3-151] "RC4 is now allowed only on whitelisted sites (Reverted)". Retrieved 2015-11-02.

[Fx44-152] "Firefox — Notes (44.0) — Mozilla". mozilla.org. 2016-01-26. Archived from the original on 2016-03-04. Retrieved 2016-03-09.

[153] "Bug 1342082 – Disable TLS 1.3 for FF52 Release". Retrieved 2017-03-29.

[Firefox78-RN-154] ttps://www.mozilla.org/en-US/firefox/78.0/releasenotes/

[Opera_9.0_for_Windows_Changelog-155] "Opera 9.0 for Windows Changelog". Archived from the original on 2012-09-10.

[Opera2-157] "Opera 2 series". Archived from the original on 2014-10-23. Retrieved 2014-09-20.

[Opera3-158] "Opera 3 series". Archived from the original on 2014-10-23. Retrieved 2014-09-20.

[Opera4-159] "Opera 4 series". Archived from the original on 2014-10-23. Retrieved 2014-09-20.

[Opera5-160] "Changelog for Opera 5.x for Windows". Archived from the original on 2014-10-19. Retrieved 2014-06-19.

[opera.com-161] "Changelog for Opera [8] Beta 2 for Windows". Archived from the original on 2005-11-23. Retrieved 2014-06-19.

[162] "Web Specifications Supported in Opera 9". Archived from the original on 2014-10-26. Retrieved 2014-06-19.

[Opera10b-163] "Opera: Opera 10 beta for Windows changelog". Archived from the original on 2014-10-23. Retrieved 2014-06-19.

[my.opera.com-164] "About Opera 11.60 and new problems with some secure servers". 2011-12-11. Archived from the original on 2012-01-18.

[OperaPOODLE-166] "Security changes in Opera 25; the poodle attacks". 2014-10-15. Archived from the original on 2014-10-20. Retrieved 2014-10-28.

[OperaLogjam-167] "Unjam the logjam". 2015-06-09. Archived from the original on 2015-06-14. Retrieved 2015-06-11.

[ReferenceA-168] "Advisory: RC4 encryption protocol is vulnerable to certain brute force attacks". 2013-04-04. Archived from the original on 2015-03-15. Retrieved 2014-11-14.

[On_the_Precariousness_of_RC4-169] "On the Precariousness of RC4". 2013-03-20. Archived from the original on 2013-11-12. Retrieved 2014-11-17.

[opera1218-170] "Opera 12 and Opera Mail security update". 2016-02-16. Archived from the original on 2016-02-16. Retrieved 2016-02-17.

[dev.opera.com-171] "Dev.Opera — Opera 14 for Android Is Out!". 2013-05-21. Archived from the original on 2015-01-30. Retrieved 2014-09-23.

[ReferenceB-172] "Dev.Opera — Introducing Opera 15 for Computers, and a Fast Release Cycle". 2013-07-02. Archived from the original on 2014-09-02. Retrieved 2014-09-23.

[opera16-174] same as Chrome 26–29

[opera17-175] same as Chrome 30 and later

[opera20-176] same as Chrome 33 and later

[Microsoft-182] Microsoft (2012-09-05). "Secure Channel". Archived from the original on 2012-08-29. Retrieved 2012-10-18.

[msdn.microsoft.com-183] Microsoft (2009-02-27). "MS-TLSP Appendix A". Archived from the original on 2013-09-27. Retrieved 2009-03-19.

[IESSL3TLS1-187] "What browsers only support SSLv2?". Retrieved 2014-06-19.

[WinXP2003SHA2-189] "SHA2 and Windows – Windows PKI blog – Site Home – TechNet Blogs". 2010-09-30. Archived from the original on 2014-07-16. Retrieved 2014-07-29.

[IE7HTTPS-190] "HTTPS Security Improvements in Internet Explorer 7". Archived from the original on 2013-10-10. Retrieved 2013-10-29.

[TLS_Cipher_Suites-191] "TLS Cipher Suites". Microsoft. Archived from the original on 2017-03-13.

[Archived_copy-192] "Archived copy". Archived from the original on 2015-03-11. Retrieved 2017-07-19.CS1 maint: archived copy as title (link)

[MS15-031-193] "Vulnerability in Schannel Could Allow Security Feature Bypass (3046049)". 2015-03-10. Archived from the original on 2017-03-13. Retrieved 2015-03-11.

[MS15-055-194] "Vulnerability in Schannel Could Allow Information Disclosure (3061518)". 2015-05-12. Archived from the original on 2016-10-08. Retrieved 2015-05-22.

[2008R1TLS1.2-195] "Update to add support for TLS 1.1 and TLS 1.2 in Windows Server 2008 SP2, Windows Embedded POSReady 2009, and Windows Embedded Standard 2009". Retrieved 2017-07-19.

[Win7TLS1.1-196] "Windows 7 adds support for TLSv1.1 and TLSv1.2 – IEInternals – Site Home – MSDN Blogs". Archived from the original on 2013-12-26. Retrieved 2013-10-29.

[20141111msblog-197] Thomlinson, Matt (2014-11-11). "Hundreds of Millions of Microsoft Customers Now Benefit from Best-in-Class Encryption". Microsoft Security. Archived from the original on 2014-11-14. Retrieved 2014-11-14.

[win7-8rc4-198] Microsoft security advisory: Update for disabling RC4 Archived 2015-03-11 at the Wayback Machine

[IE11_TLS_1.1_1.2-201] Microsoft (2013-09-24). "IE11 Changes". Archived from the original on 2013-10-30. Retrieved 2013-11-01.

[202] "February 2015 security updates for Internet Explorer". 2015-02-11. Archived from the original on 2015-02-11. Retrieved 2015-02-11.

[support.microsoft.com-203] "Update turns on the setting to disable SSL 3.0 fallback for protected mode sites by default in Internet Explorer 11". Archived from the original on 2015-02-14. Retrieved 2015-02-11.

[technet.microsoft.com-204] "Vulnerability in SSL 3.0 Could Allow Information Disclosure". 2015-04-14. Archived from the original on 2016-10-08. Retrieved 2015-04-14.

[205] Microsoft Edge Team (2016-08-09). "RC4 is now disabled in Microsoft Edge and Internet Explorer 11". Microsoft. Archived from the original on 2016-08-21.

[206] "Internet Explorer 11 for Windows Server 2012 and Windows Embedded 8 Standard". Microsoft Support. 2019-04-16.

[Windows10_v1607schannel-207] "TLS (Schannel SSP) changes in Windows 10 and Windows Server 2016". Microsoft. 2017-03-21. Archived from the original on 2017-03-30. Retrieved 2017-03-29.

[WIN_TLS_1.3-208] "Protocols in TLS/SSL (Schannel SSP)".

[ECC2-209] "What browsers work with Universal SSL". Archived from the original on 2016-03-04. Retrieved 2015-06-15.

[XDA-210] "POODLE SSL vulnerability – secure your Windo… – Windows Phone 8 Development and Hacking". XDA Developers. Archived from the original on 2016-09-23.

[IEMobile10-212] "What TLS version is used in Windows Phone 8 for secure HTTP connections?". Microsoft. Archived from the original on 2016-03-04. Retrieved 2014-11-07.

[ssllabs.com-213] "Qualys SSL Labs – Projects / User Agent Capabilities: Unknown". Archived from the original on 2017-03-01.

[IEMobile11-214] "Platform Security". Microsoft. 2014-06-25. Archived from the original on 2017-03-13. Retrieved 2014-11-07.

[Win8.1RC4-215] "Release Notes: Important Issues in Windows 8.1 Preview". Microsoft. 2013-06-24. Archived from the original on 2014-11-04. Retrieved 2014-11-04.

[Win8.1RC4Qualys-216] "W8.1(IE11) vs RC4". Qualys Community. Archived from the original on 2014-11-04. Retrieved 2014-11-04.

[Adrian-218] Adrian, Dimcev. "Common browsers/libraries/servers and the associated cipher suites implemented". TLS Cipher Suites Project. Archived from the original on 2013-04-17.

[Apple-219] "Features". Safari. Apple. 2009-06-10. Archived from the original on 2013-04-17. Retrieved 2009-06-10.

[curl.haxx.se-220] "Curl: Patch to add TLS 1.1 and 1.2 support & replace deprecated functions in SecureTransport". Sweden: haxx.se. Archived from the original on 2017-03-01.

[Qualys_SSL_Report:_google.co.uk-221] Qualys SSL Report: google.co.uk Archived 2017-03-20 at the Wayback Machine (simulation Safari 5.1.9 TLS 1.0)

[SafariSSL2-223] "Apple Secures Mac OS X with Mavericks Release". eSecurity Planet. 2013-10-25. Archived from the original on 2014-07-08. Retrieved 2014-06-23.

[BEAST-Still-224] Ristic, Ivan (2013-09-10). "Is BEAST Still a Threat?". Qualys. Archived from the original on 2014-10-12.

[beast-mitigations-mavericks-225] Ristić, Ivan (2013-10-31). "Apple enabled BEAST mitigations in OS X 10.9 Mavericks". Archived from the original on 2013-11-07. Retrieved 2013-11-07.

[beast-mitigations-10.8-226] Ristić, Ivan (2014-02-26). "Apple finally releases patch for BEAST". Qualys. Archived from the original on 2014-07-14. Retrieved 2014-07-01.

[228] "About Security Update 2014-005". Apple Support knowledge base article. Apple. Archived from the original on 2014-10-24.

[support.apple.com-229] "About the security content of iOS 8.1". Apple Support knowledge base article. Apple. Archived from the original on 2014-10-23.

[freak-OSX-231] "About Security Update 2015-002". Apple Support knowledge base article. Apple. Archived from the original on 2015-03-16. Retrieved 2015-03-09.

[MavericksTLS1.2-232] "About the security content of OS X Mavericks v10.9". Archived from the original on 2014-07-04. Retrieved 2014-06-20.

[ssltest-safari-OSX1010-233] "User Agent Capabilities: Safari 8 / OS X 10.10". Qualys SSL Labs. Archived from the original on 2015-09-06. Retrieved 2015-03-07.

[logjam-OSX-234] "About the security content of OS X Yosemite v10.10.4 and Security Update 2015-005". Archived from the original on 2015-07-02. Retrieved 2015-07-03.

[Pauly-235] Pauly, Tommy (2019-01-29). "TLS 1.3 in iOS". [email protected] (Mailing list).

[iOS5TLS1.2-236] "Technical Note TN2287 – iOS 5 and TLS 1.2 Interoperability Issues". Apple. 2011-10-14. Archived from the original on 2011-09-07. Retrieved 2012-12-10.

[Liebowitz-237] Liebowitz, Matt (2011-10-13). "Apple issues huge software security patches". NBC News. Retrieved 2012-12-10.

[MWR_Info_Security-238] MWR Info Security (2012-04-16). "Adventures with iOS UIWebviews". Archived from the original on 2013-04-17. Retrieved 2012-12-10., section "HTTPS (SSL/TLS)"

[240] "Secure Transport Reference". Archived from the original on 2014-06-04. Retrieved 2014-06-23. kSSLProtocol2 is deprecated in iOS

[theiphoneblog.com-241] "iPhone 3.0: Mobile Safari Gets Enhanced Security Certificate Visualization". The iPhone Blog. 2009-03-31. Archived from the original on 2009-04-03.

[ReferenceC-242] "Projects / User Agent Capabilities: Safari 7 / iOS 7.1". Qualys SSL Labs. Archived from the original on 2017-03-13.

[beast-mitigations-ios7-243] schurtertom (2013-10-11). "SOAP Request fails randomly on one Server but works on another on iOS7". Stack Overflow. Retrieved 2014-01-05.

[ssltest-safari-iOS812-244] "User Agent Capabilities: Safari 8 / iOS 8.1.2". Qualys SSL Labs. Archived from the original on 2016-03-04. Retrieved 2015-03-07.

[freak-iOS82-245] "About the security content of iOS 8.2". Apple Support knowledge base article. Apple. Archived from the original on 2015-03-09. Retrieved 2015-03-09.

[logjam-iOS84-246] "About the security content of iOS 8.4". Archived from the original on 2015-07-03. Retrieved 2015-07-03.

[android-tls-247] "SSLSocket | Android Developers". Archived from the original on 2015-03-18. Retrieved 2015-03-11.

[Android-SSLSocket-248] "SSLSocket | Android Developers". Archived from the original on 2016-03-04. Retrieved 2015-12-17.

[android-5-tls-249] "Android 5.0 Behavior Changes | Android Developers". Archived from the original on 2015-03-09. Retrieved 2015-03-11.

[Android_8.0_Behavior_Changes-250] "Android 8.0 Behavior Changes". Archived from the original on 2017-12-01.

[Oracle-251] Oracle. "7093640: Enable client-side TLS 1.2 by default". Retrieved 2018-08-30.

[bugs.openjdk.java.net-252] Oracle. "JEP 332: Transport Layer Security (TLS) 1.3". Retrieved 2018-08-30.

[253] Ben Smyth (2019). "TLS 1.3 for engineers: An exploration of the TLS 1.3 specification and OpenJDK's Java implementation". arXiv:1904.02148. Retrieved 2021-01-29.

[Botan_1.11.13-254] "Version 1.11.13, 2015-01-11 — Botan". 2015-01-11. Archived from the original on 2015-01-09. Retrieved 2015-01-16.

[GnuTLS-3.4.0-255] "[gnutls-devel] GnuTLS 3.4.0 released". 2015-04-08. Archived from the original on 2015-04-16. Retrieved 2015-04-16.

[GnuTLS-3.6.4-256] "[gnutls-devel] gnutls 3.6.4". 2018-09-24. Retrieved 2020-05-18.

[oracle.com-257] "Java™ SE Development Kit 8, Update 31 Release Notes". Archived from the original on 2015-01-21. Retrieved 2015-01-22.

[OpenBSD5.6-258] "OpenBSD 5.6 Released". 2014-11-01. Retrieved 2015-01-20.

[libressl-2.3-259] "LibreSSL 2.3.0 Released". 2015-09-23. Retrieved 2015-09-24.

[260] ttps://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.2.2-relnotes.txt

[261] ttps://github.com/libressl-portable/portable/issues/228

[Matrix-POODLE-262] "MatrixSSL – News". Archived from the original on 2015-02-14. Retrieved 2014-11-09.

[mbed-2.0-263] "mbed TLS 2.0.0 released". 2015-07-10. Archived from the original on 2015-09-25. Retrieved 2015-07-14.

[NSS-3.19-264] "NSS 3.19 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2015-06-05. Retrieved 2015-05-06.

[NSS-3.14-265] "NSS 3.14 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2013-01-17. Retrieved 2012-10-27.

[NSS-3.15.1-266] "NSS 3.15.1 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2013-09-22. Retrieved 2013-08-10.

[NSS_3.39_release_notes-267] "NSS 3.39 release notes". 2018-08-31. Retrieved 2018-09-14.

[OpenSSL_1.1.0_Series_Release_Notes-268] "OpenSSL 1.1.0 Series Release Notes". Archived from the original on 2016-08-25. Retrieved 2016-10-02.

[openssl-1.0.1-note-269] "Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1 [14 Mar 2012]". 2012-03-14. Archived from the original on January 20, 2015. Retrieved 2015-01-20.

[OpenSSL_1.1.1_Is_Released-270] "OpenSSL 1.1.1 Is Released". 2018-09-11. Retrieved 2018-09-14.

[XP2003schannel-271] TLS cipher suites in Microsoft Windows XP and 2003 Archived 2015-01-18 at the Wayback Machine

[Vista2008schannel-272] SChannel Cipher Suites in Microsoft Windows Vista Archived 2015-01-12 at the Wayback Machine

[Windows7schannel-273] TLS Cipher Suites in SChannel for Windows 7, 2008R2, 8, 2012 Archived 2015-03-19 at the Wayback Machine

[Windows10_v1903schannel-274] "Microsoft TLS 1.3 Support Reference". Microsoft. 2020-01-30. Retrieved 2021-01-01."What's new in Windows 10, version 1909 for IT Pros". Microsoft. 2020-10-03. Retrieved 2021-01-01.

[Windows10_v21H1schannel-275] "Protocols in TLS/SSL (Schannel SSP)". Microsoft. 2020-12-17. Retrieved 2021-01-01.

[wolfSSL-3.6.6-276] "[wolfssl] wolfSSL 3.6.6 Released". 2015-08-20. Archived from the original on 2015-10-17. Retrieved 2015-08-25.

[wolfSSL_TLS_1.3_support-277] "[wolfssl] wolfSSL TLS1.3 support". 2017-02-13. Retrieved 2017-02-13.

[NSS-3.24-278] "NSS 3.24 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2016-08-26. Retrieved 2016-06-19.

[279] "Technical Note TN2287: iOS 5 and TLS 1.2 Interoperability Issues". iOS Developer Library. Apple Inc. Archived from the original on 2015-04-03. Retrieved 2012-05-03.

[280] Qualys SSL Labs – Projects / User Agent Capabilities Archived 2015-09-19 at the Wayback Machine

[281] Georgiev, Martin and Iyengar, Subodh and Jana, Suman and Anubhai, Rishita and Boneh, Dan and Shmatikov, Vitaly (2012). The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). pp. 38–49. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2017-10-22.CS1 maint: multiple names: authors list (link)

[282] "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)". RFC 5630.

[283] Joris Claessens; Valentin Dem; Danny De Cock; Bart Preneel; Joos Vandewalle (2002). "On the Security of Today's Online Electronic Banking Systems" (PDF). Computers & Security. 21 (3): 253–265. doi:10.1016/S0167-4048(02)00312-7.

[RFC6101-284] A. Freier; P. Karlton; P. Kocher (August 2011). "The Secure Sockets Layer (SSL) Protocol Version 3.0". Archived from the original on 2012-01-15.

[285] Lawrence, Eric (2005-10-22). "IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2". MSDN Blogs. Archived from the original on 2013-04-17. Retrieved 2007-11-25.

[286] "Bugzilla@Mozilla — Bug 236933 – Disable SSL2 and other weak ciphers". Mozilla Corporation. Retrieved 2007-11-25.

[287] "Opera 9.5 for Windows Changelog" Archived 2009-06-26 at the Wayback Machine at Opera.com: "Disabled SSL v2 and weak ciphers."

[288] "Opera 10 for Windows changelog" Archived 2013-03-26 at the Wayback Machine at Opera.com: "Removed support for SSL v2 and weak ciphers"

[289] Pettersen, Yngve (2007-04-30). "10 years of SSL in Opera — Implementer's notes". Opera Software. Archived from the original on October 12, 2007. Retrieved 2007-11-25.

[290] National Institute of Standards and Technology (December 2010). "Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program" (PDF). Archived from the original (PDF) on November 6, 2010.

[291] "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)". RFC 7457. Archived from the original on 2016-03-04.

[292] "CVE – CVE-2009-3555". Archived from the original on 2016-01-04.

[293] Eric Rescorla (2009-11-05). "Understanding the TLS Renegotiation Attack". Educated Guesswork. Archived from the original on 2012-02-09. Retrieved 2009-11-27.

[294] "SSL_CTX_set_options SECURE_RENEGOTIATION". OpenSSL Docs. 2010-02-25. Archived from the original on 2010-11-26. Retrieved 2010-11-18.

[295] "GnuTLS 2.10.0 released". GnuTLS release notes. 2010-06-25. Archived from the original on 2012-02-09. Retrieved 2011-07-24.

[296] "NSS 3.12.6 release notes". NSS release notes. 2010-03-03. Archived from the original on March 6, 2012. Retrieved 2011-07-24.

[297] A. Langley; N. Modadugu; B. Moeller (2010-06-02). "Transport Layer Security (TLS) False Start". Internet Engineering Task Force. IETF. Archived from the original on 2013-09-05. Retrieved 2013-07-31.

[298] Gruener, Wolfgang. "False Start: Google Proposes Faster Web, Chrome Supports It Already". Archived from the original on 2010-10-07. Retrieved 2011-03-09.

[299] Smith, Brian. "Limited rollback attacks in False Start and Snap Start". Archived from the original on 2011-05-04. Retrieved 2011-03-09.

[300] Dimcev, Adrian. "False Start". Random SSL/TLS 101. Archived from the original on 2011-05-04. Retrieved 2011-03-09.

[301] Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). pp. 62–72. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2015-07-06.

[302] "SMACK: State Machine AttaCKs". Archived from the original on 2015-03-12.

[303] Goodin, Dan (2015-05-20). "HTTPS-crippling attack threatens tens of thousands of Web and mail servers". Ars Technica. Archived from the original on 2017-05-19.

[304] Leyden, John (1 March 2016). "One-third of all HTTPS websites open to DROWN attack". The Register. Archived from the original on 1 March 2016. Retrieved 2016-03-02.

[ars201603-305] "More than 11 million HTTPS websites imperiled by new decryption attack". Ars Technica. Archived from the original on 2016-03-01. Retrieved 2016-03-02.

[DuongRizzo-306] Thai Duong & Juliano Rizzo (2011-05-13). "Here Come The ⊕ Ninjas". Archived from the original on 2014-06-03.

[DanGoodin-307] Dan Goodin (2011-09-19). "Hackers break SSL encryption used by millions of sites". Archived from the original on 2012-02-09.

[combinator-308] "Y Combinator comments on the issue". 2011-09-20. Archived from the original on 2013-04-17.

[309] "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures". 2004-05-20. Archived from the original on 2012-06-30.

[310] Ristic, Ivan (Sep 10, 2013). "Is BEAST Still a Threat?". Archived from the original on 12 October 2014. Retrieved 8 October 2014.

[311] Brian Smith (2011-09-30). "(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)".

[312] "Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)". 2012-01-10. Archived from the original on 2014-08-15.

[313] Ristic, Ivan (Oct 31, 2013). "Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks". Archived from the original on 12 October 2014. Retrieved 8 October 2014.

[314] Dan Goodin (2012-09-13). "Crack in Internet's foundation of trust allows HTTPS session hijacking". Ars Technica. Archived from the original on 2013-08-01. Retrieved 2013-07-31.

[315] Dennis Fisher (September 13, 2012). "CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions". ThreatPost. Archived from the original on September 15, 2012. Retrieved 2012-09-13.

[Gooin20130801-316] Goodin, Dan (1 August 2013). "Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages". Ars Technica. Condé Nast. Archived from the original on 3 August 2013. Retrieved 2 August 2013.

[317] Leyden, John (2 August 2013). "Step into the BREACH: New attack developed to read encrypted web data". The Register. Archived from the original on 5 August 2013. Retrieved 2 August 2013.

[318] P. Gutmann (September 2014). "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". Archived from the original on 2015-05-12.

[poodleagain-319] Langley, Adam (December 8, 2014). "The POODLE bites again". Archived from the original on December 8, 2014. Retrieved 2014-12-08.

[320] security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault

[321] Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). "Discovery and Exploitation of New Biases in RC4". In Alex Biryukov; Guang Gong; Douglas R. Stinson (eds.). Selected Areas in Cryptography: 17th International Workshop, SAC 2010, Waterloo, Ontario, Canada, August 12-13, 2010, Revised Selected Papers. Lecture Notes in Computer Science. 6544. pp. 74–91. doi:10.1007/978-3-642-19574-7_5. ISBN 978-3-642-19573-0.

[322] Green, Matthew. "Attack of the week: RC4 is kind of broken in TLS". Cryptography Engineering. Archived from the original on March 14, 2013. Retrieved March 12, 2013.

[323] Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt. "On the Security of RC4 in TLS". Royal Holloway University of London. Archived from the original on March 15, 2013. Retrieved March 13, 2013.CS1 maint: multiple names: authors list (link)

[324] AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 July 2013). "On the Security of RC4 in TLS and WPA" (PDF). Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013. Cite journal requires |journal= (help)

[325] AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 August 2013). On the Security of RC4 in TLS (PDF). 22nd USENIX Security Symposium. p. 51. Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013. Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical

[326] Goodin, Dan. "Once-theoretical crypto attack against HTTPS now verges on practicality". Ars Technical. Conde Nast. Archived from the original on 16 July 2015. Retrieved 16 July 2015.

[327] "Mozilla Security Server Side TLS Recommended Configurations". Mozilla. Archived from the original on 2015-01-03. Retrieved 2015-01-03.

[328] "Security Advisory 2868725: Recommendation to disable RC4". Microsoft. 2013-11-12. Archived from the original on 2013-11-18. Retrieved 2013-12-04.

[329] "Ending support for the RC4 cipher in Microsoft Edge and Internet Explorer 11". Microsoft Edge Team. September 1, 2015. Archived from the original on September 2, 2015.

[330] Langley, Adam (Sep 1, 2015). "Intent to deprecate: RC4".

[331] Barnes, Richard (Sep 1, 2015). "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22.

[register20130801-332] John Leyden (1 August 2013). "Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack". The Register. Archived from the original on 1 August 2013. Retrieved 1 August 2013.

[333] "BlackHat USA Briefings". Black Hat 2013. Archived from the original on 30 July 2013. Retrieved 1 August 2013.

[334] Smyth, Ben; Pironti, Alfredo (2013). "Truncating TLS Connections to Violate Beliefs in Web Applications". 7th USENIX Workshop on Offensive Technologies. Archived from the original on 6 November 2015. Retrieved 15 February 2016.

[335] Goodin, Dan. "New attack bypasses HTTPS protection on Macs, Windows, and Linux". Ars Technica. Condé Nast. Archived from the original on 27 July 2016. Retrieved 28 July 2016.

[336] Goodin, Dan (August 24, 2016). "HTTPS and OpenVPN face new attack that can decrypt secret cookies". Ars Technica. Archived from the original on August 24, 2016. Retrieved August 24, 2016.

[337] "Why is it called the 'Heartbleed Bug'?". The Washington Post. 2014-04-09. Archived from the original on 2014-10-09.

[338] "Heartbleed Bug vulnerability [9 April 2014]". Comodo Group. Archived from the original on 5 July 2014.

[339] Bleichenbacher, Daniel (August 2006). "Bleichenbacher's RSA signature forgery based on implementation error". Archived from the original on 2014-12-16.

[340] "BERserk". Intel Security: Advanced Threat Research. September 2014. Archived from the original on 2015-01-12.

[341] Goodin, Dan (February 19, 2015). "Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections". Ars Technica. Archived from the original on September 12, 2017. Retrieved December 10, 2017.

[342] Valsorda, Filippo (2015-02-20). "Komodia/Superfish SSL validation is broken". Filippo.io. Archived from the original on 2015-02-24.

[forbidden-343] Goodin, Dan. ""Forbidden attack" makes dozens of HTTPS Visa sites vulnerable to tampering". Ars Technica. Archived from the original on 26 May 2016. Retrieved 26 May 2016.

[344] Clark Estes, Adam. "Everything You Need to Know About Cloudbleed, the Latest Internet Security Disaster". Gizmodo. Archived from the original on 2017-02-25. Retrieved 2017-02-24.

[345] Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (June 1992). "Authentication and Authenticated Key Exchanges". Designs, Codes and Cryptography. 2 (2): 107–125. CiteSeerX 10.1.1.59.6682. doi:10.1007/BF00124891. S2CID 7356608. Archived from the original on 2008-03-13. Retrieved 2008-02-11.

[346] Discussion on the TLS mailing list in October 2007 Archived 2013-09-22 at the Wayback Machine

[347] "Protecting data for the long term with forward secrecy". Archived from the original on 2013-05-06. Retrieved 2012-11-05.

[348] Bernat, Vincent. "SSL/TLS & Perfect Forward Secrecy". Archived from the original on 2012-08-27. Retrieved 2012-11-05.

[349] "SSL Labs: Deploying Forward Secrecy". Qualys.com. 2013-06-25. Archived from the original on 2013-06-26. Retrieved 2013-07-10.

[350] Ristic, Ivan (2013-08-05). "SSL Labs: Deploying Forward Secrecy". Qualsys. Archived from the original on 2013-09-20. Retrieved 2013-08-31.

[botchingpfs-351] Langley, Adam (27 June 2013). "How to botch TLS forward secrecy". imperialviolet.org. Archived from the original on 8 August 2013.

[ticketsecwp-352] Daignière, Florent. "TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL" (PDF). Matta Consulting Limited. Archived (PDF) from the original on 6 August 2013. Retrieved 7 August 2013.

[ticketsecslides-353] Daignière, Florent. "TLS "Secrets": What everyone forgot to tell you..." (PDF). Matta Consulting Limited. Archived (PDF) from the original on 5 August 2013. Retrieved 7 August 2013.

[354] L.S. Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "An Experimental Study of TLS Forward Secrecy Deployments". IEEE Internet Computing. 18 (6): 43–51. CiteSeerX 10.1.1.663.4653. doi:10.1109/MIC.2014.86. S2CID 11264303. Archived from the original on 20 September 2015. Retrieved 16 October 2015.

[googleLongTerm-355] "Protecting data for the long term with forward secrecy". Archived from the original on 2014-02-12. Retrieved 2014-03-07.

[356] Hoffman-Andrews, Jacob. "Forward Secrecy at Twitter". Twitter. Archived from the original on 2014-02-16. Retrieved 2014-03-07.

[Durumeric_et_al_2017-357] Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 September 2017). "The Security Impact of HTTPS Interception". NDSS Symposium. doi:10.14722/ndss.2017.23456. ISBN 978-1-891562-46-4.

[openpgp-358] These certificates are currently X.509, but RFC 6091 also specifies the use of OpenPGP-based certificates.

[359] "tls - Differences between the terms "pre-master secret", "master secret", "private key", and "shared secret"?". Cryptography Stack Exchange. Retrieved 2020-10-01.

[360] Chris (2009-02-18). "vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication". Scarybeastsecurity. blogspot.com. Archived from the original on 2012-07-07. Retrieved 2012-05-17.

[361] Valsorda, Filippo. "An overview of TLS 1.3 and Q&A". The Cloudflare Blog.

[362] Wildcard SSL Certificate overview, archived from the original on 2015-06-23, retrieved 2015-07-02

[363] Named-based SSL virtual hosts: how to tackle the problem (PDF), archived (PDF) from the original on 2012-08-03, retrieved 2012-05-17

vteVirtual private networking
Communication protocols	SSTP IPsec L2TP L2TPv3 PPTP Split tunneling DTLS SSL/TLS (Opportunistic: tcpcrypt)
Free software	FreeLAN FreeS/WAN Libreswan n2n OpenConnect OpenIKED Openswan OpenVPN Social VPN SoftEther VPN strongSwan tcpcrypt tinc VTun WireGuard Shadowsocks
Vendor-driven protocols	Layer 2 Forwarding Protocol DirectAccess
Proprietary software	Avast SecureLine VPN Check Point VPN-1 Cisco Systems VPN Client ExpressVPN HideMyAss! Hola LogMeIn Hamachi Microsoft Forefront Unified Access Gateway NordVPN Private Internet Access ProtonVPN PureVPN SaferVPN Tunnelbear
Risk vectors	Content-control software Deep content inspection Deep packet inspection IP address blocking Network enumeration Stateful firewall TCP reset attack VPN blocking