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 estrechamente relacionado 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 divulga en el futuro, no se puede utilizar para descifrar la sesión actual, incluso si la sesión es interceptada y grabada por un tercero.
Esto concluye el protocolo de enlace y comienza la conexión segura, que se cifra y descifra con la clave de sesión hasta que se cierra la conexión. Si alguno de los pasos anteriores falla, el protocolo de enlace TLS falla y la conexión no se crea.
TLS y SSL no encajan perfectamente en ninguna capa del modelo OSI o del modelo TCP/IP . [4] [5] TLS se ejecuta "sobre algún protocolo de transporte confiable (por ejemplo, TCP)", [6] : §1, lo que implicaría que está por encima de la capa de transporte . Proporciona cifrado a capas superiores, que normalmente es la función de la capa de presentación . Sin embargo, las aplicaciones generalmente usan TLS como si fuera una capa de transporte, [4] [5] aunque las aplicaciones que usan TLS deben controlar activamente el inicio de los protocolos de enlace TLS y el manejo de los certificados de autenticación intercambiados. [6] : §1
Cuando están protegidas por TLS, las conexiones entre un cliente (por ejemplo, un navegador web) y un servidor (por ejemplo, wikipedia.org) tendrán todas las siguientes propiedades: [6] : §1
La conexión es privada (o tiene confidencialidad ) porque se utiliza un algoritmo de clave simétrica para cifrar los datos transmitidos. Las claves para este cifrado simétrico se generan de forma única para cada conexión y se basan en un secreto compartido que se negoció al inicio de la sesión. El servidor y el cliente negocian los detalles de qué algoritmo de cifrado y claves criptográficas utilizar antes de que se transmita el primer byte de datos (ver más abajo). La negociación de un secreto compartido es a la vez segura (el secreto negociado no está disponible para los espías y no puede ser obtenido, ni siquiera por un atacante que se coloque en medio de la conexión) y fiable (ningún atacante puede modificar las comunicaciones durante la negociación sin ser detectado).
La identidad de las partes que se comunican puede autenticarse mediante criptografía de clave pública . Esta autenticación es obligatoria para el servidor y opcional para el cliente.
La conexión es confiable (o tiene integridad ) porque cada mensaje transmitido incluye una verificación de integridad del mensaje utilizando un código de autenticación de mensaje para evitar la pérdida o alteración no detectada de los datos durante la transmisión.
TLS admite muchos métodos diferentes para intercambiar claves, cifrar datos y autenticar la integridad de los mensajes. Como resultado, la configuración segura de TLS implica muchos parámetros configurables y no todas las opciones proporcionan todas las propiedades relacionadas con la privacidad descritas en la lista anterior (consulte las tablas a continuación § Intercambio de claves, § Seguridad de cifrado y § Integridad de datos).
Se han hecho intentos para subvertir aspectos de la seguridad de las comunicaciones que TLS busca proporcionar, y el protocolo ha sido revisado varias veces para abordar estas amenazas de seguridad. Los desarrolladores de navegadores web han revisado repetidamente sus productos para defenderse de posibles debilidades de seguridad después de que estas se descubrieran (consulte el historial de compatibilidad de TLS/SSL de los navegadores web).
Como el datagrama del protocolo DTLS conserva la semántica del transporte subyacente (la aplicación no sufre los retrasos asociados con los protocolos de flujo), sin embargo, la aplicación tiene que lidiar con la reordenación de paquetes , la pérdida de datagramas y datos más grandes que el tamaño de un paquete de red de datagramas . Debido a que DTLS utiliza UDP o SCTP en lugar de TCP, evita el problema de la fusión de TCP [ 9] [10] cuando se utiliza para crear un túnel VPN.
La versión 1.0 de DTLS publicada originalmente en 2006 no era un documento independiente, sino que se presentó como una serie de modificaciones de TLS 1.1. [11] De manera similar, la versión 2012 de DTLS es una modificación de TLS 1.2. Se le asignó el número de versión de DTLS 1.2 para que coincida con su versión de TLS. Por último, la versión 1.3 de DTLS de 2022 es una modificación de TLS 1.3. Al igual que las dos versiones anteriores, DTLS 1.3 tiene como objetivo proporcionar "garantías de seguridad equivalentes [a TLS 1.3] con la excepción de la protección de órdenes y la imposibilidad de volver a reproducir". [12]
El Protocolo de Seguridad de la Capa de Transporte (TLS), junto con varias otras plataformas básicas de seguridad de red, fue desarrollado a través de una iniciativa conjunta iniciada en agosto de 1986, entre la Agencia de Seguridad Nacional, la Oficina Nacional de Normas, la Agencia de Comunicaciones de Defensa y doce corporaciones de comunicaciones y computadoras 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 de Internet públicas y privadas. Su objetivo era complementar los nuevos estándares de Internet OSI que estaban surgiendo rápidamente, tanto en los perfiles GOSIP del gobierno de los EE. UU. como en el enorme esfuerzo internacional de Internet de la UIT-ISO JTC1. Originalmente conocido como protocolo SP4, se lo renombró TLS y posteriormente se publicó 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 solo 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 claves y autenticación de los conjuntos de cifrados [44] [6] : §11
Abandono del soporte para muchas características inseguras u obsoletas, incluyendo compresión , renegociación, cifrados no AEAD , cifrados nulos , [48] intercambio de claves no PFS (entre los que se encuentran los intercambios de claves RSA estáticas y DH estáticas), grupos DHE personalizados , negociación de formato de punto EC, protocolo de cambio de especificación de cifrado, tiempo UNIX de mensaje Hello y el campo de longitud de entrada AD a cifrados AEAD
Prohibición de negociación SSL o RC4 por compatibilidad con versiones anteriores
Integración del uso del hash de sesión
Desaprobar el uso del número de versión de la capa de registro y congelar el número para mejorar la compatibilidad con versiones anteriores
Trasladar algunos detalles del algoritmo relacionados con la seguridad de un apéndice a la especificación y relegar ClientKeyShare a un apéndice
Cómo agregar el cifrado de flujo ChaCha20 con el código de autenticación de mensajes Poly1305
Adición de los algoritmos de firma digital Ed25519 y Ed448
Adición de los protocolos de intercambio de claves x25519 y x448
Agregar compatibilidad para enviar múltiples respuestas OCSP
Cifrado de todos los mensajes de protocolo de enlace después de ServerHello
Network Security Services (NSS), la biblioteca de criptografía desarrollada por Mozilla y utilizada por su navegador web Firefox , habilitó TLS 1.3 de forma predeterminada en febrero de 2017. [49] Posteriormente, se agregó soporte para TLS 1.3 (pero debido a problemas de compatibilidad para una pequeña cantidad de usuarios, no se habilitó automáticamente [50] ) a Firefox 52.0 , que se lanzó en marzo de 2017. TLS 1.3 se habilitó de forma predeterminada en mayo de 2018 con el lanzamiento de Firefox 60.0 . [51]
Google Chrome estableció TLS 1.3 como la versión predeterminada por un corto tiempo en 2017. Luego lo eliminó como predeterminado, debido a middleboxes incompatibles como los proxies web de Blue Coat . [52]
La intolerancia de la nueva versión de TLS fue la osificación del protocolo ; los middleboxes habían osificado el parámetro de versión del protocolo. Como resultado, la versión 1.3 imita la imagen de cable de la versión 1.2. Este cambio se produjo muy tarde en el proceso de diseño, y solo se descubrió durante la implementación del navegador. [53] El descubrimiento de esta intolerancia también llevó a que se abandonara la estrategia de negociación de la versión anterior, en la que se elegía la versión con mayor coincidencia, debido a 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 existen mejores formas de analizar el tráfico. [64]
Certificados digitales
Ejemplo de un sitio web con certificado digital
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 maliciosos interfieran con los datos, lo que garantiza su integridad y confiabilidad.
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 clave 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 enumeradas en RFC 5746, esto viola la especificación SSL 3.0, que el IETF no puede cambiar a diferencia de TLS. La mayoría de las bibliotecas actuales implementan la corrección y hacen caso omiso de la violación que esto causa.
^ 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 § 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 [actualizar], las últimas versiones de los principales navegadores web 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". La página luego 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 simple 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 se incluye 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 modo CBC, tal como se utiliza en TLS, explotando un ataque de cumpleaños y un ataque de intermediario o la inyección de un código JavaScript malicioso en una página web. El objetivo del ataque de intermediario o la inyección de código JavaScript es permitir que el atacante capture suficiente tráfico para montar un ataque de cumpleaños. [148]
Errores de implementación:Insecto que sangra el corazónAtaque BERserk, error de Cloudflare
El fallo Heartbleed es una vulnerabilidad grave específica de la implementación de SSL/TLS en la popular biblioteca de software criptográfico OpenSSL , que afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad, informada en abril de 2014, permite a los atacantes robar claves privadas de servidores que normalmente deberían estar protegidos. [149] El fallo Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves privadas secretas asociadas con los certificados públicos utilizados para identificar a los proveedores de servicios y para cifrar el tráfico, los nombres y contraseñas de los usuarios y el contenido real. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y usuarios y suplantar servicios y usuarios. [150] La vulnerabilidad es causada por un error de sobrelectura de búfer en el software OpenSSL, en lugar de un defecto en la especificación del protocolo SSL o TLS.
En septiembre de 2014, Intel Security Advanced Threat Research anunció una variante de la vulnerabilidad de falsificación de firma RSA PKCS#1 v1.5 de Daniel Bleichenbacher [151] . Este ataque, denominado BERserk, es el resultado de una decodificación incompleta de la longitud ASN.1 de firmas de clave pública en algunas implementaciones de SSL y permite un ataque de intermediario falsificando una firma de clave pública. [152]
En febrero de 2015, después de que los medios de comunicación informaran sobre la preinstalación oculta del adware Superfish en algunas computadoras portátiles Lenovo, [153] un investigador descubrió que un certificado raíz confiable en las máquinas Lenovo afectadas no era seguro, ya que se podía acceder fácilmente a las claves utilizando el nombre de la empresa, Komodia, como frase de contraseña. [154] La biblioteca Komodia fue diseñada para interceptar el tráfico TLS/SSL del lado del cliente para el control y la vigilancia parental, pero también se utilizó en numerosos programas de adware, incluido Superfish, que a menudo se instalaban subrepticiamente sin el conocimiento del usuario de la computadora. A su vez, estos programas potencialmente no deseados instalaban el certificado raíz corrupto, lo que permitía a los atacantes controlar por completo el tráfico web y confirmar los sitios web falsos como auténticos.
En mayo de 2016, se informó que docenas de sitios web daneses protegidos con HTTPS pertenecientes a Visa Inc. eran vulnerables a ataques que permitían a los piratas informáticos inyectar código malicioso y contenido falsificado en los navegadores de los visitantes. [155] Los ataques funcionaron porque la implementación de TLS utilizada en los servidores afectados reutilizó incorrectamente números aleatorios ( nonces ) que están destinados a usarse solo una vez, lo que garantiza que cada protocolo de enlace TLS sea único. [155]
En febrero de 2017, un error de implementación causado por un solo carácter mal escrito en el código utilizado para analizar HTML generó un error de desbordamiento de búfer en los servidores de Cloudflare . Este error, conocido como Cloudbleed , es similar en sus efectos al error Heartbleed descubierto en 2014 y permitió que terceros no autorizados leyeran datos en la memoria de los programas que se ejecutaban en los servidores, datos que de otro modo deberían haber estado protegidos por TLS. [156]
Encuesta sobre sitios web vulnerables a ataques
En julio de 2021 [actualizar], 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 [actualizar], 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
Ilustración simplificada del protocolo de enlace TLS 1.2 completo con información de tiempo
Cuando se inicia la conexión, el registro encapsula un protocolo de "control": el protocolo de mensajería de 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.
Hay dos soluciones alternativas conocidas proporcionadas por X.509 :
Si todos los servidores virtuales pertenecen al mismo dominio, se puede utilizar un certificado comodín . [175] Además de la selección de nombres de host imprecisos, que puede ser un problema o no, no existe un acuerdo común sobre cómo hacer coincidir los certificados comodín. Se aplican diferentes reglas según el protocolo de aplicación o el software utilizado. [176]
Agregue cada nombre de host virtual en la extensión subjectAltName. El problema principal es que el certificado debe volver a emitirse cada vez que se agrega un nuevo servidor virtual.
Para proporcionar el nombre del servidor, las extensiones de seguridad de la capa de transporte (TLS) RFC 4366 permiten que los clientes incluyan una extensión de indicación de nombre de servidor (SNI) en el mensaje ClientHello extendido. Esta extensión indica al servidor inmediatamente a qué nombre desea conectarse el cliente, de modo que el servidor pueda seleccionar el certificado apropiado para enviar a los clientes.
QUIC (Quick UDP Internet Connections) – “…fue diseñado para proporcionar protección de seguridad equivalente a TLS/SSL”; el objetivo principal de QUIC es mejorar el rendimiento percibido de las aplicaciones web orientadas a la conexión que actualmente utilizan TCP
^ ie "Credenciales delegadas para (D)TLS". Ietf . Archivado desde el original el 2024-06-26 . Consultado el 2024-06-26 .
^ ab Lawrence, Scott; Khare, Rohit (mayo de 2000). Actualización a TLS dentro de HTTP/1.1. Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC2817 . RFC 2817.
^ "SSL/TLS en detalle". TechNet . Microsoft Docs . 8 de octubre de 2009. Archivado desde el original el 13 de agosto de 2022 . Consultado el 24 de octubre de 2021 .
^ ab Hooper, Howard (2012). Guía oficial de certificación CCNP Security VPN 642–648 (2.ª edición). Cisco Press. pág. 22. ISBN9780132966382.
^ ab Spott, Andrew; Leek, Tom; et al. "¿Qué capa es TLS?". Information Security Stack Exchange . Archivado desde el original el 2021-02-13 . Consultado el 2017-04-13 .
^ abcdef E. Rescorla (agosto de 2018). Protocolo de seguridad de la capa de transporte (TLS) versión 1.3. Grupo de trabajo TLS de la IETF . doi : 10.17487/RFC8446 . RFC 8446.Norma propuesta. Deja obsoletas las RFC 5077, 5246 y 6961; actualiza las RFC 5705 y 6066.
^ Rescorla, Eric; Modadugu, Nagendra (abril de 2006). Seguridad de la capa de transporte de datagramas. doi : 10.17487/RFC4347 . RFC 4347.
^ Rescorla, Eric; Modadugu, Nagendra (enero de 2012). Seguridad de la capa de transporte de datagramas Versión 1.2. doi : 10.17487/RFC6347 . RFC 6347.
^ Titz, Olaf (23 de abril de 2001). "Por qué TCP sobre TCP es una mala idea". Archivado desde el original el 10 de marzo de 2023. Consultado el 17 de octubre de 2015 .
^ Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (octubre de 2005). "Comprensión de TCP sobre TCP: efectos de la tunelización TCP en el rendimiento y la latencia de extremo a extremo". En Atiquzzaman, Mohammed; Balandin, Sergey I (eds.). Rendimiento, calidad de servicio y control de las redes de sensores y comunicaciones de próxima generación III . Vol. 6011. Bibcode :2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815 . doi :10.1117/12.630496. S2CID 8945952.
^ RFC 4347 § 4
^ Rescorla, Eric; Tschofenig, Hannes; Modadugu, Nagena (21 de abril de 2022). Protocolo de seguridad de la capa de transporte de datagramas (DTLS) versión 1.3. doi : 10.17487/RFC9147 . RFC 9147.
^ "Preguntas frecuentes sobre AnyConnect: túneles, comportamiento de reconexión y temporizador de inactividad". Cisco . Archivado desde el original el 26 de febrero de 2017 . Consultado el 26 de febrero de 2017 .
^ "Descripción general de la arquitectura de Cisco InterCloud" (PDF) . Cisco Systems . Archivado (PDF) del original el 2022-08-09 . Consultado el 2022-11-29 .
^ "OpenConnect". OpenConnect . Archivado desde el original el 2 de febrero de 2017 . Consultado el 26 de febrero de 2017 .
^ "Túnel ZScaler ZTNA 2.0". ZScaler . Archivado desde el original el 2022-11-29 . Consultado el 2022-11-29 .
^ "Seguridad de la capa de transporte de datagramas (DTLS) f5". f5 Networks . Archivado desde el original el 2022-11-29 . Consultado el 2022-11-29 .
^ "Configuración de un servidor virtual DTLS". Citrix Systems . Archivado desde el original el 2016-12-21 . Consultado el 2022-11-29 .
^ "Notas sobre interoperabilidad de WebRTC". Archivado desde el original el 11 de mayo de 2013.
^ abcde Bright, Peter (17 de octubre de 2018). «Apple, Google, Microsoft y Mozilla se unen para poner fin a TLS 1.0». Archivado desde el original el 17 de octubre de 2018. Consultado el 17 de octubre de 2018 .
^ abcd "Esto es lo nuevo y lo que ha cambiado en Firefox 74.0 Stable - gHacks Tech News". www.ghacks.net . 10 de marzo de 2020. Archivado desde el original el 2020-03-11 . Consultado el 2020-03-10 .
^ abcd «TLS 1.0 y TLS 1.1: estado de la plataforma Chrome». chromestatus.com . Archivado desde el original el 2023-07-07 . Consultado el 2020-03-10 .
^ abcde T. Dierks; E. Rescorla (agosto de 2008). Protocolo de seguridad de la capa de transporte (TLS) versión 1.2. Grupo de trabajo TLS de la IETF . doi : 10.17487/RFC5246 . RFC 5246.Obsoleto. Queda obsoleto por RFC 8446; deja obsoletos RFC 3268, 4346 y 4366; actualiza RFC 4492.
^ ab "Uso de TLS para proteger los datos". www.ncsc.gov.uk . Archivado desde el original el 21 de julio de 2021 . Consultado el 24 de agosto de 2022 .
^ "TLS 1.3: Un año después". IETF . Archivado desde el original el 8 de julio de 2020 . Consultado el 24 de agosto de 2022 .
^ "Creación de TLS: el papel pionero de Ruth Nelson". Archivado desde el original el 24 de junio de 2020. Consultado el 4 de julio de 2020 .
^ Woo, Thomas YC; Bindignavle, Raghuram; Su, Shaowen; Lam, Simon S. (junio de 1994). SNP: una interfaz para la programación segura de redes (PDF) . Actas de la Conferencia técnica de verano de USENIX. Archivado (PDF) desde el original el 2014-12-12 . Consultado el 2023-07-05 .
^ "Programa de la Conferencia Técnica de Verano de USENIX 1994, Boston, 6–10 de junio de 1994". Archivado desde el original el 6 de octubre de 2023. Consultado el 21 de enero de 2024 .
^ Simon S. Lam (PI/PD), "Aplicación de una teoría de módulos e interfaces a la verificación de seguridad", subvención del Programa de investigación universitaria INFOSEC de la NSA n.º MDA 904-91-C-7046, del 28/6/91 al 27/6/93.
^ "Cita del premio ACM Software System Award 2004". ACM . Archivado desde el original el 17 de junio de 2013 . Consultado el 25 de julio de 2012 .
^ "Comunicado de prensa de la ACM, 15 de marzo de 2005". ACM . Archivado desde el original el 10 de enero de 2016 . Consultado el 25 de julio de 2012 .
^ "Simon S. Lam, miembro del Salón de la Fama de Internet". Archivado desde el original el 6 de febrero de 2024. Consultado el 3 de marzo de 2024 .
^ "Científico informático incluido en el Salón de la Fama de Internet". Archivado desde el original el 8 de marzo de 2024 . Consultado el 3 de marzo de 2024 .
^ Messmer, Ellen. "El padre de SSL, el Dr. Taher Elgamal, encuentra proyectos de TI de rápido crecimiento en Oriente Medio". Network World . Archivado desde el original el 31 de mayo de 2014. Consultado el 30 de mayo de 2014 .
^ Greene, Tim. "El padre de SSL dice que, a pesar de los ataques, el eje de seguridad tiene mucha vida por delante". Network World . Archivado desde el original el 31 de mayo de 2014. Consultado el 30 de mayo de 2014 .
^ ab Oppliger, Rolf (2016). "Introducción". SSL y TLS: teoría y práctica (2.ª ed.). Artech House . p. 13. ISBN978-1-60807-999-5. Recuperado el 1 de marzo de 2018 – vía Google Books.
^ "EL PROTOCOLO SSL". Netscape Corporation. 2007. Archivado desde el original el 14 de junio de 1997.
^ Rescorla 2001
^ "POODLE: vulnerabilidad SSLv3 (CVE-2014-3566)". Archivado desde el original el 5 de diciembre de 2014 . Consultado el 21 de octubre de 2014 .
^ "Estándares de seguridad y cambios de nombre en la guerra de navegadores". Archivado desde el original el 29 de febrero de 2020. Consultado el 29 de febrero de 2020 .
^ "Los cambios en el cumplimiento de PCI se realizarán el 30 de junio. ¿Está listo su negocio de comercio electrónico?". Forbes . Archivado desde el original el 2018-06-21 . Consultado el 2018-06-20 .
^ T. Dierks; E. Rescorla (abril de 2006). Protocolo de seguridad de la capa de transporte (TLS) versión 1.1. Grupo de trabajo TLS de la IETF . doi : 10.17487/RFC4346 . RFC 4346.Histórico. Obsoleto por RFC 5246. Obsoleto por RFC 2246.
^ abc «Parámetros de seguridad de la capa de transporte: conjuntos de cifrados». Autoridad de números asignados en Internet (IANA) . Archivado desde el original el 2016-12-21 . Consultado el 2022-12-16 .
^ Mackie, Kurt. "Microsoft retrasa el fin del soporte para TLS 1.0 y 1.1 -". Revista Microsoft Certified Professional Online . Archivado desde el original el 2021-06-14 . Consultado el 2021-06-14 .
^ "Preguntas frecuentes sobre TLS 1.2: base de conocimientos". Answers.psionline.com . Archivado desde el original el 20 de febrero de 2022 . Consultado el 20 de febrero de 2022 .
^ "Diferencias entre TLS 1.2 y TLS 1.3 (#TLS13)". WolfSSL . 2019-09-18. Archivado desde el original el 2019-09-19 . Consultado el 2019-09-18 .
^ "Copia archivada". Archivado desde el original el 17 de marzo de 2024. Consultado el 17 de marzo de 2024 .{{cite web}}: CS1 maint: copia archivada como título ( enlace )
^ "Notas de la versión NSS 3.29". Mozilla Developer Network. Febrero de 2017. Archivado desde el original el 22 de febrero de 2017.
^ "Habilitar TLS 1.3 de forma predeterminada". Bugzilla@Mozilla. 16 de octubre de 2016. Archivado desde el original el 12 de agosto de 2018. Consultado el 10 de octubre de 2017 .
^ "Firefox — Notas (60.0)". Mozilla . Archivado desde el original el 2018-05-09 . Consultado el 2018-05-10 .
^ "ProxySG, ASG y WSS interrumpirán las conexiones SSL cuando los clientes que utilicen TLS 1.3 accedan a sitios que también utilicen TLS 1.3". BlueTouch Online . 16 de mayo de 2017. Archivado desde el original el 12 de septiembre de 2017 . Consultado el 11 de septiembre de 2017 .
^ Sullivan, Nick (26 de diciembre de 2017). "Por qué TLS 1.3 aún no está disponible en los navegadores". El blog de Cloudflare . Archivado desde el original el 26 de diciembre de 2017. Consultado el 14 de marzo de 2020 .
^ ab Thomson, Martin; Pauly, Tommy (diciembre de 2021). Viabilidad a largo plazo de los mecanismos de extensión de protocolos. doi : 10.17487/RFC9170 . RFC 9170.
^ "Hackatón IETF 100 sobre TLS 1.3". Archivado desde el original el 15 de enero de 2018.
^ ab IETF – Internet Engineering Task Force (2017-11-12), Presentaciones y premios del hackathon de IETF, archivado del original el 2021-10-28 , consultado el 2017-11-14
^ "¡Hurra! TLS 1.3 ya está aquí. Ahora hay que implementarlo y ponerlo en software". Archivado desde el original el 2018-03-27 . Consultado el 2018-03-28 .
^ IETF – Grupo de trabajo de ingeniería de Internet (15 de julio de 2018), IETF102-HACKATHON-20180715-1400, archivado desde el original el 28 de octubre de 2021 , consultado el 18 de julio de 2018
^ "Ya está disponible la versión BETA de wolfSSL TLS 1.3". [email protected]. 11 de mayo de 2017. Archivado desde el original el 9 de julio de 2018. Consultado el 11 de mayo de 2017 .
^ "SOPORTE DEL PROTOCOLO TLS 1.3". [email protected]. Archivado desde el original el 2018-07-09 . Consultado el 2018-07-09 .
^ "Soporte de TLS 1.3 Draft 28 en wolfSSL". [email protected]. 14 de junio de 2018. Archivado desde el original el 9 de julio de 2018 . Consultado el 14 de junio de 2018 .
^ "Se lanza OpenSSL 1.1.1". Matt Caswell. 11 de septiembre de 2018. Archivado desde el original el 8 de diciembre de 2018. Consultado el 11 de octubre de 2024 .
^ "Protocolos en TLS/SSL (Schannel SSP)". Microsoft Docs . 25 de mayo de 2022. Archivado desde el original el 25 de enero de 2023 . Consultado el 21 de febrero de 2023 .
^ ab Hoffman-Andrews, Jacob (26 de febrero de 2019). "ETS no es TLS y no deberías usarlo". Electronic Frontier Foundation . Archivado desde el original el 26 de febrero de 2019. Consultado el 27 de febrero de 2019 .
^ TS 103 523-3 – V1.1.1 – CYBER; Protocolo de seguridad de middlebox; Parte 3: Perfil para el control de acceso a redes empresariales y centros de datos ( PDF ) . ETSI .org. Archivado (PDF) del original el 14 de noviembre de 2018.
^ Cory Doctorow (26 de febrero de 2019). «Temeridad monumental». Boing Boing . Archivado desde el original el 27 de febrero de 2019.
^ Rea, Scott (2013). "Alternativas a las autoridades de certificación para una Web segura" (PDF) . RSA Conference Asia Pacific. Archivado (PDF) del original el 7 de octubre de 2016. Consultado el 7 de septiembre de 2016 .
^ "Conteo de certificados SSL". Archivado desde el original el 16 de mayo de 2015. Consultado el 20 de febrero de 2022 .
^ Raymond, Art (3 de agosto de 2017). «DigiCert de Lehi se traga a un competidor de seguridad web en un acuerdo de 1.000 millones de dólares». Deseret News . Archivado desde el original el 29 de septiembre de 2018 . Consultado el 21 de mayo de 2020 .
^ "Tendencias de participación de mercado para las autoridades de certificación SSL". W3Techs . Consultado el 21 de mayo de 2020 .
^ Ryan Singel (24 de marzo de 2010). "Un dispositivo de aplicación de la ley subvierte el protocolo SSL". wired .com . Archivado desde el original el 12 de abril de 2014.
^ Seth Schoen (24 de marzo de 2010). "Una nueva investigación sugiere que los gobiernos pueden falsificar certificados SSL". EFF .org . Archivado desde el original el 25 de marzo de 2010.
^ P. Eronen, Ed. (diciembre de 2005). Eronen, P; Tschofenig, H (eds.). Conjuntos de cifrados de clave precompartida para seguridad de la capa de transporte (TLS). Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC4279 . RFC 4279 . Consultado el 9 de septiembre de 2013 .
^ D. Taylor, Ed. (noviembre de 2007). Uso del protocolo de contraseña remota segura (SRP) para la autenticación TLS. Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC5054 . RFC 5054. Consultado el 21 de diciembre de 2014 .
^ Gothard, Peter (31 de julio de 2013). «Google actualiza los certificados SSL a un cifrado de 2048 bits». Informática . Incisive Media. Archivado desde el original el 22 de septiembre de 2013 . Consultado el 9 de septiembre de 2013 .
^ "El valor del cifrado de 2048 bits: por qué es importante la longitud de la clave de cifrado". SearchSecurity . Archivado desde el original el 16 de enero de 2018 . Consultado el 18 de diciembre de 2017 .
^ Sean Turner (17 de septiembre de 2015). «Consenso: eliminar DSA de TLS 1.3». Archivado desde el original el 3 de octubre de 2015.
^ RFC 8422
^ abcdefg RFC 5830, 6986, 7091, 7801, 8891
^ RFC 5288, 5289
^ RFC 6655, 7251
^ RFC 6367
^ RFC 5932, 6367
^ desde RFC 6209
^ RFC 4162
^ "Sobre la (in)seguridad práctica de los cifrados de bloques de 64 bits: ataques de colisión en HTTP sobre TLS y OpenVPN" (PDF) . 28 de octubre de 2016. Archivado (PDF) desde el original el 24 de abril de 2017. Consultado el 8 de junio de 2017 .
^ "Publicación especial NIST 800-57 Recomendación para la gestión de claves — Parte 1: General (revisada)" (PDF) . 2007-03-08. Archivado desde el original (PDF) el 6 de junio de 2014 . Consultado el 2014-07-03 .
^ abc Qualys SSL Labs. "Mejores prácticas de implementación de SSL/TLS". Archivado desde el original el 4 de julio de 2015 . Consultado el 2 de junio de 2015 .
^ RFC 5469
^ RFC 7905
^ "Http vs https". Archivado desde el original el 12 de febrero de 2015. Consultado el 12 de febrero de 2015 .
^ abcd Al 3 de mayo de 2024. «SSL Pulse: Encuesta sobre la implementación de SSL en los sitios web más populares». Qualys . Archivado desde el original el 8 de marzo de 2021 . Consultado el 30 de mayo de 2024 .
^ ab ivanr (19 de marzo de 2013). "RC4 en TLS está roto: ¿y ahora qué?". Qualsys Security Labs. Archivado desde el original el 27 de agosto de 2013. Consultado el 30 de julio de 2013 .
^ abc Bodo Möller, Thai Duong y Krzysztof Kotowicz. "Este CANICHE muerde: cómo aprovechar la alternativa SSL 3.0" (PDF) . Archivado (PDF) desde el original el 14 de octubre de 2014. Consultado el 15 de octubre de 2014 .
^ "Internet Explorer 11 se retiró y oficialmente no recibe soporte: lo que necesita saber". 15 de junio de 2022. Archivado desde el original el 15 de junio de 2022. Consultado el 15 de junio de 2022 .
^ "La compatibilidad de la aplicación de escritorio Internet Explorer 11 finalizó para ciertas versiones de Windows 10" . Consultado el 17 de junio de 2022 .
^ "Guía de referencia de la extensión de sockets seguros de Java (JSSE)". Centro de ayuda de Oracle . Archivado desde el original el 22 de enero de 2022 . Consultado el 24 de diciembre de 2021 .
^ Georgiev, Martin; Iyengar, Subodh; Jana, Suman; Anubhai, Rishita; Boneh, Dan; Shmatikov, Vitaly (2012). El código más peligroso del mundo: validación de certificados SSL en software que no sea de navegador. Actas de la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones (PDF) . Association for Computing Machinery. págs. 38–49. ISBN978-1-4503-1651-4. Archivado (PDF) del original el 22 de octubre de 2017.
^ Audet, F. (2009). El uso del esquema URI SIPS en el protocolo de inicio de sesión (SIP). doi : 10.17487/RFC5630 . RFC 5630.
^ Sheffer, Y.; Holz, R.; Saint-Andre, P. (2015). Resumen de ataques conocidos a la seguridad de la capa de transporte (TLS) y a la TLS de datagramas (DTLS). doi : 10.17487/RFC7457 . RFC 7457.
^ "CVE – CVE-2009-3555". Archivado desde el original el 4 de enero de 2016.
^ Rescorla, Eric (5 de noviembre de 2009). "Understanding the TLS Renegotiation Attack" (Comprender el ataque de renegociación de TLS). Conjeturas fundamentadas . Archivado desde el original el 11 de febrero de 2012. Consultado el 27 de noviembre de 2009 .
^ "SSL_CTX_set_options SECURE_RENEGOTIATION". Documentos de OpenSSL . 25 de febrero de 2010. Archivado desde el original el 26 de noviembre de 2010. Consultado el 18 de noviembre de 2010 .
^ "Lanzamiento de GnuTLS 2.10.0". Notas de lanzamiento de GnuTLS . 2010-06-25. Archivado desde el original el 2015-10-17 . Consultado el 2011-07-24 .
^ "Notas de la versión NSS 3.12.6". Notas de la versión NSS . 2010-03-03. Archivado desde el original el 6 de marzo de 2012 . Consultado el 24 de julio de 2011 .
^ A. Langley; N. Modadugu; B. Moeller (2010-06-02). "Transport Layer Security (TLS) False Start" (Comienzo en falso de la seguridad de la capa de transporte [TLS]). Grupo de trabajo de ingeniería de Internet . IETF. Archivado desde el original el 2013-09-05 . Consultado el 2013-07-31 .
^ Gruener, Wolfgang. "Falso comienzo: Google propone una Web más rápida, Chrome ya la soporta". Archivado desde el original el 2010-10-07 . Consultado el 2011-03-09 .
^ Smith, Brian. "Ataques de reversión limitados en False Start y Snap Start". Archivado desde el original el 4 de mayo de 2011. Consultado el 9 de marzo de 2011 .
^ Dimcev, Adrian. "False Start". Introducción a SSL/TLS aleatorio . Archivado desde el original el 4 de mayo de 2011. Consultado el 9 de marzo de 2011 .
^ Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). Un ataque entre protocolos al protocolo TLS. Actas de la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones (PDF) . Association for Computing Machinery. págs. 62–72. ISBN978-1-4503-1651-4. Archivado (PDF) del original el 6 de julio de 2015.
^ "SMACK: Ataques de máquinas de estado". Archivado desde el original el 12 de marzo de 2015.
^ Goodin, Dan (20 de mayo de 2015). "Un ataque que paraliza el protocolo HTTPS amenaza a decenas de miles de servidores web y de correo". Ars Technica . Archivado desde el original el 19 de mayo de 2017.
^ Leyden, John (1 de marzo de 2016). «Un tercio de todos los sitios web HTTPS están expuestos a ataques DROWN». The Register . Archivado desde el original el 1 de marzo de 2016. Consultado el 2 de marzo de 2016 .
^ ab "Más de 11 millones de sitios web HTTPS en peligro por un nuevo ataque de descifrado". Ars Technica . Marzo de 2016. Archivado desde el original el 2016-03-01 . Consultado el 2016-03-02 .
^ Thai Duong y Juliano Rizzo (13 de mayo de 2011). "Aquí vienen los ⊕ Ninjas". Archivado desde el original el 3 de junio de 2014.
^ Goodin, Dan (19 de septiembre de 2011). "Los piratas informáticos rompen el cifrado SSL utilizado por millones de sitios". The Register . Archivado desde el original el 10 de febrero de 2012.
^ "Comentarios de Y Combinator sobre el tema". 20 de septiembre de 2011. Archivado desde el original el 31 de marzo de 2012.
^ "Seguridad de los conjuntos de cifrados CBC en SSL/TLS: problemas y contramedidas". 20 de mayo de 2004. Archivado desde el original el 30 de junio de 2012.
^ Ristic, Ivan (10 de septiembre de 2013). "¿BEAST sigue siendo una amenaza?". Archivado desde el original el 12 de octubre de 2014. Consultado el 8 de octubre de 2014 .
^ "Lanzamiento estable de Chrome". Lanzamientos de Chrome . 25 de octubre de 2011. Archivado desde el original el 20 de febrero de 2015. Consultado el 1 de febrero de 2015 .
^ "Ataque contra comunicaciones protegidas por TLS". Blog de seguridad de Mozilla . Mozilla. 27 de septiembre de 2011. Archivado desde el original el 4 de marzo de 2015. Consultado el 1 de febrero de 2015 .
^ Smith, Brian (30 de septiembre de 2011). «(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitado por websockets-76)». Archivado desde el original el 10 de febrero de 2012. Consultado el 1 de noviembre de 2011 .
^ MSRC (10 de enero de 2012). Vulnerabilidad en SSL/TLS podría permitir la divulgación de información (2643584). Boletines de seguridad (informe técnico). MS12-006 . Consultado el 24 de octubre de 2021 a través de Microsoft Docs .
^ Ristic, Ivan (31 de octubre de 2013). «Apple habilitó mitigaciones de BEAST en OS X 10.9 Mavericks». Archivado desde el original el 12 de octubre de 2014. Consultado el 8 de octubre de 2014 .
^ Goodin, Dan (13 de septiembre de 2012). "Una grieta en los cimientos de la confianza en Internet permite el secuestro de sesiones HTTPS". Ars Technica . Archivado desde el original el 1 de agosto de 2013. Consultado el 31 de julio de 2013 .
^ Fisher, Dennis (13 de septiembre de 2012). "Ataque CRIME utiliza la relación de compresión de las solicitudes TLS como canal lateral para secuestrar sesiones seguras". ThreatPost. Archivado desde el original el 15 de septiembre de 2012. Consultado el 13 de septiembre de 2012 .
^ ab Goodin, Dan (1 de agosto de 2013). «Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages» (Desapareció en 30 segundos: un nuevo ataque extrae secretos de páginas protegidas con HTTPS). Ars Technica . Condé Nast. Archivado desde el original el 3 de agosto de 2013. Consultado el 2 de agosto de 2013 .
^ Leyden, John (2 de agosto de 2013). «Step into the BREACH: New attack developed to read encrypted web data» (Entra en la brecha: se ha desarrollado un nuevo ataque para leer datos web cifrados). The Register . Archivado desde el original el 5 de agosto de 2013. Consultado el 2 de agosto de 2013 .
^ P. Gutmann (septiembre de 2014). Cifrado y luego MAC para seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS). Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC7366 . RFC 7366.
^ Langley, Adam (8 de diciembre de 2014). «El CANICHE vuelve a morder». Archivado desde el original el 8 de diciembre de 2014. Consultado el 8 de diciembre de 2014 .
^ "ssl – ¿Cuáles son los cifrados más seguros para usar con BEAST? (Explotación de TLS 1.0) He leído que RC4 es inmune". Serverfault.com . Archivado desde el original el 20 de febrero de 2022 . Consultado el 20 de febrero de 2022 .
^ Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). "Descubrimiento y explotación de nuevos sesgos en RC4". En Alex Biryukov; Guang Gong ; Douglas R. Stinson (eds.). Selected Areas in Cryptography: 17th International Workshop, SAC 2010, Waterloo, Ontario, Canadá, 12-13 de agosto de 2010, Documentos revisados seleccionados . Notas de clase en informática. Vol. 6544. págs. 74-91. doi :10.1007/978-3-642-19574-7_5. ISBN978-3-642-19573-0.
^ Green, Matthew (12 de marzo de 2013). "Ataque de la semana: RC4 está un poco roto en TLS". Ingeniería criptográfica . Archivado desde el original el 14 de marzo de 2013. Consultado el 12 de marzo de 2013 .
^ AlFardan, Nadhem; Bernstein, Dan; Paterson, Kenny; Poettering, Bertram; Schuldt, Jacob. "Sobre la seguridad de RC4 en TLS". Royal Holloway University of London. Archivado desde el original el 15 de marzo de 2013. Consultado el 13 de marzo de 2013 .
^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob CN (8 de julio de 2013). "Sobre la seguridad de RC4 en TLS y WPA" (PDF) . Information Security Group . Archivado (PDF) desde el original el 22 de septiembre de 2013 . Consultado el 2 de septiembre de 2013 .
^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob CN (15 de agosto de 2013). Sobre la seguridad de RC4 en TLS (PDF) . 22.º Simposio de seguridad de USENIX . p. 51. Archivado (PDF) del original el 22 de septiembre de 2013 . Consultado el 2 de septiembre de 2013 . Los ataques de recuperación de texto simple contra RC4 en TLS son factibles aunque no verdaderamente prácticos
^ Goodin, Dan (15 de julio de 2015). «Un ataque criptográfico contra HTTPS, que antes era teórico, ahora roza la posibilidad de ser práctico». Ars Technical . Conde Nast. Archivado desde el original el 16 de julio de 2015 . Consultado el 16 de julio de 2015 .
^ "Configuraciones recomendadas de TLS del lado del servidor de seguridad de Mozilla". Mozilla. Archivado desde el original el 2015-01-03 . Consultado el 2015-01-03 .
^ "Aviso de seguridad 2868725: recomendación para deshabilitar RC4". Microsoft. 12 de noviembre de 2013. Archivado desde el original el 18 de noviembre de 2013. Consultado el 4 de diciembre de 2013 .
^ "Fin del soporte para el cifrado RC4 en Microsoft Edge e Internet Explorer 11". Equipo Microsoft Edge. 1 de septiembre de 2015. Archivado desde el original el 2 de septiembre de 2015.
^ Langley, Adam (1 de septiembre de 2015). «Intent to deprecate: RC4». Archivado desde el original el 23 de mayo de 2013. Consultado el 2 de septiembre de 2015 .
^ Barnes, Richard (1 de septiembre de 2015). "Intent to ship: RC4 deshabilitado de forma predeterminada en Firefox 44". Archivado desde el original el 22 de enero de 2011.
^ por John Leyden (1 de agosto de 2013). "Gmail, Outlook.com y el voto electrónico 'pwned' on stage in crypto-dodge hack". The Register . Archivado desde el original el 1 de agosto de 2013. Consultado el 1 de agosto de 2013 .
^ "BlackHat USA Briefings". Black Hat 2013. Archivado desde el original el 30 de julio de 2013. Consultado el 1 de agosto de 2013 .
^ Smyth, Ben; Pironti, Alfredo (2013). Truncando conexiones TLS para violar creencias en aplicaciones web. 7º Taller USENIX sobre tecnologías ofensivas (informe). Archivado desde el original el 6 de noviembre de 2015 . Consultado el 15 de febrero de 2016 .
^ AlFardan, Nadhem; Paterson, Kenneth G (2012). Ataques de recuperación de texto simple contra datagramas TLS (PDF) . Simposio sobre seguridad de redes y sistemas distribuidos (NDSS 2012). Archivado desde el original el 18 de enero de 2012.{{cite conference}}: CS1 maint: unfit URL (link)
^ Goodin, Dan (26 de julio de 2016). «Nuevo ataque elude la protección HTTPS en Mac, Windows y Linux». Ars Technica . Condé Nast. Archivado desde el original el 27 de julio de 2016 . Consultado el 28 de julio de 2016 .
^ Goodin, Dan (24 de agosto de 2016). «HTTPS y OpenVPN se enfrentan a un nuevo ataque que puede descifrar cookies secretas». Ars Technica . Archivado desde el original el 24 de agosto de 2016. Consultado el 24 de agosto de 2016 .
^ "¿Por qué se le llama 'el virus del sangrado del corazón'?". The Washington Post . 9 de abril de 2014. Archivado desde el original el 9 de octubre de 2014.
^ "Vulnerabilidad de Heartbleed Bug [9 de abril de 2014]". Comodo Group . Archivado desde el original el 5 de julio de 2014.
^ Bleichenbacher, Daniel (agosto de 2006). "Falsificación de firma RSA de Bleichenbacher basada en un error de implementación". Archivado desde el original el 16 de diciembre de 2014.
^ "BERserk". Intel Security: Advanced Threat Research. Septiembre de 2014. Archivado desde el original el 12 de enero de 2015.
^ Goodin, Dan (19 de febrero de 2015). «Las computadoras Lenovo se entregan con adware de tipo man-in-the-middle que interrumpe las conexiones HTTPS». Ars Technica . Archivado desde el original el 12 de septiembre de 2017. Consultado el 10 de diciembre de 2017 .
^ Valsorda, Filippo (20 de febrero de 2015). "La validación SSL de Komodia/Superfish no funciona". Filippo.io. Archivado desde el original el 24 de febrero de 2015.
^ ab Goodin, Dan (26 de mayo de 2016). «Un «ataque prohibido» hace que decenas de sitios Visa HTTPS sean vulnerables a la manipulación». Ars Technica . Archivado desde el original el 26 de mayo de 2016 . Consultado el 26 de mayo de 2016 .
^ Clark Estes, Adam (24 de febrero de 2017). "Todo lo que necesita saber sobre Cloudbleed, el último desastre de seguridad en Internet". Gizmodo . Archivado desde el original el 25 de febrero de 2017. Consultado el 24 de febrero de 2017 .
^ Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (junio de 1992). "Autenticación e intercambios de claves autenticadas". Diseños, códigos y criptografía . 2 (2): 107–125. CiteSeerX 10.1.1.59.6682 . doi :10.1007/BF00124891. S2CID 7356608. Archivado desde el original el 13 de marzo de 2008 . Consultado el 11 de febrero de 2008 .
^ "Discusión en la lista de correo de TLS en octubre de 2007". Archivado desde el original el 22 de septiembre de 2013. Consultado el 20 de febrero de 2022 .
^ "Protección de datos a largo plazo mediante el secreto hacia delante". Archivado desde el original el 6 de mayo de 2013. Consultado el 5 de noviembre de 2012 .
^ Bernat, Vincent (28 de noviembre de 2011). «SSL/TLS y Perfect Forward Secrecy». Archivado desde el original el 27 de agosto de 2012. Consultado el 5 de noviembre de 2012 .
^ "SSL Labs: Implementación de la confidencialidad avanzada". Qualys.com. 25 de junio de 2013. Archivado desde el original el 26 de junio de 2013. Consultado el 10 de julio de 2013 .
^ Ristic, Ivan (5 de agosto de 2013). "SSL Labs: Implementación de confidencialidad avanzada". Qualsys. Archivado desde el original el 20 de septiembre de 2013. Consultado el 31 de agosto de 2013 .
^ ab Langley, Adam (27 de junio de 2013). "Cómo arruinar el secreto de reenvío de TLS". imperialviolet.org . Archivado desde el original el 8 de agosto de 2013.
^ de Daignière, Florent. "TLS "Secrets": Whitepaper presentando las implicaciones de seguridad de la implementación de tickets de sesión (RFC 5077) tal como se implementa en OpenSSL" (PDF) . Matta Consulting Limited. Archivado (PDF) del original el 6 de agosto de 2013 . Consultado el 7 de agosto de 2013 .
^ de Daignière, Florent. "TLS "Secrets": What everybody forgot to tell you…" (PDF) . Matta Consulting Limited. Archivado (PDF) del original el 5 de agosto de 2013. Consultado el 7 de agosto de 2013 .
^ LS Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "Un estudio experimental de implementaciones de confidencialidad directa TLS". IEEE Internet Computing . 18 (6): 43–51. CiteSeerX 10.1.1.663.4653 . doi :10.1109/MIC.2014.86. S2CID 11264303. Archivado desde el original el 20 de septiembre de 2015 . Consultado el 16 de octubre de 2015 .
^ "Protección de datos a largo plazo mediante el secreto hacia delante". Archivado desde el original el 12 de febrero de 2014. Consultado el 7 de marzo de 2014 .
^ Hoffman-Andrews, Jacob. "Secreto de reenvío en Twitter". Twitter. Archivado desde el original el 16 de febrero de 2014. Consultado el 7 de marzo de 2014 .
^ abc Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 de septiembre de 2017). "El impacto de la interceptación HTTPS en la seguridad". Simposio NDSS . doi :10.14722/ndss.2017.23456. ISBN .978-1-891562-46-4Archivado desde el original el 22 de marzo de 2019 . Consultado el 11 de marzo de 2019 .
^ ab Estos certificados actualmente son X.509 , pero RFC 6091 también especifica el uso de certificados basados en OpenPGP .
^ "tls – ¿Diferencias entre los términos "secreto pre-master", "secreto maestro", "clave privada" y "secreto compartido"?". Cryptography Stack Exchange . Archivado desde el original el 2020-09-22 . Consultado el 2020-10-01 .
^ Chris (18 de febrero de 2009). «vsftpd-2.1.0 publicado: uso de reanudación de sesión TLS para autenticación de conexión de datos FTPS». Scarybeastsecurity. blogspot.com. Archivado desde el original el 7 de julio de 2012. Consultado el 17 de mayo de 2012 .
^ Rescorla, Eric (agosto de 2018). "Negociación criptográfica". Protocolo de seguridad de la capa de transporte (TLS), versión 1.3. IETF. sección 4.1.1. doi : 10.17487/RFC8446 . RFC 8446.
^ Valsorda, Filippo (23 de septiembre de 2016). «Una descripción general de TLS 1.3 y preguntas y respuestas». El blog de Cloudflare . Archivado desde el original el 3 de mayo de 2019. Consultado el 3 de mayo de 2019 .
^ Descripción general del certificado SSL comodín, archivado desde el original el 23 de junio de 2015 , consultado el 2 de julio de 2015
^ Hosts virtuales SSL basados en nombres: cómo abordar el problema (PDF) , archivado (PDF) del original el 2012-08-03 , recuperado el 2012-05-17
Lectura adicional
Wikimedia Commons tiene medios relacionados con SSL y TLS .
Wagner, David; Schneier, Bruce (noviembre de 1996). "Análisis del protocolo SSL 3.0" (PDF) . Actas del segundo taller de USENIX sobre comercio electrónico . USENIX Press. págs. 29–40. Archivado (PDF) desde el original el 16 de octubre de 2006. Consultado el 12 de octubre de 2006 .
Rescorla, Eric (2001). SSL y TLS: diseño y construcción de sistemas seguros . Estados Unidos: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
Stephen A. Thomas (2000). Fundamentos de SSL y TLS para proteger la Web . Nueva York: Wiley. ISBN 978-0-471-38354-3.
Bard, Gregory (2006). "Un desafiante pero factible ataque de texto simple elegido adaptativo por bloques contra SSL". Asociación Internacional de Investigación Criptológica (136). Archivado desde el original el 23 de septiembre de 2011. Consultado el 23 de septiembre de 2011 .
Canvel, Brice. "Intercepción de contraseñas en un canal SSL/TLS". Archivado desde el original el 20 de abril de 2016. Consultado el 20 de abril de 2007 .
RFC de cambio para la renegociación de TLS . 2010. doi :10.17487/RFC5746. RFC 5746 .
Creación de VPN con IPsec y SSL/TLS Archivado el 12 de abril de 2015 en Wayback Machine Artículo de Linux Journal de Rami Rosen
Joshua Davies (2010). Implementación de SSL/TLS . Wiley. ISBN 978-0470920411.
Polk, Tim; McKay, Kerry; Chokhani, Santosh (abril de 2014). "Directrices para la selección, configuración y uso de implementaciones de seguridad de la capa de transporte (TLS)" (PDF) . Instituto Nacional de Estándares y Tecnología. Archivado desde el original (PDF) el 2014-05-08 . Consultado el 2014-05-07 .
Abdou, AbdelRahman; van Oorschot, Paul (agosto de 2017). "Verificación de la ubicación del servidor (SLV) y fijación de la ubicación del servidor: aumento de la autenticación TLS". ACM Transactions on Privacy and Security . 21 (1): 1:1–1:26. doi :10.1145/3139294. S2CID 5869541. Archivado desde el original el 22 de marzo de 2019. Consultado el 11 de enero de 2018 .
Ivan Ristic (2022). Bulletproof TLS y PKI, segunda edición . Feisty Duck. ISBN 978-1907117091.
Normas primarias
La versión actual aprobada de (D)TLS es la versión 1.3, que se especifica en:
RFC 8446: "El protocolo de seguridad de la capa de transporte (TLS) versión 1.3".
RFC 9147: "Protocolo de seguridad de la capa de transporte de datagramas (DTLS) versión 1.3"
Las normas actuales sustituyen a estas versiones anteriores, que hoy se consideran obsoletas:
RFC 5246: "El protocolo de seguridad de la capa de transporte (TLS) versión 1.2".
RFC 6347: "Seguridad de la capa de transporte de datagramas versión 1.2"
RFC 4346: "El protocolo de seguridad de la capa de transporte (TLS) versión 1.1".
RFC 4347 "Seguridad de la capa de transporte de datagramas"
RFC 2246: "El protocolo TLS versión 1.0".
RFC 6101: "El protocolo Secure Sockets Layer (SSL) versión 3.0".
Borrador de Internet (1995): "El protocolo SSL"
Extensiones
Posteriormente otras RFC ampliaron (D)TLS.
Las extensiones de (D)TLS 1.3 incluyen:
RFC 9367: "Conjuntos de cifrado GOST para el protocolo de seguridad de la capa de transporte (TLS) versión 1.3".
RFC 7366: "Cifrado y luego MAC para seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS)".
RFC 7465: "Prohibición de conjuntos de cifrados RC4".
RFC 7507: "Valor del conjunto de cifrado de señalización de respaldo TLS (SCSV) para prevenir ataques de degradación del protocolo".
RFC 7568: "Desuso de la versión 3.0 de Secure Sockets Layer".
RFC 7627: "Hash de sesión de seguridad de la capa de transporte (TLS) y extensión de secreto maestro extendido".
RFC 7685: "Una extensión de relleno ClientHello de seguridad de la capa de transporte (TLS)".
RFC 9189: "Conjuntos de cifrado GOST para el protocolo de seguridad de la capa de transporte (TLS) versión 1.2".
Las extensiones de (D)TLS 1.1 incluyen:
RFC 4366: "Extensiones de seguridad de la capa de transporte (TLS)" describe un conjunto de extensiones específicas y un mecanismo de extensión genérico.
RFC 5077: "Reanudación de sesión de seguridad de la capa de transporte (TLS) sin estado del lado del servidor".
RFC 5081: "Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS)", obsoleto por RFC 6091.
RFC 5216: "El protocolo de autenticación EAP -TLS"
Las extensiones de TLS 1.0 incluyen:
RFC 2595: "Uso de TLS con IMAP, POP3 y ACAP". Especifica una extensión de los servicios IMAP, POP3 y ACAP que permite al servidor y al cliente utilizar la seguridad de la capa de transporte para proporcionar una comunicación privada y autenticada a través de Internet.
RFC 2712: "Adición de conjuntos de cifrado Kerberos a la seguridad de la capa de transporte (TLS)". Los conjuntos de cifrado de 40 bits definidos en este memorando aparecen únicamente con el fin de documentar el hecho de que esos códigos de conjuntos de cifrado ya han sido asignados.
RFC 2817: "Actualización a TLS dentro de HTTP/1.1", explica cómo utilizar el mecanismo de actualización en HTTP/1.1 para iniciar la seguridad de la capa de transporte (TLS) a través de una conexión TCP existente. Esto permite que el tráfico HTTP seguro y no seguro comparta el mismo puerto conocido (en este caso, http: en 80 en lugar de https: en 443).
RFC 2818: "HTTP sobre TLS", distingue el tráfico seguro del tráfico inseguro mediante el uso de un "puerto de servidor" diferente.
RFC 3207: "Extensión del servicio SMTP para SMTP seguro sobre seguridad de la capa de transporte". Especifica una extensión del servicio SMTP que permite que un servidor y un cliente SMTP utilicen seguridad de la capa de transporte para proporcionar comunicación privada y autenticada a través de Internet.
RFC 3268: "Conjuntos de cifrados AES para TLS". Agrega conjuntos de cifrados del Estándar de cifrado avanzado (AES) a los cifrados simétricos existentes anteriormente.
RFC 3546: "Extensiones de seguridad de la capa de transporte (TLS)", añade un mecanismo para negociar extensiones de protocolo durante la inicialización de la sesión y define algunas extensiones. Quedó obsoleto a partir de RFC 4366.
RFC 3749: "Métodos de compresión del protocolo de seguridad de la capa de transporte", especifica el marco para los métodos de compresión y el método de compresión DEFLATE .
RFC 3943: "Compresión del protocolo de seguridad de la capa de transporte (TLS) mediante Lempel-Ziv-Stac (LZS)".
RFC 4132: "Adición de conjuntos de cifrado Camellia a la seguridad de la capa de transporte (TLS)".
RFC 4162: "Adición de conjuntos de cifrado SEED a la seguridad de la capa de transporte (TLS)".
RFC 4279: "Conjuntos de cifrados de clave precompartida para seguridad de la capa de transporte (TLS)", agrega tres conjuntos de nuevos conjuntos de cifrados para el protocolo TLS para soportar la autenticación basada en claves precompartidas.
RFC informativos
RFC 7457: "Resumen de ataques conocidos a la seguridad de la capa de transporte (TLS) y a la TLS de datagramas (DTLS)"
RFC 7525: "Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS)"
Enlaces externos
Grupo de trabajo de ingeniería de Internet: grupo de trabajo TLS Archivado el 11 de enero de 2014 en Wayback Machine
