El protocolo TLS tiene como objetivo principal proporcionar seguridad, incluida la privacidad (confidencialidad), integridad y autenticidad mediante el uso de criptografía , como el uso de certificados , entre dos o más aplicaciones informáticas que se comunican. Se ejecuta en la capa de presentación y está compuesto por dos capas: el registro TLS y los protocolos de enlace TLS .
El protocolo de seguridad de la capa de transporte de datagramas ( DTLS ) es un protocolo de comunicaciones que proporciona seguridad a las aplicaciones basadas en datagramas . En los textos técnicos, se suelen ver referencias a "( D ) TLS " cuando se aplica a ambas versiones. [1]
TLS es un estándar propuesto por el 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 ( Secure Sockets Layer ) ahora obsoletas (1994, 1995, 1996) desarrolladas por Netscape Communications para agregar el protocolo HTTPS a su navegador web Netscape Navigator .
Dado que las aplicaciones pueden comunicarse con o sin TLS (o SSL), es necesario que el cliente solicite al servidor que configure una conexión TLS. [2] Una de las principales formas de lograr esto es utilizar un número de puerto diferente para las conexiones TLS. El puerto 80 se utiliza normalmente para el tráfico HTTP sin cifrar, mientras que el puerto 443 es el puerto común utilizado para el tráfico HTTPS cifrado . Otro mecanismo es realizar una solicitud STARTTLS específica del protocolo al servidor para cambiar la conexión a TLS, por ejemplo, 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 (consulte § Protocolo de enlace TLS). [3] Los protocolos utilizan un protocolo de enlace con un cifrado asimétrico para establecer no solo las configuraciones de cifrado sino también una clave compartida específica de la sesión con la que se cifra la comunicación posterior 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 solicitando una conexión segura y el cliente presenta una lista de conjuntos de cifrados compatibles ( cifrados y funciones hash ).
De esta lista, el servidor selecciona un cifrado y una función hash que también admite y notifica la decisión al cliente.
El servidor suele proporcionar una identificación en forma de certificado digital . El certificado contiene el nombre del servidor , la autoridad de certificación (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 sólo el servidor debería poder descifrar con su clave privada); ambas partes utilizan el número aleatorio para generar una clave de sesión única para el cifrado y descifrado posterior de datos durante la sesión, o
utiliza el intercambio de claves Diffie-Hellman (o su variante DH de curva elíptica ) para generar de forma segura una clave de sesión aleatoria y única para el cifrado y descifrado que tiene la propiedad adicional de secreto hacia adelante : si la clave privada del servidor se revela en el futuro, no se puede utilizar para descifrar la sesión actual, incluso si la sesión es interceptada y grabada 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 la conexión no se crea.
TLS y SSL no encajan perfectamente en ninguna capa del modelo OSI o del modelo TCP/IP . [4] [5] TLS se ejecuta "sobre algún protocolo de transporte confiable (por ejemplo, TCP)", [6] : §1, lo que implicaría que está por encima de la capa de transporte . Proporciona cifrado a capas superiores, que normalmente es la función de la capa de presentación . Sin embargo, las aplicaciones generalmente usan TLS como si fuera una capa de transporte, [4] [5] aunque las aplicaciones que usan TLS deben controlar activamente el inicio de los protocolos de enlace TLS y el manejo de los certificados de autenticación intercambiados. [6] : §1
Cuando están protegidas por TLS, las conexiones entre un cliente (por ejemplo, un navegador web) y un servidor (por ejemplo, wikipedia.org) tendrán todas las siguientes propiedades: [6] : §1
La conexión es privada (o tiene confidencialidad ) 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 a la vez segura (el secreto negociado no está disponible para los espías y no puede ser obtenido, ni siquiera por un atacante que se coloque en medio de la conexión) y fiable (ningún atacante puede modificar las comunicaciones durante la negociación sin ser detectado).
La identidad de las partes que se comunican puede autenticarse mediante criptografía de clave pública . Esta autenticación es obligatoria para el servidor y opcional para el cliente.
La conexión es confiable (o tiene integridad ) porque cada mensaje transmitido incluye una verificación de integridad del mensaje utilizando un código de autenticación de mensaje para evitar la pérdida o alteración no detectada de los datos durante la transmisión.
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 y § Integridad de datos).
Se han hecho intentos para subvertir aspectos de la seguridad de las comunicaciones que TLS busca proporcionar, y el protocolo ha sido 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 estas se descubrieran (consulte el historial de compatibilidad de TLS/SSL de los navegadores web).
Como el datagrama del protocolo DTLS conserva la semántica del transporte subyacente (la aplicación no sufre los retrasos asociados con los protocolos de flujo), sin embargo, la aplicación tiene que lidiar con la reordenación de paquetes , la pérdida de datagramas y datos más grandes que el tamaño de un paquete de red de datagramas . Debido a que DTLS utiliza UDP o SCTP en lugar de TCP, evita el problema de la fusión de TCP [ 9] [10] cuando se utiliza para crear un túnel VPN.
La versión 1.0 de DTLS publicada originalmente en 2006 no era un documento independiente, sino que se presentó como una serie de modificaciones de TLS 1.1. [11] De manera similar, la versión 2012 de DTLS es una modificación de TLS 1.2. Se le asignó el número de versión de DTLS 1.2 para que coincida con su versión de TLS. Por último, la versión 1.3 de DTLS de 2022 es una modificación de TLS 1.3. Al igual que las dos versiones anteriores, DTLS 1.3 tiene como objetivo proporcionar "garantías de seguridad equivalentes [a TLS 1.3] con la excepción de la protección de órdenes y la imposibilidad de volver a reproducir". [12]
El Protocolo de Seguridad de la Capa de Transporte (TLS), junto con otras plataformas básicas de seguridad de red, fue desarrollado a través de una iniciativa conjunta que comenzó en agosto de 1986, entre la Agencia de Seguridad Nacional, la Oficina Nacional de Normas, la Agencia de Comunicaciones de Defensa y doce corporaciones de comunicaciones e informáticas que iniciaron un proyecto especial llamado Sistema de Red de Datos Seguros (SDNS). [26] El programa fue descrito en septiembre de 1987 en la 10.ª Conferencia Nacional de Seguridad Informática en un amplio conjunto de artículos publicados. El innovador programa de investigación se centró en el diseño de la próxima generación de redes de comunicaciones informáticas seguras y especificaciones de productos para su implementación en aplicaciones en internets públicas y privadas. Su objetivo era complementar los nuevos estándares de internet OSI que estaban surgiendo rápidamente y que avanzaban tanto en los perfiles GOSIP del gobierno de los EE. UU. como en el enorme esfuerzo internacional de internet ITU-ISO JTC1. Originalmente conocido como protocolo SP4, fue renombrado TLS y posteriormente publicado en 1995 como estándar internacional ITU-T X.274|ISO/IEC 10736:1995.
Programación de redes seguras (SNP)
Los primeros esfuerzos de investigación en pos de 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 asemejara mucho a los sockets de Berkeley , para facilitar la modernización de aplicaciones de red preexistentes con medidas de seguridad. SNP se publicó y presentó en la Conferencia Técnica de Verano USENIX de 1994. [27] [28] El proyecto SNP fue financiado por una subvención de la NSA al profesor Simon Lam en UT-Austin en 1991. [29] Secure Network Programming ganó el premio ACM Software System Award en 2004. [30] [31] Simon Lam fue incluido en el Salón de la Fama de Internet por "inventar sockets seguros e implementar la primera capa de sockets seguros, llamada SNP, en 1993". [32] [33]
SSL 1.0, 2.0 y 3.0
Netscape desarrolló los protocolos SSL originales, y Taher Elgamal , científico jefe de Netscape Communications de 1995 a 1998, ha sido descrito como el "padre de SSL". [34] [35] [36] [37] La versión 1.0 de SSL nunca se lanzó públicamente debido a graves fallos de seguridad en el protocolo. La versión 2.0, después de ser lanzada en febrero de 1995, se descubrió rápidamente que contenía una serie de fallos de seguridad y usabilidad. Utilizaba las mismas claves criptográficas para la autenticación y el cifrado de mensajes. Tenía una construcción MAC débil que utilizaba la función hash MD5 con un prefijo secreto, lo que la hacía vulnerable a ataques de extensión de longitud. Tampoco proporcionaba protección ni para el apretón de manos de apertura ni para un cierre explícito de mensaje, lo que significaba que los ataques de intermediario podían pasar desapercibidos. Además, SSL 2.0 asumía un servicio único y un certificado de dominio fijo, lo que entraba en conflicto con la característica ampliamente utilizada de alojamiento virtual en servidores web, por lo que la mayoría de los sitios web se veían efectivamente afectados por el uso de SSL.
Estas fallas hicieron necesario un rediseño completo del protocolo a la versión SSL 3.0. [38] [36] Lanzado en 1996, fue producido por Paul Kocher en colaboración con los ingenieros de Netscape Phil Karlton y Alan Freier, con una implementación de referencia de Christopher Allen y Tim Dierks de Certicom. Las versiones más nuevas de SSL/TLS se basan en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por IETF como un documento histórico en RFC 6101.
SSL 2.0 quedó obsoleto en 2011 por RFC 6176. En 2014, se descubrió que SSL 3.0 era vulnerable al ataque POODLE que afecta a todos los cifrados de bloque en SSL; RC4 , el único cifrado no de bloque compatible con SSL 3.0, también es factiblemente vulnerado tal como se usa en SSL 3.0. [39] SSL 3.0 quedó obsoleto en junio de 2015 por RFC 7568.
TLS 1.0
TLS 1.0 se definió por primera vez en el 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 Certicom. 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 impedir 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 las apariencias ante Microsoft, "para que no pareciera que la IETF estaba simplemente aprobando el protocolo de Netscape". [40]
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. [41] [42] En octubre de 2018, Apple , Google , Microsoft y Mozilla anunciaron conjuntamente que dejarían obsoletos TLS 1.0 y 1.1 en marzo de 2020. [20] TLS 1.0 y 1.1 quedaron obsoletos formalmente en RFC 8996 en marzo de 2021.
TLS 1.1
TLS 1.1 se definió en RFC 4346 en abril de 2006. [43] Es una actualización de la versión 1.0 de TLS. Las diferencias significativas en esta versión incluyen:
Soporte para el registro de parámetros de la IANA . [44]
La compatibilidad con las versiones 1.0 y 1.1 de TLS fue ampliamente descontinuada por los sitios web alrededor de 2020, lo que deshabilitó el acceso a las versiones de Firefox anteriores a la 24 y a los navegadores basados en Chromium anteriores a la 29. [45] [46]
TLS 1.2
TLS 1.2 se definió en RFC 5246 en agosto de 2008. [23] Se basa en la especificación TLS 1.1 anterior. Las principales diferencias incluyen:
La combinación MD5 y SHA-1 en el hash del mensaje final fue reemplazada por SHA-256, con una opción para usar algoritmos hash específicos del conjunto de cifrados. Sin embargo, el tamaño del hash en el mensaje final debe seguir siendo de al menos 96 bits . [23] : §7.4.9
La combinación MD5 y SHA-1 en el elemento firmado digitalmente fue reemplazada por un único hash negociado durante el protocolo de enlace , que por defecto es SHA-1.
Mejora en la capacidad del cliente y del servidor para especificar qué hashes y algoritmos de firma aceptan.
Se agregaron la definición de extensiones TLS y conjuntos de cifrado AES. [44]
Todas las versiones de TLS se perfeccionaron en el documento RFC 6176 de marzo de 2011, eliminando su compatibilidad con SSL de modo que las sesiones TLS nunca negocien el uso de la versión 2.0 de Secure Sockets Layer (SSL). Actualmente no hay una fecha oficial para que TLS 1.2 quede obsoleto. Las especificaciones para TLS 1.2 también se redefinieron en el documento de seguimiento de estándares RFC 8446 para mantenerlo lo más seguro posible; ahora debe considerarse un protocolo de conmutación por error, destinado únicamente a negociarse con clientes que no pueden comunicarse a través de TLS 1.3 (la definición original de TLS 1.2 del RFC 5246 está obsoleta desde entonces).
TLS 1.3
TLS 1.3 se definió en RFC 8446 en agosto de 2018. [6] Se basa en la especificación TLS 1.2 anterior. Las principales diferencias con TLS 1.2 incluyen: [47]
Separación de los algoritmos de acuerdo de claves y autenticación de los conjuntos de cifrados [44] [6] : §11
Abandono del soporte para muchas características inseguras u obsoletas, incluyendo compresión , renegociación, cifrados no AEAD , cifrados nulos , [48] intercambio de claves no PFS (entre los que se encuentran los intercambios de claves RSA estáticas y DH estáticas), grupos DHE personalizados , negociación de formato de punto EC, protocolo de cambio de especificación de cifrado, tiempo UNIX de mensaje Hello y el campo de longitud de entrada AD a cifrados AEAD
Prohibición de negociación SSL o RC4 por compatibilidad con versiones anteriores
Integración del uso del hash de sesión
Desaprobar 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
Trasladar algunos detalles del algoritmo relacionados con la seguridad de un apéndice a la especificación y relegar ClientKeyShare a un apéndice
Cómo 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
Agregar compatibilidad para enviar múltiples respuestas OCSP
Cifrado de 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. [49] Posteriormente, se agregó soporte para TLS 1.3 (pero debido a problemas de compatibilidad para una pequeña cantidad de usuarios, no se habilitó automáticamente [50] ) 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 . [51]
Google Chrome estableció TLS 1.3 como la versión predeterminada por un corto tiempo en 2017. Luego lo eliminó como predeterminado, debido a middleboxes incompatibles como los proxies web de Blue Coat . [52]
La intolerancia de la nueva versión de TLS fue la osificación del protocolo ; los middleboxes habían osificado el parámetro de versión del protocolo. Como resultado, la versión 1.3 imita la imagen de cable de la versión 1.2. Este cambio se produjo muy tarde en el proceso de diseño, y solo se descubrió durante la implementación del navegador. [53] El descubrimiento de esta intolerancia también llevó a que se abandonara la estrategia de negociación de la versión anterior, en la que se elegía la versión con mayor coincidencia, debido a los niveles de osificación inviables. [54] El " engrasado " de un punto de extensión, en el que un participante del protocolo reclama soporte para extensiones inexistentes para garantizar que se toleren extensiones no reconocidas pero realmente existentes y, por lo tanto, para resistir la osificación, fue diseñado originalmente para TLS, pero desde entonces se ha adoptado en otros lugares. [54]
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 utilizar TLS 1.3. [55] [56] El grupo TLS estaba formado por personas de Japón, Reino Unido y Mauricio a través del equipo cyberstorm.mu. [56] Este trabajo continuó en el IETF 101 Hackathon en Londres , [57] y el IETF 102 Hackathon en Montreal. [58]
wolfSSL habilitó el uso de TLS 1.3 a partir de la versión 3.11.1, lanzada en mayo de 2017. [59] Como la primera implementación comercial de TLS 1.3, wolfSSL 3.11.1 admitía el borrador 18 y ahora admite el borrador 28, [60] 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. [61]
EnEl popular proyecto OpenSSL lanzó la versión 1.1.1 de su biblioteca, en la que el soporte para TLS 1.3 era "la característica principal". [62]
La Electronic Frontier Foundation elogió a TLS 1.3 y expresó su preocupación por el protocolo variante Enterprise Transport Security (ETS) que deshabilita intencionalmente importantes medidas de seguridad en TLS 1.3. [64] Originalmente llamado Enterprise TLS (eTLS), ETS es un estándar publicado conocido como ' ETSI TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". Está destinado a usarse completamente dentro de redes propietarias como 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 para facilitar la realización de auditorías. [65] [66] A pesar de los supuestos beneficios, la EFF advirtió que la pérdida del secreto hacia adelante podría facilitar la exposición de los datos y dijo que hay mejores formas de analizar el tráfico. [64]
Certificados digitales
Un certificado digital certifica la propiedad de una clave pública por parte del sujeto designado del certificado e indica ciertos usos esperados de esa clave. Esto permite que otros (partes que confían) confíen en las firmas o en las afirmaciones realizadas por la clave privada que corresponde a la clave pública certificada. Los almacenes de claves y los almacenes de confianza pueden tener varios formatos, como .pem , .crt, .pfx y .jks .
Autoridades de certificación
TLS generalmente depende de un conjunto de autoridades de certificación de terceros de confianza para establecer la autenticidad de los certificados. La confianza suele estar anclada en una lista de certificados distribuidos con software de agente de usuario [67] y puede ser modificada por la parte que confía.
Según Netcraft , que monitorea los certificados TLS activos, la autoridad de certificación (CA) líder del 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). En 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, según los recuentos de Netcraft. [68] En 2017, Symantec vendió su negocio TLS/SSL a DigiCert. [69] En un informe actualizado, se mostró que IdenTrust , DigiCert y Sectigo son las 3 principales autoridades de certificación en términos de participación de mercado desde mayo de 2019. [70]
Como consecuencia de la elección de los certificados X.509 , se necesitan autoridades de certificación y una infraestructura de clave pública 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 revelaciones de vigilancia masiva de 2013 hicieron que se conociera más ampliamente que las autoridades de certificación son un punto débil desde el punto de vista de la seguridad, ya que permiten ataques de intermediarios (MITM) si la autoridad de certificación coopera (o se ve comprometida). [71] [72]
Importancia de los certificados SSL
Cifrado : los certificados SSL cifran los datos que se envían entre un servidor web y el navegador de un usuario, lo que garantiza que la información confidencial esté protegida durante toda la transmisión. Esta tecnología de cifrado impide que terceros no autorizados intercepten e interpreten los datos, lo que los protege de posibles riesgos como la piratería o las violaciones de datos.
Autenticación : los certificados SSL también ofrecen autenticación, certificando la integridad de un sitio web y que los visitantes se están conectando al servidor correcto y no a un impostor malicioso. Este método de autenticación ayuda a los consumidores a ganar confianza al garantizar que están tratando con un sitio web seguro y confiable.
Integridad : otra función importante de los certificados SSL es garantizar la integridad de los datos. SSL utiliza técnicas criptográficas para verificar que los datos comunicados entre el servidor y el navegador estén intactos y no se hayan modificado durante el tránsito. Esto evita que actores malintencionados interfieran con los datos, lo que garantiza su integridad y fiabilidad.
Algoritmos
Intercambio de claves o acuerdo de claves
Antes de que un cliente y un servidor puedan comenzar a intercambiar información protegida por TLS, deben intercambiar o acordar de forma segura una clave de cifrado y un cifrado para usar al cifrar los datos (consulte § Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves se encuentran: claves públicas y privadas generadas con RSA (denominadas 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 efímero de curva elíptica (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon), [23] clave precompartida (TLS_PSK) [73] y contraseña remota segura (TLS_SRP). [74]
Los métodos de acuerdo de claves TLS_DH_anon y TLS_ECDH_anon no autentican al servidor ni al usuario y, por lo tanto, rara vez se utilizan porque son vulnerables a ataques de intermediarios . Solo TLS_DHE y TLS_ECDHE brindan confidencialidad hacia adelante.
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, en la solidez de la seguridad proporcionada. En julio de 2013, Google anunció que ya no utilizaría claves públicas de 1024 bits y que cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios porque la solidez del cifrado está directamente relacionada con el tamaño de la clave . [75] [76]
Cifrar
Notas
^ abcd Se debe implementar el RFC 5746 para corregir una falla de renegociación que de lo contrario rompería este protocolo.
^ Si las bibliotecas implementan las correcciones que se enumeran en RFC 5746, esto viola la especificación SSL 3.0, que el IETF no puede modificar a diferencia de TLS. La mayoría de las bibliotecas actuales implementan la corrección y hacen caso omiso de la violación que esto provoca.
^ ab 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 o el servidor lo mitiguen. Consulte el apartado Navegadores web.
^ El ataque POODLE rompe todos los cifrados de bloque (cifrados CBC) utilizados en SSL 3.0 a menos que el cliente o el servidor lo mitiguen. Consulte el apartado Navegadores web.
^ abcdefg Los cifrados AEAD (como GCM y CCM ) solo se pueden usar en TLS 1.2 o posterior.
^ abcdefgh Los cifrados CBC pueden ser atacados con el ataque Lucky Thirteen si la biblioteca no está escrita con cuidado para eliminar los canales secundarios de tiempo.
^ Aunque la longitud de la clave de 3DES es de 168 bits, la seguridad efectiva de 3DES es de solo 112 bits, [87] lo que está por debajo del mínimo recomendado de 128 bits. [88]
^ Se han eliminado IDEA y DES de TLS 1.2. [89]
^ Los conjuntos de cifrado de 40 bits de seguridad abc se diseñaron intencionalmente con longitudes de clave reducidas para cumplir con las regulaciones estadounidenses, que ya fueron derogadas y que prohíben la exportación de software criptográfico que contenga ciertos algoritmos de cifrado fuertes (consulte Exportación de criptografía desde los Estados Unidos ). Estos conjuntos débiles están prohibidos en TLS 1.1 y versiones posteriores.
^ El uso de RC4 en todas las versiones de TLS está prohibido por RFC 7465 (porque los ataques RC4 debilitan o rompen el RC4 utilizado en SSL/TLS).
En el diseño de aplicaciones, TLS generalmente se implementa sobre los protocolos de la capa de transporte, cifrando todos los datos relacionados con protocolos como HTTP , FTP , SMTP , NNTP y XMPP .
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 . [91]
Notas
^ ver § Tabla de cifrados arriba
^ Ver las secciones § Navegadores web y § Ataques contra TLS/SSL
Navegadores web
A partir de abril de 2016 [update], las últimas versiones de todos los navegadores web principales admiten TLS 1.0, 1.1 y 1.2, y los tienen habilitados de forma predeterminada. Sin embargo, no todos los sistemas operativos de Microsoft compatibles admiten la última versión de IE. Además, muchos sistemas operativos de Microsoft admiten actualmente varias versiones de IE, pero esto ha cambiado según las Preguntas frecuentes sobre la política de ciclo de vida de soporte de Internet Explorer de Microsoft Archivado el 20 de junio de 2023 en Wayback Machine , "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 enumerando 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 llegue al final de la etapa de vida útil. Desde el 15 de junio de 2022, Internet Explorer 11 dejó de ser compatible con las ediciones de Windows 10 que siguen la Política de ciclo de vida moderno de Microsoft. [95] [96]
Las mitigaciones contra ataques conocidos aún no son suficientes:
Medidas de mitigación contra ataques POODLE: algunos navegadores ya impiden la reversión a SSL 3.0; sin embargo, esta mitigación debe ser compatible no solo con los clientes sino también con los servidores. Es necesario deshabilitar SSL 3.0, implementar una "división de registros anti-POODLE" o denegar los cifrados CBC en SSL 3.0.
Google Chrome: completo (TLS_FALLBACK_SCSV está implementado 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 manera predeterminada desde la versión 40. El soporte de SSL 3.0 en sí se eliminó desde la versión 44).
Mozilla Firefox: completo (el soporte de SSL 3.0 en sí se abandonó desde la versión 39. SSL 3.0 en sí está deshabilitado de manera predeterminada y el respaldo a SSL 3.0 está deshabilitado desde la versión 34 , TLS_FALLBACK_SCSV se implementó desde la versión 35. En ESR, SSL 3.0 en sí está deshabilitado de manera predeterminada y TLS_FALLBACK_SCSV se implementó desde ESR 31.3.0.)
Internet Explorer: parcial (sólo en la versión 11, SSL 3.0 está deshabilitado por defecto desde abril de 2015. La versión 10 y anteriores siguen siendo vulnerables a 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 en sí está deshabilitado de manera predeterminada desde la versión 27. El soporte de SSL 3.0 en sí se abandonará desde la versión 31).
Safari: completo (solo en OS X 10.8 y posteriores e iOS 8, los cifrados CBC durante la transición a SSL 3.0 están denegados, pero esto significa que utilizará RC4, que tampoco se recomienda. El soporte de SSL 3.0 en sí se abandonó en OS X 10.11 y posteriores e iOS 9).
Mitigación contra ataques RC4:
Google Chrome deshabilitó RC4 excepto como respaldo desde la versión 43. RC4 está deshabilitado desde Chrome 48.
Firefox deshabilitó RC4 excepto como respaldo desde la versión 36. Firefox 44 deshabilitó RC4 de manera predeterminada.
Opera deshabilitó RC4 excepto como respaldo desde la versión 30. RC4 está deshabilitado desde Opera 35.
Internet Explorer para Windows 7 /Server 2008 R2 y para Windows 8 /Server 2012 ha establecido la prioridad de RC4 en la más baja y también puede deshabilitar RC4, excepto como una alternativa a través de la configuración del registro. Internet Explorer 11 Mobile 11 para Windows Phone 8.1 deshabilita RC4, excepto como una alternativa si no funciona ningún otro algoritmo habilitado. Edge e IE 11 deshabilitan 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 todavía es vulnerable al ataque FREAK.
Internet Explorer 11 Mobile todavía es vulnerable al ataque FREAK.
Google Chrome, Internet Explorer (computadora de escritorio), Safari (computadora de escritorio y dispositivo móvil) y Opera (dispositivo móvil) tienen implementadas mitigaciones FREAK.
Mozilla Firefox en todas las plataformas y Google Chrome en Windows no se vieron afectados por FREAK.
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.
Un artículo presentado en la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones [98] mostró que muchas aplicaciones utilizaban algunas de estas bibliotecas SSL de forma incorrecta, lo que generaba vulnerabilidades. Según los autores:
"La causa principal de la mayoría de estas vulnerabilidades es el pésimo diseño de las API de 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 entendiendo mal sus múltiples parámetros, opciones, efectos secundarios y valores de retorno".
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 cifrado y autenticación de TLS con la autorización. También ha habido un desarrollo sustancial desde fines de la década de 1990 en la creación de tecnología de cliente fuera de los navegadores web, con el fin de permitir la compatibilidad con aplicaciones cliente/servidor. En comparación con las tecnologías VPN IPsec tradicionales , TLS tiene algunas ventajas inherentes en el firewall y la travesía 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. [99]
Seguridad
Ataques contra TLS/SSL
A continuación se enumeran los ataques significativos contra TLS/SSL.
En febrero de 2015, la IETF emitió un RFC informativo [100] que resume los diversos ataques conocidos contra TLS/SSL.
Ataque de renegociación
En agosto de 2009 se descubrió una vulnerabilidad del procedimiento de renegociación que puede conducir a ataques de inyección de texto simple contra SSL 3.0 y todas las versiones actuales de TLS. [101] Por ejemplo, permite a un atacante que puede secuestrar una conexión https insertar sus propias solicitudes al comienzo de la conversación que el cliente tiene con el servidor web. 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, lo que normalmente no requerirá otros cambios a menos que se utilice la autenticación de certificado de cliente . Para solucionar 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 los protocolos de enlace anteriores en cualquier protocolo de enlace de renegociación. [102] Esta extensión se ha convertido en un estándar propuesto y se le ha asignado el número RFC 5746. El RFC ha sido implementado por varias bibliotecas. [103] [104] [105]
Ataques de degradación:Ataque FREAK yAtaque de atasco
Un ataque de degradación de protocolo (también llamado ataque de reversión de versión) engaña a un servidor web para que negocie conexiones con versiones anteriores de TLS (como SSLv2) que hace tiempo que se abandonaron por ser inseguras.
Las modificaciones previas a los protocolos originales, como False Start [106] (adoptado y habilitado por Google Chrome [107] ) o Snap Start , introdujeron ataques limitados de degradación del protocolo TLS [108] o permitieron modificaciones a la lista de conjuntos de cifrados enviada por el cliente al servidor. Al hacerlo, un atacante podría tener éxito en influir en la selección del conjunto de cifrados en un intento de degradar el conjunto de cifrados negociado para usar un algoritmo de cifrado simétrico más débil o un intercambio de claves más débil. [109] Un artículo presentado en una conferencia de ACM sobre seguridad informática y de comunicaciones en 2012 demostró que la extensión False Start estaba en riesgo: en ciertas circunstancias podría permitir a un atacante recuperar las claves de cifrado fuera de línea y acceder a los datos cifrados. [110]
Los ataques de degradación del 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 . [111] El ataque consistía en 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 usar grupos Diffie-Hellman de 512 bits "de grado de exportación" heredados de la década de 1990. [112] Obliga a los servidores susceptibles a degradarse a grupos Diffie-Hellman de 512 bits criptográficamente débiles. Un atacante puede entonces deducir las claves que el cliente y el servidor determinan utilizando el intercambio de claves Diffie-Hellman .
Ataques entre protocolos: DROWN
El ataque DROWN es un exploit que ataca a servidores que admiten conjuntos de protocolos SSL/TLS contemporáneos, explotando su compatibilidad con el protocolo SSLv2, obsoleto e inseguro, para aprovechar un ataque a conexiones que utilizan protocolos actualizados que, de otro modo, serían seguros. [113] [114] DROWN explota una vulnerabilidad en los protocolos utilizados y la configuración del servidor, en lugar de cualquier 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 de los 1 millón de sitios web más populares se encontraban entre los sitios web protegidos con TLS que eran vulnerables al ataque DROWN. [114]
Ataque de la BESTIA
El 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una prueba de concepto llamada BEAST ( Browser Exploit Against SSL/TLS ) [115] usando un applet de Java para violar las restricciones de la política del mismo origen , para una vulnerabilidad de encadenamiento de bloques de cifrado (CBC) conocida desde hace mucho tiempo en TLS 1.0: [116] [117] un atacante que observa 2 bloques de texto cifrado consecutivos C0, C1 puede probar si el bloque de texto simple P1 es igual a x eligiendo el siguiente bloque de texto simple P2 = x ⊕ C0 ⊕ C1 ; según la operación CBC, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , que será igual a C1 si x = P1 . No se habían demostrado anteriormente explotaciones prácticas para esta vulnerabilidad , que fue descubierta originalmente por Phillip Rogaway [118] en 2002. La vulnerabilidad del ataque se había solucionado con TLS 1.1 en 2006, pero TLS 1.1 no había sido ampliamente adoptado antes de esta demostración de ataque.
RC4 como cifrador de flujo es inmune a los ataques BEAST. Por lo tanto, RC4 se utilizó ampliamente como una forma de mitigar los ataques 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 recomendó habilitar RC4 en el lado del servidor. [119]
Chrome y Firefox no son vulnerables a los ataques BEAST, [120] [121] sin embargo, Mozilla actualizó sus bibliotecas NSS para mitigar ataques similares a 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. [122]
El 10 de enero de 2012, Microsoft publicó el boletín de seguridad MS12-006, que solucionó la vulnerabilidad BEAST al cambiar la forma en que el componente Windows Secure Channel ( Schannel ) transmite paquetes de red cifrados desde el extremo del servidor. [123] Los usuarios de Internet Explorer (anterior a 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 de BEAST implementando la división 1/n-1 y activándola de forma predeterminada en OS X Mavericks , lanzado el 22 de octubre de 2013. [124]
Ataques CRIME y BREACH
Los autores del ataque BEAST también son los creadores del posterior ataque CRIME , que puede permitir a un atacante recuperar el contenido de las cookies web cuando se utiliza la compresión de datos junto con TLS. [125] [126] 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.
Aunque el ataque CRIME se presentó como un ataque general que podría funcionar de manera efectiva contra una gran cantidad de protocolos, incluidos, entre otros, TLS y protocolos de capa de aplicación como SPDY o HTTP , solo se demostraron exploits contra TLS y SPDY y se mitigaron en gran medida en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, a pesar de que los autores de CRIME han advertido que esta vulnerabilidad podría estar incluso más extendida que la compresión SPDY y TLS combinadas. En 2013, se anunció una nueva instancia del ataque CRIME contra la compresión HTTP, denominada BREACH . Basado en el ataque CRIME, un ataque BREACH puede extraer tokens de inicio de sesión, direcciones de correo electrónico u otra información confidencial del tráfico web cifrado con TLS en tan solo 30 segundos (dependiendo de la cantidad de bytes que se extraigan), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso o pueda inyectar contenido en páginas válidas que el usuario esté visitando (por ejemplo, una red inalámbrica bajo el control del atacante). [127] Todas las versiones de TLS y SSL están en riesgo de BREACH independientemente del algoritmo de cifrado o la clave utilizada. [128] A diferencia de casos anteriores de CRIME, contra los que se puede defender con éxito desactivando la compresión TLS o la compresión del encabezado SPDY, BREACH explota la compresión HTTP, que no se puede desactivar de manera realista, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para los usuarios. [127] Esta es una limitación conocida de TLS, ya que es susceptible a ataques de texto simple elegido contra los datos de la capa de aplicación que se supone que debe proteger.
Algunos expertos [88] también recomendaron evitar el triple DES CBC. Dado que los últimos cifrados compatibles desarrollados para admitir cualquier programa que utilice la biblioteca SSL/TLS de Windows XP como Internet Explorer en Windows XP son RC4 y Triple-DES, y dado que RC4 ahora está obsoleto (consulte la discusión sobre los ataques RC4 ), esto dificulta la compatibilidad con cualquier versión de SSL para cualquier programa que utilice esta biblioteca en XP.
Se publicó una solución como la extensión Encrypt-then-MAC para la especificación TLS, publicada como RFC 7366. [129] El ataque Lucky Thirteen se puede mitigar en TLS 1.2 utilizando solo cifrados AES_GCM; AES_CBC sigue siendo vulnerable. SSL puede proteger el correo electrónico, VoIP y otros tipos de comunicaciones a través de redes inseguras, además de su caso de uso principal de transmisión segura de datos entre un cliente y el servidor [2]
Ataque de CANICHE
El 14 de octubre de 2014, los investigadores de Google publicaron una vulnerabilidad en el diseño de SSL 3.0 que hace que el modo de funcionamiento CBC con SSL 3.0 sea vulnerable a un ataque de relleno ( CVE - 2014-3566). A este ataque lo llamaron 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. [94]
Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayoría de los clientes y servidores admiten TLS 1.0 y versiones posteriores, todos los navegadores principales cambian voluntariamente a SSL 3.0 si fallan los protocolos de enlace con versiones más nuevas de TLS, a menos que proporcionen la opción para que un usuario o administrador deshabilite SSL 3.0 y el usuario o administrador lo haga [ cita requerida ] . Por lo tanto, el intermediario puede realizar primero un ataque de reversión de versión y luego explotar esta vulnerabilidad. [94]
El 8 de diciembre de 2014, se anunció una variante de POODLE que afecta las implementaciones de TLS que no aplican correctamente los requisitos de bytes de relleno. [130]
Ataques RC4
A pesar de la existencia de ataques a RC4 que rompieron su seguridad, las suites de cifrado en SSL y TLS que se basaban en RC4 todavía se consideraban seguras antes de 2013 en función de la forma en que se usaban en SSL y TLS. En 2011, la suite RC4 fue recomendada como una solución alternativa para el ataque BEAST . [131] 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 alternativa para BEAST. [93] AlFardan, Bernstein, Paterson, Poettering y Schuldt propusieron un escenario de ataque que utilizó sesgos estadísticos recientemente descubiertos en la tabla de claves RC4 [132] para recuperar partes del texto sin formato con una gran cantidad de cifrados TLS. [133] [134] Un ataque a RC4 en TLS y SSL que requiere cifrados 13 × 2 20 para romper RC4 fue presentado el 8 de julio de 2013 y luego descrito como "factible" en la presentación adjunta en un Simposio de Seguridad USENIX en agosto de 2013. [135] [136] En julio de 2015, mejoras posteriores en el ataque hacen que sea cada vez más práctico vencer la seguridad de TLS cifrado con RC4. [137]
Como muchos navegadores modernos han sido diseñados para derrotar los ataques BEAST (excepto Safari para Mac OS X 10.7 o anterior, para iOS 6 o anterior y para Windows; consulte el § Navegadores web), RC4 ya no es una buena opción para TLS 1.0. Los cifrados CBC que se vieron afectados por el ataque BEAST en el pasado se han convertido en una opción más popular para la protección. [88] Mozilla y Microsoft recomiendan deshabilitar RC4 siempre que sea posible. [138] [139] RFC 7465 prohíbe el uso de conjuntos de cifrados 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 deshabilitarí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. [140] [141] [142]
Ataque de truncamiento
Un ataque de truncamiento de TLS (cierre de sesión) bloquea las solicitudes de cierre de sesión de la cuenta de una víctima, de modo que el usuario permanece conectado a un servicio web sin saberlo. Cuando se envía la solicitud de cierre de sesión, el atacante inyecta un mensaje TCP FIN sin cifrar (no 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 no se da cuenta de la finalización anormal. [143]
Publicado en julio de 2013, [144] [145] el ataque hace que los servicios web como Gmail y Hotmail muestren una página que informa al usuario que ha cerrado sesión correctamente, al tiempo que garantiza que el navegador del usuario mantenga la autorización con el servicio, lo que permite que un atacante con acceso posterior al navegador acceda y tome el control de la cuenta iniciada del usuario. El ataque no se basa en la instalación de malware en la computadora de la víctima; los atacantes solo necesitan colocarse entre la víctima y el servidor web (por ejemplo, configurando un punto de acceso inalámbrico no autorizado). [143] Esta vulnerabilidad también requiere acceso a la computadora de la víctima. Otra posibilidad es que cuando se utiliza FTP, la conexión de datos puede tener un FIN falso en el flujo de datos, y si las reglas del protocolo para intercambiar alertas close_notify no se cumplen, un archivo puede truncarse.
Ataque de texto simple contra DTLS
En febrero de 2013, dos investigadores de Royal Holloway, Universidad de Londres, descubrieron un ataque de temporización [146] que les permitió recuperar (partes del) texto simple de una conexión DTLS utilizando la implementación OpenSSL o GnuTLS de DTLS cuando se utilizaba el modo de cifrado en cadena de bloques de cifrado .
Ataque impío del PAC
Este ataque, descubierto a mediados de 2016, explota 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 con TLS. [147] 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 a veces se utilizan para autenticar a los usuarios. Los servicios de intercambio de documentos, como los que ofrecen Google y Dropbox, también funcionan enviando al usuario un token de seguridad que está incluido en la URL. Un atacante que obtenga dichas URL puede obtener acceso completo a la cuenta o los datos de una víctima.
El exploit funciona contra casi todos los navegadores y sistemas operativos.
Ataque Sweet32
El ataque Sweet32 rompe todos los cifrados de bloque de 64 bits utilizados en modo CBC, tal como se utiliza en TLS, explotando un ataque de cumpleaños y un ataque de intermediario o la inyección de un código JavaScript malicioso en una página web. El objetivo del ataque de intermediario o la inyección de código JavaScript es permitir que el atacante capture suficiente tráfico para montar un ataque de cumpleaños. [148]
Errores de implementación:Insecto que sangra el corazónAtaque BERserk, error de Cloudflare
El fallo 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. [149] El fallo Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves privadas secretas asociadas con los certificados públicos utilizados para identificar a los proveedores de servicios y para cifrar el tráfico, los nombres y contraseñas de los usuarios y el contenido real. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y usuarios y suplantar servicios y usuarios. [150] La vulnerabilidad es causada por un error de sobrelectura de 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 de falsificación de firma RSA PKCS#1 v1.5 de Daniel Bleichenbacher [151] . Este ataque, denominado BERserk, es el resultado de una decodificación incompleta de la longitud ASN.1 de firmas de clave pública en algunas implementaciones de SSL y permite un ataque de intermediario falsificando una firma de clave pública. [152]
En febrero de 2015, después de que los medios de comunicación informaran sobre la preinstalación oculta del adware Superfish en algunas computadoras portátiles Lenovo, [153] un investigador descubrió que un certificado raíz confiable en las máquinas Lenovo afectadas no era seguro, ya que se podía acceder fácilmente a las claves utilizando el nombre de la empresa, Komodia, como frase de contraseña. [154] La biblioteca Komodia fue diseñada para interceptar el tráfico TLS/SSL del lado del cliente para el control y la vigilancia parental, pero también se utilizó en numerosos programas de adware, incluido Superfish, que a menudo se instalaban subrepticiamente sin el conocimiento del usuario de la computadora. A su vez, estos programas potencialmente no deseados instalaban el certificado raíz corrupto, lo que permitía a los atacantes controlar por completo el tráfico web y confirmar los sitios web falsos como auténticos.
En mayo de 2016, se informó que docenas de sitios web daneses protegidos con 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. [155] Los ataques funcionaron porque la implementación de TLS utilizada en los servidores afectados reutilizó incorrectamente números aleatorios ( nonces ) que están destinados a usarse solo una vez, lo que garantiza que cada protocolo de enlace TLS sea único. [155]
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 generó un error de desbordamiento de búfer en los servidores de Cloudflare . Este error, conocido como Cloudbleed , es similar en sus efectos al error Heartbleed descubierto en 2014 y permitió que terceros no autorizados leyeran datos en la memoria de los programas que se ejecutaban en los servidores, datos que de otro modo deberían haber estado protegidos por TLS. [156]
Encuesta sobre sitios web vulnerables a ataques
En julio de 2021 [update], el Movimiento por una Internet Confiable estimó la proporción de sitios web que son vulnerables a ataques TLS. [92]
Secreto de reenvío
Forward secrecy is a property of cryptographic systems which ensures that a session key derived from a set of public and private keys will not be compromised if one of the private keys is compromised in the future.[157] Without forward secrecy, if the server's private key is compromised, not only will all future TLS-encrypted sessions using that server certificate be compromised, but also any past sessions that used it as well (provided that these past sessions were intercepted and stored at the time of transmission).[158] An implementation of TLS can provide forward secrecy by requiring the use of ephemeral Diffie–Hellman key exchange to establish session keys, and some notable TLS implementations do so exclusively: e.g., Gmail and other Google HTTPS services that use OpenSSL.[159] However, many clients and servers supporting TLS (including browsers and web servers) are not configured to implement such restrictions.[160][161] In practice, unless a web service uses Diffie–Hellman key exchange to implement forward secrecy, all of the encrypted web traffic to and from that service can be decrypted by a third party if it obtains the server's master (private) key; e.g., by means of a court order.[162]
Even where Diffie–Hellman key exchange is implemented, server-side session management mechanisms can impact forward secrecy. The use of TLS session tickets (a TLS extension) causes the session to be protected by AES128-CBC-SHA256 regardless of any other negotiated TLS parameters, including forward secrecy ciphersuites, and the long-lived TLS session ticket keys defeat the attempt to implement forward secrecy.[163][164][165] Stanford University research in 2014 also found that of 473,802 TLS servers surveyed, 82.9% of the servers deploying ephemeral Diffie–Hellman (DHE) key exchange to support forward secrecy were using weak Diffie–Hellman parameters. These weak parameter choices could potentially compromise the effectiveness of the forward secrecy that the servers sought to provide.[166]
Since late 2011, Google has provided forward secrecy with TLS by default to users of its Gmail service, along with Google Docs and encrypted search, among other services.[167]Since November 2013, Twitter has provided forward secrecy with TLS to users of its service.[168] As of August 2019[update], about 80% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to most web browsers.[92]
TLS interception
TLS interception (or HTTPS interception if applied particularly to that protocol) is the practice of intercepting an encrypted data stream in order to decrypt it, read and possibly manipulate it, and then re-encrypt it and send the data on its way again. This is done by way of a "transparent proxy": the interception software terminates the incoming TLS connection, inspects the HTTP plaintext, and then creates a new TLS connection to the destination.[169]
TLS/HTTPS interception is used as an information security measure by network operators in order to be able to scan for and protect against the intrusion of malicious content into the network, such as computer viruses and other malware.[169] Such content could otherwise not be detected as long as it is protected by encryption, which is increasingly the case as a result of the routine use of HTTPS and other secure protocols.
A significant drawback of TLS/HTTPS interception is that it introduces new security risks of its own. One notable limitation is that it provides a point where network traffic is available unencrypted thus giving attackers an incentive to attack this point in particular in order to gain access to otherwise secure content. The interception also allows the network operator, or persons who gain access to its interception system, to perform man-in-the-middle attacks against network users. A 2017 study found that "HTTPS interception has become startlingly widespread, and that interception products as a class have a dramatically negative impact on connection security".[169]
Protocol details
The TLS protocol exchanges records, which encapsulate the data to be exchanged in a specific format (see below). Each record can be compressed, padded, appended with a message authentication code (MAC), or encrypted, all depending on the state of the connection. Each record has a content type field that designates the type of data encapsulated, a length field and a TLS version field. The data encapsulated may be control or procedural messages of the TLS itself, or simply the application data needed to be transferred by TLS. The specifications (cipher suite, keys etc.) required to exchange application data by TLS, are agreed upon in the "TLS handshake" between the client requesting the data and the server responding to requests. The protocol therefore defines both the structure of payloads transferred in TLS and the procedure to establish and monitor the transfer.
TLS handshake
When the connection starts, the record encapsulates a "control" protocol – the handshake messaging protocol (content type 22). This protocol is used to exchange all the information required by both sides for the exchange of the actual application data by TLS. It defines the format of messages and the order of their exchange. These may vary according to the demands of the client and server – i.e., there are several possible procedures to set up the connection. This initial exchange results in a successful TLS connection (both parties ready to transfer application data with TLS) or an alert message (as specified below).
Basic TLS handshake
A typical connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:
Negotiation phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID. If the client can use Application-Layer Protocol Negotiation, it may include a list of supported application protocols, such as HTTP/2.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.2 should not be selected.
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[170]
The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE, ECDHE and DH_anon cipher suites.[23]
The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data (session keys such as IV, symmetric encryption key, MAC key[171]) for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.
The client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be terminated.
Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."
The server sends its authenticated and encrypted Finished message.
The client performs the same decryption and verification procedure as the server did in the previous step.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.
Client-authenticated TLS handshake
The following full example shows a client being authenticated (in addition to the server as in the example above; see mutual authentication) via TLS using certificates exchanged between both peers.
Negotiation Phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[170]
The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE, ECDHE and DH_anon ciphersuites.[1]
The server sends a CertificateRequest message, to request a certificate from the client.
The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client responds with a Certificate message, which contains the client's certificate, but not its private key.
The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data ("session keys") for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). "The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)."
The server sends its own encrypted Finished message.
The client performs the same decryption and verification procedure as the server did in the previous step.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message.
Resumed TLS handshake
Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations: resumed sessions. Resumed sessions are implemented using session IDs or session tickets.
Apart from the performance benefit, resumed sessions can also be used for single sign-on, as it guarantees that both the original session and any resumed session originate from the same client. This is of particular importance for the FTP over TLS/SSL protocol, which would otherwise suffer from a man-in-the-middle attack in which an attacker could intercept the contents of the secondary data connections.[172]
TLS 1.3 handshake
The TLS 1.3 handshake was condensed to only one round trip compared to the two round trips required in previous versions of TLS/SSL.
To start the handshake, the client guesses which key exchange algorithm will be selected by the server and sends a ClientHello message to the server containing a list of supported ciphers (in order of the client's preference) and public keys for some or all of its key exchange guesses. If the client successfully guesses the key exchange algorithm, 1 round trip is eliminated from the handshake. After receiving the ClientHello, the server selects a cipher and sends back a ServerHello with its own public key, followed by server Certificate and Finished messages.[173]
After the client receives the server's finished message, it now is coordinated with the server on which cipher suite to use.[174]
Session IDs
In an ordinary full handshake, the server sends a session id as part of the ServerHello message. The client associates this session id with the server's IP address and TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a session id). The random data in the ClientHello and ServerHello messages virtually guarantee that the generated connection keys will be different from in the previous connection. In the RFCs, this type of handshake is called an abbreviated handshake. It is also described in the literature as a restart handshake.
Negotiation phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods. Included in the message is the session id from the previous TLS connection.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. If the server recognizes the session id sent by the client, it responds with the same session id. The client uses this to recognize that a resumed handshake is being performed. If the server does not recognize the session id sent by the client, it sends a different value for its session id. This tells the client that a resumed handshake will not be performed. At this point, both the client and server have the "master secret" and random data to generate the key data to be used for this connection.
The server now sends a ChangeCipherSpec record, essentially telling the client, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
Finally, the server sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The client will attempt to decrypt the server's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
Finally, the client sends a ChangeCipherSpec, telling the server, "Everything I tell you from now on will be encrypted."
The client sends its own encrypted Finished message.
The server performs the same decryption and verification procedure as the client did in the previous step.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message.
Session tickets
RFC 5077 extends TLS via use of session tickets, instead of session IDs. It defines a way to resume a TLS session without requiring that session-specific state is stored at the TLS server.
When using session tickets, the TLS server stores its session-specific state in a session ticket and sends the session ticket to the TLS client for storing. The client resumes a TLS session by sending the session ticket to the server, and the server resumes the TLS session according to the session-specific state in the ticket. The session ticket is encrypted and authenticated by the server, and the server verifies its validity before using its contents.
One particular weakness of this method with OpenSSL is that it always limits encryption and authentication security of the transmitted TLS session ticket to AES128-CBC-SHA256, no matter what other TLS parameters were negotiated for the actual TLS session.[164] This means that the state information (the TLS session ticket) is not as well protected as the TLS session itself. Of particular concern is OpenSSL's storage of the keys in an application-wide context (SSL_CTX), i.e. for the life of the application, and not allowing for re-keying of the AES128-CBC-SHA256 TLS session tickets without resetting the application-wide OpenSSL context (which is uncommon, error-prone and often requires manual administrative intervention).[165][163]
TLS record
This is the general format of all TLS records.
Content type
This field identifies the Record Layer Protocol Type contained in this record.
Legacy version
This field identifies the major and minor version of TLS prior to TLS 1.3 for the contained message. For a ClientHello message, this need not be the highest version supported by the client. For TLS 1.3 and later, this must to be set 0x0303 and application must send supported versions in an extra message extension block.
Length
The length of "protocol message(s)", "MAC" and "padding" fields combined (i.e. q−5), not to exceed 214 bytes (16 KiB).
Protocol message(s)
One or more messages identified by the Protocol field. Note that this field may be encrypted depending on the state of the connection.
MAC and padding
A message authentication code computed over the "protocol message(s)" field, with additional key material included. Note that this field may be encrypted, or not included entirely, depending on the state of the connection.
No "MAC" or "padding" fields can be present at end of TLS records before all cipher algorithms and parameters have been negotiated and handshaked and then confirmed by sending a CipherStateChange record (see below) for signalling that these parameters will take effect in all further records sent by the same peer.
Handshake protocol
Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record (see below), or the encryption mode of the session is modified by another record (see ChangeCipherSpec protocol below).
Message type
This field identifies the handshake message type.
Handshake message data length
This is a 3-byte field indicating the length of the handshake data, not including the header.
Note that multiple handshake messages may be combined within one record.
Alert protocol
This record should normally not be sent during normal handshaking or application exchanges. However, this message can be sent at any time during the handshake and up to the closure of the session. If this is used to signal a fatal error, the session will be closed immediately after sending this record, so this record is used to give a reason for this closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that the session is not reliable enough for its needs (before doing so, the remote may also send its own signal).
Level
This field identifies the level of alert. If the level is fatal, the sender should close the session immediately. Otherwise, the recipient may decide to terminate the session itself, by sending its own fatal alert and closing the session itself immediately after sending it. The use of Alert records is optional, however if it is missing before the session closure, the session may be resumed automatically (with its handshakes).
Normal closure of a session after termination of the transported application should preferably be alerted with at least the Close notify Alert type (with a simple warning level) to prevent such automatic resume of a new session. Signalling explicitly the normal closure of a secure session before effectively closing its transport layer is useful to prevent or detect attacks (like attempts to truncate the securely transported data, if it intrinsically does not have a predetermined length or duration that the recipient of the secured data may expect).
Description
This field identifies which type of alert is being sent.
ChangeCipherSpec protocol
CCS protocol type
Currently only 1.
Application protocol
Length
Length of application data (excluding the protocol header and including the MAC and padding trailers)
MAC
32 bytes for the SHA-256-based HMAC, 20 bytes for the SHA-1-based HMAC, 16 bytes for the MD5-based HMAC.
Padding
Variable length; last byte contains the padding length.
Support for name-based virtual servers
From the application protocol point of view, TLS belongs to a lower layer, although the TCP/IP model is too coarse to show it. This means that the TLS handshake is usually (except in the STARTTLS case) performed before the application protocol can start. In the name-based virtual server feature being provided by the application layer, all co-hosted virtual servers share the same certificate because the server has to select and send a certificate immediately after the ClientHello message. This is a big problem in hosting environments because it means either sharing the same certificate among all customers or using a different IP address for each of them.
There are two known workarounds provided by X.509:
If all virtual servers belong to the same domain, a wildcard certificate can be used.[175] Besides the loose host name selection that might be a problem or not, there is no common agreement about how to match wildcard certificates. Different rules are applied depending on the application protocol or software used.[176]
Add every virtual host name in the subjectAltName extension. The major problem being that the certificate needs to be reissued whenever a new virtual server is added.
To provide the server name, RFC 4366 Transport Layer Security (TLS) Extensions allow clients to include a Server Name Indication extension (SNI) in the extended ClientHello message. This extension hints to the server immediately which name the client wishes to connect to, so the server
can select the appropriate certificate to send to the clients.
RFC 2817 also documents a method to implement name-based virtual hosting by upgrading HTTP to TLS via an HTTP/1.1 Upgrade header. Normally this is to securely implement HTTP over TLS within the main "http" URI scheme (which avoids forking the URI space and reduces the number of used ports), however, few implementations currently support this.[citation needed]
QUIC (Quick UDP Internet Connections) – "…was designed to provide security protection equivalent to TLS/SSL"; QUIC's main goal is to improve perceived performance of connection-oriented web applications that are currently using TCP
^i.e. "Delegated Credentials for (D)TLS". Ietf. Archived from the original on 2024-06-26. Retrieved 2024-06-26.
^ a bLawrence, Scott; Khare, Rohit (May 2000). Upgrading to TLS Within HTTP/1.1. Internet Engineering Task Force. doi:10.17487/RFC2817. RFC 2817.
^"SSL/TLS in Detail". TechNet. Microsoft Docs. October 8, 2009. Archived from the original on 2022-08-13. Retrieved 2021-10-24.
^ a bHooper, Howard (2012). CCNP Security VPN 642–648 Official Cert Guide (2 ed.). Cisco Press. p. 22. ISBN 9780132966382.
^ a bSpott, Andrew; Leek, Tom; et al. "What layer is TLS?". Information Security Stack Exchange. Archived from the original on 2021-02-13. Retrieved 2017-04-13.
^ a b c d e fE. Rescorla (August 2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF TLS workgroup. doi:10.17487/RFC8446. RFC 8446. Proposed Standard. Obsoletes RFC 5077, 5246 and 6961; updates RFC 5705 and 6066.
^Rescorla, Eric; Modadugu, Nagendra (January 2012). Datagram Transport Layer Security Version 1.2. doi:10.17487/RFC6347. RFC 6347.
^Titz, Olaf (2001-04-23). "Why TCP Over TCP Is A Bad Idea". Archived from the original on 2023-03-10. Retrieved 2015-10-17.
^Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (October 2005). "Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency". In Atiquzzaman, Mohammed; Balandin, Sergey I (eds.). Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III. Vol. 6011. Bibcode:2005SPIE.6011..138H. CiteSeerX10.1.1.78.5815. doi:10.1117/12.630496. S2CID 8945952.
^RFC 4347 § 4
^Rescorla, Eric; Tschofenig, Hannes; Modadugu, Nagena (April 21, 2022). The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. doi:10.17487/RFC9147. RFC 9147.
^"AnyConnect FAQ: tunnels, reconnect behavior, and the inactivity timer". Cisco. Archived from the original on 26 February 2017. Retrieved 26 February 2017.
^"Cisco InterCloud Architectural Overview" (PDF). Cisco Systems. Archived (PDF) from the original on 2022-08-09. Retrieved 2022-11-29.
^"OpenConnect". OpenConnect. Archived from the original on 2 February 2017. Retrieved 26 February 2017.
^"ZScaler ZTNA 2.0 Tunnel". ZScaler. Archived from the original on 2022-11-29. Retrieved 2022-11-29.
^"f5 Datagram Transport Layer Security (DTLS)". f5 Networks. Archived from the original on 2022-11-29. Retrieved 2022-11-29.
^"Configuring a DTLS Virtual Server". Citrix Systems. Archived from the original on 2016-12-21. Retrieved 2022-11-29.
^"WebRTC Interop Notes". Archived from the original on 2013-05-11.
^ a b c d eBright, Peter (17 October 2018). "Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0". Archived from the original on 17 October 2018. Retrieved 17 October 2018.
^ a b c d"Here is what is new and changed in Firefox 74.0 Stable – gHacks Tech News". www.ghacks.net. 10 March 2020. Archived from the original on 2020-03-11. Retrieved 2020-03-10.
^ a b c d"TLS 1.0 and TLS 1.1 – Chrome Platform Status". chromestatus.com. Archived from the original on 2023-07-07. Retrieved 2020-03-10.
^ a b c d eT. Dierks; E. Rescorla (August 2008). The Transport Layer Security (TLS) Protocol Version 1.2. IETF TLS workgroup. doi:10.17487/RFC5246. RFC 5246. Obsolete. Obsoleted by RFC 8446; obsoletes RFC 3268, 4346 and 4366; updates RFC 4492.
^ a b"Using TLS to protect data". www.ncsc.gov.uk. Archived from the original on July 21, 2021. Retrieved August 24, 2022.
^"TLS 1.3: One Year Later". IETF. Archived from the original on July 8, 2020. Retrieved August 24, 2022.
^"Creating TLS: The Pioneering Role of Ruth Nelson". Archived from the original on 2020-06-24. Retrieved 2020-07-04.
^Woo, Thomas Y. C.; Bindignavle, Raghuram; Su, Shaowen; Lam, Simon S. (June 1994). SNP: An interface for secure network programming (PDF). Proceedings USENIX Summer Technical Conference. Archived (PDF) from the original on 2014-12-12. Retrieved 2023-07-05.
^"1994 USENIX Summer Technical Conference Program, Boston, 6–10 June 1994". Archived from the original on 6 October 2023. Retrieved 21 January 2024.
^Simon S. Lam (PI/PD), "Applying a Theory of Modules and Interfaces to Security Verification," NSA INFOSEC University Research Program grant no. MDA 904-91-C-7046, 6/28/91 to 6/27/93.
^"2004 ACM Software System Award citation". ACM. Archived from the original on 17 June 2013. Retrieved 25 July 2012.
^"ACM Press Release, March 15, 2005". ACM. Archived from the original on 10 January 2016. Retrieved 25 July 2012.
^"Internet Hall of Fame inductee Simon S. Lam". Archived from the original on 6 February 2024. Retrieved 3 Mar 2024.
^"Computer Scientist Inducted into Internet Hall of Fame". Archived from the original on 8 March 2024. Retrieved 3 Mar 2024.
^Messmer, Ellen. "Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East". Network World. Archived from the original on 31 May 2014. Retrieved 30 May 2014.
^Greene, Tim. "Father of SSL says despite attacks, the security linchpin has lots of life left". Network World. Archived from the original on 31 May 2014. Retrieved 30 May 2014.
^ a bOppliger, Rolf (2016). "Introduction". SSL and TLS: Theory and Practice (2nd ed.). Artech House. p. 13. ISBN 978-1-60807-999-5. Retrieved 2018-03-01 – via Google Books.
^"THE SSL PROTOCOL". Netscape Corporation. 2007. Archived from the original on 14 June 1997.
^Rescorla 2001
^"POODLE: SSLv3 vulnerability (CVE-2014-3566)". Archived from the original on 5 December 2014. Retrieved 21 October 2014.
^"Security Standards and Name Changes in the Browser Wars". Archived from the original on 2020-02-29. Retrieved 2020-02-29.
^Laura K. Gray (2015-12-18). "Date Change for Migrating from SSL and Early TLS". Payment Card Industry Security Standards Council blog. Archived from the original on 2015-12-20. Retrieved 2018-04-05.
^"Changes to PCI Compliance are Coming June 30. Is Your Ecommerce Business Ready?". Forbes. Archived from the original on 2018-06-21. Retrieved 2018-06-20.
^T. Dierks; E. Rescorla (April 2006). The Transport Layer Security (TLS) Protocol Version 1.1. IETF TLS workgroup. doi:10.17487/RFC4346. RFC 4346. Historic. Obsoleted by RFC 5246. Obsoletes RFC 2246.
^ a b c"Transport Layer Security Parameters – Cipher Suites". Internet Assigned Numbers Authority (IANA). Archived from the original on 2016-12-21. Retrieved 2022-12-16.
^Mackie, Kurt. "Microsoft Delays End of Support for TLS 1.0 and 1.1 -". Microsoft Certified Professional Magazine Online. Archived from the original on 2021-06-14. Retrieved 2021-06-14.
^"TLS 1.2 FAQ – Knowledge Base". Answers.psionline.com. Archived from the original on 20 February 2022. Retrieved 20 February 2022.
^"Differences between TLS 1.2 and TLS 1.3 (#TLS13)". WolfSSL. 2019-09-18. Archived from the original on 2019-09-19. Retrieved 2019-09-18.
^"Archived copy". Archived from the original on 2024-03-17. Retrieved 2024-03-17.{{cite web}}: CS1 maint: archived copy as title (link)
^"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. Archived from the original on 12 August 2018. Retrieved 10 October 2017.
^"Firefox — Notes (60.0)". Mozilla. Archived from the original on 2018-05-09. 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.
^Sullivan, Nick (2017-12-26). "Why TLS 1.3 isn't in browsers yet". The Cloudflare Blog. Archived from the original on 2017-12-26. Retrieved 2020-03-14.
^ a bThomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170.
^"TLS 1.3 IETF 100 Hackathon". Archived from the original on 2018-01-15.
^ a bIETF – Internet Engineering Task Force (2017-11-12), IETF Hackathon Presentations and Awards, archived from the original on 2021-10-28, retrieved 2017-11-14
^"Hurrah! TLS 1.3 is here. Now to implement it and put it into software". Archived from the original on 2018-03-27. Retrieved 2018-03-28.
^IETF – Internet Engineering Task Force (2018-07-15), IETF102-HACKATHON-20180715-1400, archived from the original on 2021-10-28, retrieved 2018-07-18
^"wolfSSL TLS 1.3 BETA Release Now Available". [email protected]. 11 May 2017. Archived from the original on 9 July 2018. Retrieved 11 May 2017.
^"TLS 1.3 PROTOCOL SUPPORT". [email protected]. Archived from the original on 2018-07-09. Retrieved 2018-07-09.
^"TLS 1.3 Draft 28 Support in wolfSSL". [email protected]. 14 June 2018. Archived from the original on 9 July 2018. Retrieved 14 June 2018.
^"OpenSSL 1.1.1 Is Released". Matt Caswell. 11 Sep 2018. Archived from the original on 8 December 2018. Retrieved 19 Dec 2018.
^"Protocols in TLS/SSL (Schannel SSP)". Microsoft Docs. May 25, 2022. Archived from the original on 25 January 2023. Retrieved 21 February 2023.
^ a bHoffman-Andrews, Jacob (2019-02-26). "ETS Isn't TLS and You Shouldn't Use It". Electronic Frontier Foundation. Archived from the original on 2019-02-26. 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 (PDF). ETSI.org. Archived (PDF) from the original on November 14, 2018.
^Cory Doctorow (February 26, 2019). "Monumental Recklessness". Boing Boing. Archived from the original on February 27, 2019.
^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". Archived from the original on 16 May 2015. Retrieved 20 February 2022.
^Raymond, Art (3 August 2017). "Lehi's DigiCert swallows web security competitor in $1 billion deal". Deseret News. Archived from the original on 29 September 2018. Retrieved 21 May 2020.
^"Market share trends for SSL certificate authorities". W3Techs. Retrieved 21 May 2020.
^Ryan Singel (March 24, 2010). "Law Enforcement Appliance Subverts SSL". wired.com. Archived from the original on April 12, 2014.
^Seth Schoen (March 24, 2010). "New Research Suggests That Governments May Fake SSL Certificates". EFF.org. Archived from the original on March 25, 2010.
^P. Eronen, Ed. (December 2005). Eronen, P; Tschofenig, H (eds.). Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. doi:10.17487/RFC4279. RFC 4279. Retrieved 9 September 2013.
^D. Taylor, Ed. (November 2007). Using the Secure Remote Password (SRP) Protocol for TLS Authentication. Internet Engineering Task Force. doi:10.17487/RFC5054. RFC 5054. Retrieved December 21, 2014.
^Gothard, Peter (31 July 2013). "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 e f gRFC 5830, 6986, 7091, 7801, 8891
^RFC 5288, 5289
^RFC 6655, 7251
^RFC 6367
^RFC 5932, 6367
^ a bRFC 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 cQualys SSL Labs. "SSL/TLS Deployment Best Practices". Archived from the original on 4 July 2015. Retrieved 2 June 2015.
^RFC 5469
^RFC 7905
^"Http vs https". Archived from the original on 2015-02-12. Retrieved 2015-02-12.
^ a b c dAs of May 03, 2024. "SSL Pulse: Survey of the SSL Implementation of the Most Popular Websites". Qualys. Archived from the original on 2021-03-08. Retrieved 2024-05-30.
^ a bivanr (19 March 2013). "RC4 in TLS is Broken: Now What?". Qualsys Security Labs. Archived from the original on 2013-08-27. Retrieved 2013-07-30.
^ a b cBodo 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.
^"Internet Explorer 11 has retired and is officially out of support—what you need to know". June 15, 2022. Archived from the original on 2022-06-15. Retrieved 2022-06-15.
^"Internet Explorer 11 desktop app support ended for certain versions of Windows 10". Retrieved 2022-06-17.
^"Java Secure Socket Extension (JSSE) Reference Guide". Oracle Help Center. Archived from the original on 2022-01-22. Retrieved 2021-12-24.
^Georgiev, Martin; Iyengar, Subodh; Jana, Suman; Anubhai, Rishita; Boneh, Dan; 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). Association for Computing Machinery. pp. 38–49. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2017-10-22.
^Audet, F. (2009). The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP). doi:10.17487/RFC5630. RFC 5630.
^Sheffer, Y.; Holz, R.; Saint-Andre, P. (2015). Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). doi:10.17487/RFC7457. RFC 7457.
^"CVE – CVE-2009-3555". Archived from the original on 2016-01-04.
^Rescorla, Eric (2009-11-05). "Understanding the TLS Renegotiation Attack". Educated Guesswork. Archived from the original on 2012-02-11. 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 2015-10-17. 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). Association for Computing Machinery. 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. March 2016. 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.
^Goodin, Dan (2011-09-19). "Hackers break SSL encryption used by millions of sites". The Register. Archived from the original on 2012-02-10.
^"Y Combinator comments on the issue". 2011-09-20. Archived from the original on 2012-03-31.
^"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.
^"Chrome Stable Release". Chrome Releases. 2011-10-25. Archived from the original on 2015-02-20. Retrieved 2015-02-01.
^"Attack against TLS-protected communications". Mozilla Security Blog. Mozilla. 2011-09-27. Archived from the original on 2015-03-04. Retrieved 2015-02-01.
^Smith, Brian (2011-09-30). "(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets-76)". Archived from the original on 2012-02-10. Retrieved 2011-11-01.
^MSRC (2012-01-10). Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584). Security Bulletins (Technical report). MS12-006. Retrieved 2021-10-24 – via Microsoft Docs.
^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.
^Goodin, Dan (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.
^Fisher, Dennis (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 bGoodin, 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). Internet Engineering Task Force. doi:10.17487/RFC7366. RFC 7366.
^Langley, Adam (December 8, 2014). "The POODLE bites again". Archived from the original on December 8, 2014. Retrieved 2014-12-08.
^"ssl – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune". Serverfault.com. Archived from the original on 20 February 2022. Retrieved 20 February 2022.
^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. Vol. 6544. pp. 74–91. doi:10.1007/978-3-642-19574-7_5. ISBN 978-3-642-19573-0.
^Green, Matthew (12 March 2013). "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.
^AlFardan, Nadhem; Bernstein, Dan; Paterson, Kenny; Poettering, Bertram; Schuldt, Jacob. "On the Security of RC4 in TLS". Royal Holloway University of London. Archived from the original on March 15, 2013. Retrieved March 13, 2013.
^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). Information Security Group. Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013.
^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 (15 July 2015). "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". Archived from the original on May 23, 2013. Retrieved September 2, 2015.
^Barnes, Richard (Sep 1, 2015). "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22.
^ a bJohn 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 (report). Archived from the original on 6 November 2015. Retrieved 15 February 2016.
^AlFardan, Nadhem; Paterson, Kenneth G (2012). Plaintext-recovery attacks against datagram TLS (PDF). Network and distributed system security symposium (NDSS 2012). Archived from the original on 2012-01-18.{{cite conference}}: CS1 maint: unfit URL (link)
^Goodin, Dan (26 July 2016). "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 bGoodin, Dan (26 May 2016). ""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 (February 24, 2017). "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. CiteSeerX10.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 from the original on 22 September 2013. Retrieved 20 February 2022.
^"Protecting data for the long term with forward secrecy". Archived from the original on 2013-05-06. Retrieved 2012-11-05.
^Bernat, Vincent (28 November 2011). "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 bLangley, Adam (27 June 2013). "How to botch TLS forward secrecy". imperialviolet.org. Archived from the original on 8 August 2013.
^ a bDaigniè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 bDaigniè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. CiteSeerX10.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 cDurumeric, 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. Archived from the original on 22 March 2019. Retrieved 11 March 2019.
^ a bThese 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. Archived from the original on 2020-09-22. 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.
^Rescorla, Eric (August 2018). "Cryptographic Negotiation". The Transport Layer Security (TLS) Protocol Version 1.3. IETF. sec. 4.1.1. doi:10.17487/RFC8446. RFC 8446.
^Valsorda, Filippo (23 September 2016). "An overview of TLS 1.3 and Q&A". The Cloudflare Blog. Archived from the original on 3 May 2019. Retrieved 3 May 2019.
^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
Further reading
Wikimedia Commons has media related to SSL and TLS.
Wagner, David; Schneier, Bruce (November 1996). "Analysis of the SSL 3.0 Protocol" (PDF). The Second USENIX Workshop on Electronic Commerce Proceedings. USENIX Press. pp. 29–40. Archived (PDF) from the original on 2006-10-16. Retrieved 2006-10-12.
Rescorla, Eric (2001). SSL and TLS: Designing and Building Secure Systems. United States: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
Stephen A. Thomas (2000). SSL and TLS essentials securing the Web. New York: Wiley. ISBN 978-0-471-38354-3.
Bard, Gregory (2006). "A Challenging But Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL". International Association for Cryptologic Research (136). Archived from the original on 2011-09-23. Retrieved 2011-09-23.
Canvel, Brice. "Password Interception in a SSL/TLS Channel". Archived from the original on 2016-04-20. Retrieved 2007-04-20.
RFC of change for TLS Renegotiation. 2010. doi:10.17487/RFC5746. RFC 5746.
Creating VPNs with IPsec and SSL/TLS Archived 2015-04-12 at the Wayback Machine Linux Journal article by Rami Rosen
Joshua Davies (2010). Implementing SSL/TLS. Wiley. ISBN 978-0470920411.
Polk, Tim; McKay, Kerry; Chokhani, Santosh (April 2014). "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" (PDF). National Institute of Standards and Technology. Archived from the original (PDF) on 2014-05-08. Retrieved 2014-05-07.
Abdou, AbdelRahman; van Oorschot, Paul (August 2017). "Server Location Verification (SLV) and Server Location Pinning: Augmenting TLS Authentication". ACM Transactions on Privacy and Security. 21 (1): 1:1–1:26. doi:10.1145/3139294. S2CID 5869541. Archived from the original on 2019-03-22. Retrieved 2018-01-11.
Ivan Ristic (2022). Bulletproof TLS and PKI, Second Edition. Feisty Duck. ISBN 978-1907117091.
Primary standards
The current approved version of (D)TLS is version 1.3, which are specified in:
RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
RFC 9147: "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"
The current standards replaces these former versions, which are now considered obsolete:
RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
RFC 6347: "Datagram Transport Layer Security Version 1.2"
RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".
RFC 4347" "Datagram Transport Layer Security"
RFC 2246: "The TLS Protocol Version 1.0".
RFC 6101: "The Secure Sockets Layer (SSL) Protocol Version 3.0".
Internet Draft (1995): "The SSL Protocol"
Extensions
Other RFCs subsequently extended (D)TLS.
Extensions to (D)TLS 1.3 include:
RFC 9367: "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3".
RFC 5081: "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", obsoleted by RFC 6091.
RFC 5216: "The EAP-TLS Authentication Protocol"
Extensions to TLS 1.0 include:
RFC 2595: "Using TLS with IMAP, POP3 and ACAP". Specifies an extension to the IMAP, POP3 and ACAP services that allow the server and client to use transport-layer security to provide private, authenticated communication over the Internet.
RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". The 40-bit cipher suites defined in this memo appear only for the purpose of documenting the fact that those cipher suite codes have already been assigned.
RFC 2817: "Upgrading to TLS Within HTTP/1.1", explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).
RFC 2818: "HTTP Over TLS", distinguishes secured traffic from insecure traffic by the use of a different 'server port'.
RFC 3207: "SMTP Service Extension for Secure SMTP over Transport Layer Security". Specifies an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet.
RFC 3268: "AES Ciphersuites for TLS". Adds Advanced Encryption Standard (AES) cipher suites to the previously existing symmetric ciphers.
RFC 3546: "Transport Layer Security (TLS) Extensions", adds a mechanism for negotiating protocol extensions during session initialisation and defines some extensions. Made obsolete by RFC 4366.
RFC 3749: "Transport Layer Security Protocol Compression Methods", specifies the framework for compression methods and the DEFLATE compression method.
RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", adds three sets of new cipher suites for the TLS protocol to support authentication based on pre-shared keys.
Informational RFCs
RFC 7457: "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)"
RFC 7525: "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"
External links
Internet Engineering Task Force – TLS Workgroup Archived 2014-01-11 at the Wayback Machine