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 original de DTLS 1.0 publicada 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 posterior de DTLS publicada en 2012 es una modificación de TLS 1.2. Se le asignó el número de versión de DTLS 1.2 para que coincidiera con su versión de TLS. Por último, la versión DTLS 1.3 publicada en 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 RFC 6176 en 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 verse como un protocolo de conmutación por error, destinado únicamente a ser negociado con clientes que no pueden comunicarse a través de TLS 1.3 (la definición original de RFC 5246 para TLS 1.2 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 clave 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 de Hola 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 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 enviados 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).
^ Solo autenticación, sin cifrado.
Integridad de los datos
Se utiliza un código de autenticación de mensajes (MAC) para la integridad de los datos. HMAC se utiliza para el modo CBC de cifrados de bloques. El cifrado autenticado (AEAD), como el modo GCM y CCM, utiliza MAC integrado con AEAD y no utiliza HMAC . [6] : §8.4 PRF basado en HMAC o HKDF se utiliza para el protocolo de enlace TLS.
Aplicaciones y adopción
En el diseño de aplicaciones, TLS generalmente se implementa sobre los protocolos de la capa de transporte, cifrando todos los datos relacionados con 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 y mitigaron en gran medida los exploits contra TLS y SPDY 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 mismo 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 bloques de 64 bits utilizados en el modo CBC, tal como se utiliza en TLS, mediante la explotación de 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 al atacante capturar 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 PKCS#1 v1.5 RSA Signature Forgery 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 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
El secreto hacia adelante es una propiedad de los sistemas criptográficos que garantiza que una clave de sesión derivada de un conjunto de claves públicas y privadas no se verá comprometida si una de las claves privadas se ve comprometida en el futuro. [157] Sin secreto hacia adelante, si la clave privada del servidor se ve comprometida, no solo se verán comprometidas todas las futuras sesiones cifradas con TLS que utilicen ese certificado de servidor, sino también cualquier sesión anterior que lo haya utilizado (siempre que estas sesiones anteriores se hayan interceptado y almacenado en el momento de la transmisión). [158] Una implementación de TLS puede proporcionar secreto hacia adelante al requerir el uso de un intercambio de claves Diffie-Hellman efímero para establecer claves de sesión, y algunas implementaciones notables de TLS lo hacen exclusivamente: por ejemplo, Gmail y otros servicios HTTPS de Google que utilizan OpenSSL . [159] Sin embargo, muchos clientes y servidores que admiten TLS (incluidos navegadores y servidores web) no están configurados para implementar dichas restricciones. [160] [161] En la práctica, a menos que un servicio web utilice el intercambio de claves Diffie-Hellman para implementar el secreto hacia adelante, todo el tráfico web cifrado hacia y desde ese servicio puede ser descifrado por un tercero si obtiene la clave maestra (privada) del servidor; por ejemplo, mediante una orden judicial. [162]
Incluso cuando se implementa el intercambio de claves Diffie-Hellman, los mecanismos de gestión de sesiones del lado del servidor pueden afectar la confidencialidad hacia adelante. El uso de tickets de sesión TLS (una extensión TLS) hace que la sesión esté protegida por AES128-CBC-SHA256 independientemente de cualquier otro parámetro TLS negociado, incluidos los conjuntos de cifrados de confidencialidad hacia adelante, y las claves de tickets de sesión TLS de larga duración frustran el intento de implementar la confidencialidad hacia adelante. [163] [164] [165] Una investigación de la Universidad de Stanford en 2014 también encontró que de los 473.802 servidores TLS encuestados, el 82,9% de los servidores que implementaban el intercambio de claves efímeras Diffie-Hellman (DHE) para respaldar la confidencialidad hacia adelante usaban parámetros Diffie-Hellman débiles. Estas elecciones de parámetros débiles podrían comprometer potencialmente la efectividad de la confidencialidad hacia adelante que los servidores buscaban proporcionar. [166]
Desde finales de 2011, Google ha proporcionado confidencialidad hacia adelante con TLS de forma predeterminada a los usuarios de su servicio Gmail , junto con Google Docs y la búsqueda cifrada, entre otros servicios. [167]
Desde noviembre de 2013, Twitter ha proporcionado confidencialidad hacia adelante con TLS a los usuarios de su servicio. [168] A partir de agosto de 2019 [update], aproximadamente el 80% de los sitios web habilitados para TLS están configurados para usar conjuntos de cifrado que brindan confidencialidad hacia adelante a la mayoría de los navegadores web. [92]
Interceptación de TLS
La interceptación TLS (o interceptación HTTPS si se aplica particularmente a ese protocolo) es la práctica de interceptar un flujo de datos cifrados para descifrarlos, leerlos y posiblemente manipularlos, y luego volver a cifrarlos y enviarlos nuevamente. Esto se hace por medio de un " proxy transparente ": el software de interceptación finaliza la conexión TLS entrante, inspecciona el texto simple HTTP y luego crea una nueva conexión TLS al destino. [169]
Los operadores de red utilizan la interceptación TLS/HTTPS como medida de seguridad de la información para poder escanear y protegerse contra la intrusión de contenido malicioso en la red, como virus informáticos y otro malware . [169] De lo contrario, dicho contenido no podría detectarse siempre que esté protegido por cifrado, lo que es cada vez más frecuente como resultado del uso rutinario de HTTPS y otros protocolos seguros.
Una desventaja importante de la interceptación TLS/HTTPS es que introduce nuevos riesgos de seguridad propios. Una limitación notable es que proporciona un punto en el que el tráfico de red está disponible sin cifrar, lo que da a los atacantes un incentivo para atacar este punto en particular con el fin de obtener acceso a contenido que de otro modo sería seguro. La interceptación también permite al operador de red, o a las personas que obtienen acceso a su sistema de interceptación, realizar ataques de intermediario contra los usuarios de la red. Un estudio de 2017 concluyó que "la interceptación HTTPS se ha generalizado de forma sorprendente y que los productos de interceptación como clase tienen un impacto drásticamente negativo en la seguridad de la conexión". [169]
Detalles del protocolo
El protocolo TLS intercambia registros que encapsulan los datos que se van a intercambiar en un formato específico (ver más abajo). Cada registro puede comprimirse, rellenarse, añadirse un código de autenticación de mensajes (MAC) o cifrarse, todo ello en función del estado de la conexión. Cada registro tiene un campo de tipo de contenido que designa el tipo de datos encapsulados, un campo de longitud y un campo de versión TLS. Los datos encapsulados pueden ser mensajes de control o de procedimiento del propio TLS, o simplemente los datos de aplicación que se necesitan transferir mediante TLS. Las especificaciones (conjunto de cifrados, claves, etc.) necesarias para intercambiar datos de aplicación mediante TLS se acuerdan en el "apretón de manos TLS" entre el cliente que solicita los datos y el servidor que responde a las solicitudes. Por tanto, el protocolo define tanto la estructura de las cargas útiles transferidas en TLS como el procedimiento para establecer y supervisar la transferencia.
Protocolo de enlace TLS
Cuando se inicia la conexión, el registro encapsula un protocolo de "control": el protocolo de mensajería de enlace ( tipo de contenido 22). Este protocolo se utiliza para intercambiar toda la información requerida por ambas partes para el intercambio de los datos de la aplicación real mediante TLS. Define el formato de los mensajes y el orden de su intercambio. Estos pueden variar según las demandas del cliente y del servidor, es decir, existen varios procedimientos posibles para establecer la conexión. Este intercambio inicial da como resultado una conexión TLS exitosa (ambas partes listas para transferir datos de la aplicación con TLS) o un mensaje de alerta (como se especifica a continuación).
Protocolo de enlace TLS básico
A continuación se muestra un ejemplo de conexión típico, que ilustra un protocolo de enlace en el que el servidor (pero no el cliente) está autenticado por su certificado:
El servidor responde con un mensaje ServerHello , que contiene la versión de protocolo elegida, un número aleatorio, un conjunto de cifrados y un método de compresión de entre las opciones ofrecidas por el cliente. Para confirmar o permitir la reanudación de los protocolos de enlace, el servidor puede enviar un ID de sesión . La versión de protocolo elegida debe ser la más alta que admitan tanto el cliente como el servidor. Por ejemplo, si el cliente admite la versión 1.1 de TLS y el servidor admite la versión 1.2, se debe seleccionar la versión 1.1; no se debe seleccionar la versión 1.2.
El servidor envía su mensaje de Certificado (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitir este paso). [170]
El servidor envía su mensaje ServerKeyExchange (dependiendo del conjunto de cifrados seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrados DHE , ECDHE y DH_anon. [23]
El servidor envía un mensaje ServerHelloDone , indicando que ha finalizado la negociación del protocolo de enlace.
El cliente responde con un mensaje ClientKeyExchange , que puede contener un PreMasterSecret , una clave pública o nada (de nuevo, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
El cliente y el servidor utilizan entonces los números aleatorios y PreMasterSecret para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave ( claves de sesión como IV , clave de cifrado simétrico , clave MAC [171] ) para esta conexión se derivan de este secreto maestro (y los valores aleatorios generados por el cliente y el servidor), que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada .
El cliente ahora envía un registro ChangeCipherSpec , que básicamente le dice al servidor: "Todo lo que le diga de ahora en adelante será autenticado (y encriptado si los parámetros de encriptación estaban presentes en el certificado del servidor)". El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro con un tipo de contenido de 20.
El cliente envía un mensaje Finalizado autenticado y encriptado , que contiene un hash y una MAC de los mensajes de protocolo de enlace anteriores.
El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la dirección MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y la conexión debe finalizarse.
Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente: "Todo lo que te diga de ahora en adelante será autenticado (y encriptado, si se negoció el cifrado)".
El servidor envía su mensaje Finalizado autenticado y cifrado.
El cliente realiza el mismo procedimiento de descifrado y verificación que el servidor en el paso anterior.
Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de aplicación está habilitado, con un tipo de contenido de 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también se autenticarán y, opcionalmente, se cifrarán exactamente como en su mensaje Finalizado . De lo contrario, el tipo de contenido devolverá 25 y el cliente no se autenticará.
Protocolo de enlace TLS autenticado por el cliente
El siguiente ejemplo completo muestra un cliente que se autentica (además del servidor como en el ejemplo anterior; consulte autenticación mutua ) a través de TLS utilizando certificados intercambiados entre ambos pares.
Fase de negociación:
Un cliente envía un mensaje ClientHello especificando la versión más alta del protocolo TLS que admite, un número aleatorio, una lista de conjuntos de cifrado sugeridos y métodos de compresión.
El servidor responde con un mensaje ServerHello , que contiene la versión del protocolo elegida, un número aleatorio, un conjunto de cifrados y un método de compresión entre las opciones ofrecidas por el cliente. El servidor también puede enviar un identificador de sesión como parte del mensaje para realizar un enlace reanudado.
El servidor envía su mensaje de Certificado (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitir este paso). [170]
El servidor envía su mensaje ServerKeyExchange (según el conjunto de cifrados seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrados DHE, ECDHE y DH_anon. [1]
El servidor envía un mensaje CertificateRequest para solicitar un certificado al cliente.
El servidor envía un mensaje ServerHelloDone , indicando que ha finalizado la negociación del protocolo de enlace.
El cliente responde con un mensaje de Certificado , que contiene el certificado del cliente, pero no su clave privada.
El cliente envía un mensaje ClientKeyExchange , que puede contener un PreMasterSecret , una clave pública o nada (de nuevo, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
El cliente envía un mensaje CertificateVerify , que es una firma sobre los mensajes de protocolo de enlace anteriores utilizando la clave privada del certificado del cliente. Esta firma se puede verificar utilizando la clave pública del certificado del cliente. Esto permite que el servidor sepa que el cliente tiene acceso a la clave privada del certificado y, por lo tanto, es el propietario del certificado.
El cliente y el servidor utilizan entonces los números aleatorios y PreMasterSecret para calcular un secreto común, denominado "secreto maestro". Todos los demás datos clave ("claves de sesión") para esta conexión se derivan de este secreto maestro (y de los valores aleatorios generados por el cliente y el servidor), que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada.
El cliente ahora envía un registro ChangeCipherSpec , que básicamente le dice al servidor: "Todo lo que le diga de ahora en adelante será autenticado (y encriptado si se negoció el cifrado). "El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro y tiene el tipo 20 y no 22.
Finalmente, el cliente envía un mensaje Finalizado cifrado , que contiene un hash y una MAC de los mensajes de protocolo de enlace anteriores.
El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la dirección MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y se debe interrumpir la conexión.
Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente: "Todo lo que te diga de ahora en adelante será autenticado (y encriptado si se negoció el cifrado)".
El servidor envía su propio mensaje de Finalizado cifrado.
El cliente realiza el mismo procedimiento de descifrado y verificación que el servidor en el paso anterior.
Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de aplicación está habilitado, con un tipo de contenido de 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también se cifrarán exactamente como en su mensaje Finalizado .
Se reanudó el protocolo de enlace TLS
Las operaciones de clave pública (por ejemplo, RSA) son relativamente costosas en términos de potencia computacional. TLS proporciona un atajo seguro en el mecanismo de enlace para evitar estas operaciones: sesiones reanudadas. Las sesiones reanudadas se implementan utilizando identificadores de sesión o tickets de sesión.
Además de las ventajas en términos de rendimiento, las sesiones reanudadas también se pueden utilizar para el inicio de sesión único , ya que garantiza que tanto la sesión original como cualquier sesión reanudada se originen en el mismo cliente. Esto es de particular importancia para el protocolo FTP sobre TLS/SSL , que de otro modo sufriría un ataque de intermediario en el que un atacante podría interceptar el contenido de las conexiones de datos secundarias. [172]
Protocolo de enlace TLS 1.3
El protocolo de enlace TLS 1.3 se condensó a un solo viaje de ida y vuelta en comparación con los dos viajes de ida y vuelta requeridos en versiones anteriores de TLS/SSL.
Para iniciar el protocolo de enlace, el cliente adivina qué algoritmo de intercambio de claves seleccionará el servidor y envía un mensaje ClientHello al servidor que contiene una lista de cifrados admitidos (en orden de preferencia del cliente) y claves públicas para algunas o todas sus suposiciones de intercambio de claves. Si el cliente adivina correctamente el algoritmo de intercambio de claves, se elimina 1 viaje de ida y vuelta del protocolo de enlace. Después de recibir el ClientHello , el servidor selecciona un cifrado y envía de vuelta un ServerHello con su propia clave pública, seguido de los mensajes de certificado y finalización del servidor . [173]
Una vez que el cliente recibe el mensaje terminado del servidor, ahora se coordina con el servidor qué conjunto de cifrado utilizar. [174]
ID de sesión
En un protocolo de enlace completo normal , el servidor envía un identificador de sesión como parte del mensaje ServerHello . El cliente asocia este identificador de sesión con la dirección IP y el puerto TCP del servidor, de modo que cuando el cliente se vuelva a conectar a ese servidor, pueda utilizar el identificador de sesión para acortar el protocolo de enlace. En el servidor, el identificador de sesión se asigna a los parámetros criptográficos negociados previamente, específicamente el "secreto maestro". Ambos lados deben tener el mismo "secreto maestro" o el protocolo de enlace reanudado fallará (esto evita que un espía utilice un identificador de sesión ). Los datos aleatorios en los mensajes ClientHello y ServerHello prácticamente garantizan que las claves de conexión generadas serán diferentes a las de la conexión anterior. En las RFC, este tipo de protocolo de enlace se denomina protocolo de enlace abreviado . También se describe en la literatura como protocolo de enlace de reinicio .
Fase de negociación:
Un cliente envía un mensaje ClientHello en el que especifica la versión más alta del protocolo TLS que admite, un número aleatorio, una lista de conjuntos de cifrados sugeridos y métodos de compresión. El mensaje incluye el ID de sesión de la conexión TLS anterior.
El servidor responde con un mensaje ServerHello , que contiene la versión del protocolo elegida, un número aleatorio, un conjunto de cifrados y un método de compresión de las opciones ofrecidas por el cliente. Si el servidor reconoce el id de sesión enviado por el cliente, responde con el mismo id de sesión . El cliente utiliza esto para reconocer que se está realizando un protocolo de enlace reanudado. Si el servidor no reconoce el id de sesión enviado por el cliente, envía un valor diferente para su id de sesión . Esto le indica al cliente que no se realizará un protocolo de enlace reanudado. En este punto, tanto el cliente como el servidor tienen el "secreto maestro" y los datos aleatorios para generar los datos clave que se utilizarán para esta conexión.
El servidor envía ahora un registro ChangeCipherSpec , que básicamente le dice al cliente: "Todo lo que le diga a partir de ahora será cifrado". El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro y tiene el tipo 20 y no 22.
Finalmente, el servidor envía un mensaje Finalizado cifrado , que contiene un hash y una MAC de los mensajes de protocolo de enlace anteriores.
El cliente intentará descifrar el mensaje Finalizado del servidor y verificar el hash y la dirección MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y se debe interrumpir la conexión.
Finalmente, el cliente envía un ChangeCipherSpec diciéndole al servidor: "Todo lo que te diga a partir de ahora será cifrado".
El cliente envía su propio mensaje de Finalizado cifrado .
El servidor realiza el mismo procedimiento de descifrado y verificación que el cliente en el paso anterior.
Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de aplicación está habilitado, con un tipo de contenido de 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también se cifrarán exactamente como en su mensaje Finalizado .
Entradas para la sesión
RFC 5077 amplía TLS mediante el uso de tickets de sesión, en lugar de identificadores de sesión. Define una forma de reanudar una sesión TLS sin necesidad de almacenar el estado específico de la sesión en el servidor TLS.
Al utilizar tickets de sesión, el servidor TLS almacena su estado específico de sesión en un ticket de sesión y envía el ticket de sesión al cliente TLS para su almacenamiento. El cliente reanuda una sesión TLS enviando el ticket de sesión al servidor, y el servidor reanuda la sesión TLS de acuerdo con el estado específico de la sesión en el ticket. El servidor cifra y autentica el ticket de sesión, y el servidor verifica su validez antes de utilizar su contenido.
Una debilidad particular de este método con OpenSSL es que siempre limita la seguridad de cifrado y autenticación del ticket de sesión TLS transmitido a AES128-CBC-SHA256, sin importar qué otros parámetros TLS se negociaron para la sesión TLS real. [164] Esto significa que la información de estado (el ticket de sesión TLS) no está tan bien protegida como la sesión TLS en sí. De particular preocupación es el almacenamiento de OpenSSL de las claves en un contexto de toda la aplicación ( SSL_CTX), es decir, durante la vida de la aplicación, y no permite volver a introducir las claves de los AES128-CBC-SHA256tickets de sesión TLS sin restablecer el contexto OpenSSL de toda la aplicación (lo que es poco común, propenso a errores y a menudo requiere intervención administrativa manual). [165] [163]
Registro TLS
Este es el formato general de todos los registros TLS.
Tipo de contenido
Este campo identifica el tipo de protocolo de capa de registro contenido en este registro.
Versión heredada
Este campo identifica la versión principal y secundaria de TLS anterior a TLS 1.3 para el mensaje incluido. Para un mensaje ClientHello, no es necesario que sea la versión más alta compatible con el cliente. Para TLS 1.3 y versiones posteriores, debe configurarse en 0x0303 y la aplicación debe enviar las versiones compatibles en un bloque de extensión de mensaje adicional.
Longitud
La longitud de los campos "mensaje(s) de protocolo", "MAC" y "relleno" combinados (es decir, q −5), no debe superar los 214 bytes (16 KiB).
Mensaje(s) de protocolo
Uno o más mensajes identificados por el campo Protocolo. Tenga en cuenta que este campo puede estar cifrado según el estado de la conexión.
MAC y relleno
Un código de autenticación de mensajes calculado sobre el campo "mensaje(s) de protocolo", con material de clave adicional incluido. Tenga en cuenta que este campo puede estar cifrado o no estar incluido en su totalidad, según el estado de la conexión.
No puede haber campos "MAC" o "padding" al final de los registros TLS antes de que todos los algoritmos y parámetros de cifrado se hayan negociado y aceptado y luego confirmado mediante el envío de un registro CipherStateChange (ver a continuación) para indicar que estos parámetros tendrán efecto en todos los registros posteriores enviados por el mismo par.
Protocolo de apretón de manos
La mayoría de los mensajes intercambiados durante la configuración de la sesión TLS se basan en este registro, a menos que se produzca un error o una advertencia que deba ser señalado por un registro del protocolo de alerta (ver a continuación), o el modo de cifrado de la sesión sea modificado por otro registro (ver el protocolo ChangeCipherSpec a continuación).
Tipo de mensaje
Este campo identifica el tipo de mensaje de protocolo de enlace.
Longitud de los datos del mensaje de protocolo de enlace
Este es un campo de 3 bytes que indica la longitud de los datos del protocolo de enlace, sin incluir el encabezado.
Tenga en cuenta que se pueden combinar varios mensajes de protocolo de enlace dentro de un registro.
Protocolo de alerta
Este registro normalmente no se debe enviar durante el protocolo de enlace normal o los intercambios de aplicaciones. Sin embargo, este mensaje se puede enviar en cualquier momento durante el protocolo de enlace y hasta el cierre de la sesión. Si se utiliza para señalar un error fatal, la sesión se cerrará inmediatamente después de enviar este registro, por lo que este registro se utiliza para dar una razón para este cierre. Si el nivel de alerta está marcado como advertencia, el control remoto puede decidir cerrar la sesión si decide que la sesión no es lo suficientemente confiable para sus necesidades (antes de hacerlo, el control remoto también puede enviar su propia señal).
Nivel
Este campo identifica el nivel de alerta. Si el nivel es fatal, el remitente debe cerrar la sesión inmediatamente. De lo contrario, el destinatario puede decidir terminar la sesión por sí mismo, enviando su propia alerta fatal y cerrando la sesión inmediatamente después de enviarla. El uso de registros de alerta es opcional, sin embargo, si falta antes del cierre de la sesión, la sesión puede reanudarse automáticamente (con sus protocolos de enlace).
El cierre normal de una sesión después de la finalización de la aplicación transportada debería ser alertado preferiblemente con al menos el tipo de alerta de notificación de cierre (con un nivel de advertencia simple) para evitar la reanudación automática de una nueva sesión. Señalar explícitamente el cierre normal de una sesión segura antes de cerrar efectivamente su capa de transporte es útil para prevenir o detectar ataques (como intentos de truncar los datos transportados de forma segura, si intrínsecamente no tienen una longitud o duración predeterminada que el receptor de los datos seguros pueda esperar).
Descripción
Este campo identifica qué tipo de alerta se está enviando.
Protocolo ChangeCipherSpec
Tipo de protocolo CCS
Actualmente solo 1.
Protocolo de aplicación
Longitud
Longitud de los datos de la aplicación (excluyendo el encabezado del protocolo e incluyendo los trailers MAC y de relleno)
IMPERMEABLE
32 bytes para el HMAC basado en SHA-256 , 20 bytes para el HMAC basado en SHA-1 , 16 bytes para el HMAC basado en MD5 .
Relleno
Longitud variable; el último byte contiene la longitud de relleno.
Compatibilidad con servidores virtuales basados en nombres
Desde el punto de vista del protocolo de aplicación, TLS pertenece a una capa inferior, aunque el modelo TCP/IP es demasiado burdo para mostrarlo. Esto significa que el protocolo de enlace TLS se realiza normalmente (excepto en el caso de STARTTLS ) antes de que pueda iniciarse el protocolo de aplicación. En la función de servidor virtual basado en nombre que proporciona la capa de aplicación, todos los servidores virtuales coalojados comparten el mismo certificado porque el servidor tiene que seleccionar y enviar un certificado inmediatamente después del mensaje ClientHello. Esto es un gran problema en los entornos de alojamiento porque significa compartir el mismo certificado entre todos los clientes o usar una dirección IP diferente para cada uno de ellos.
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