El protocolo TLS tiene como objetivo principal brindar seguridad, incluida 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 a su vez se compone de dos capas: el registro TLS y los protocolos de protocolo de enlace TLS .
El Datagram Transport Layer Security ( DTLS ) , estrechamente relacionado, es un protocolo de comunicaciones que proporciona seguridad a las aplicaciones basadas en datagramas . En la redacción técnica, las referencias a "( D ) TLS " se ven a menudo cuando se aplica a ambas versiones. [1]
TLS es un estándar propuesto por el Grupo de Trabajo de Ingeniería de Internet (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) desarrollado por Netscape Communications para agregar el protocolo HTTPS a su navegador web Navigator .
Dado que las aplicaciones pueden comunicarse con o sin TLS (o SSL), es necesario que el cliente solicite que el servidor 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 no cifrado, 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 aceptado 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 la configuración de cifrado sino también una clave compartida específica de la sesión con la que se cifra la comunicación adicional utilizando 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 cifrado admitidos ( cifrados y funciones hash ).
De esta lista, el servidor elige una función de cifrado y hash que también admite y notifica al cliente de la decisión.
Normalmente, el servidor proporciona la identificación en forma de un certificado digital . El certificado contiene el nombre del servidor , la autoridad certificadora (CA) de confianza que garantiza la autenticidad del certificado y la clave de cifrado pública del servidor.
El cliente confirma la validez del certificado antes de continuar.
Para generar las claves de sesión utilizadas para la conexión segura, el cliente:
cifra un número aleatorio ( PreMasterSecret ) con la clave pública del servidor y envía el resultado al servidor (que sólo el servidor debería poder descifrar con su clave privada); Luego, ambas partes utilizan el número aleatorio para generar una clave de sesión única para el posterior cifrado y descifrado de datos durante la sesión, o
utiliza el intercambio de claves Diffie-Hellman (o su variante de curva elíptica DH ) 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 directo : si la clave privada del servidor se divulga en el futuro, no puede ser se utiliza para descifrar la sesión actual, incluso si la sesión es interceptada y registrada por un tercero.
Esto concluye el protocolo de enlace y comienza la conexión segura, que se cifra y descifra con la clave de sesión hasta que se cierra la conexión. Si alguno de los pasos anteriores falla, el protocolo de enlace TLS falla y no se crea la conexión.
TLS y SSL no encajan perfectamente en 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 . Sirve para el cifrado a capas superiores, que normalmente es función de la capa de presentación . Sin embargo, las aplicaciones generalmente usan TLS como si fuera una capa de transporte, [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 confiable (ningún atacante puede modificar las comunicaciones durante la negociación sin ser detectado).
La identidad de las partes que se comunican se puede autenticar 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 realizado intentos de subvertir aspectos de la seguridad de las comunicaciones que TLS busca brindar y el protocolo se ha revisado varias veces para abordar estas amenazas a la seguridad. Los desarrolladores de navegadores web han revisado repetidamente sus productos para defenderse de posibles debilidades de seguridad después de que se descubrieran (consulte el historial de soporte TLS/SSL de los navegadores web).
Como el datagrama del protocolo DTLS preserva 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 mayores que el tamaño de una red de datagramas. paquete . Debido a que DTLS usa UDP o SCTP en lugar de TCP, evita el "problema de fusión de TCP", [9] [10] cuando se usa para crear un túnel VPN.
La versión original de 2006 de DTLS versión 1.0 no era un documento independiente. Se proporcionó como una serie de deltas de TLS 1.1. [11] De manera similar, la versión de seguimiento de 2012 de DTLS es un delta de TLS 1.2. Se le asignó el número de versión de DTLS 1.2 para que coincida con su versión TLS. Por último, el DTLS 1.3 2022 es un delta del TLS 1.3. Al igual que las dos versiones anteriores, DTLS 1.3 pretende proporcionar "garantías de seguridad equivalentes [a TLS 1.3] con la excepción de protección de orden/no rejugabilidad". [12]
El Protocolo de seguridad de la capa de transporte (TLS), junto con varias otras plataformas básicas de seguridad de red, se desarrolló a través de una iniciativa conjunta iniciada en agosto de 1986, entre la Agencia de Seguridad Nacional, la Oficina Nacional de Estándares, la Agencia de Comunicaciones de Defensa y doce sistemas de comunicaciones y corporaciones informáticas que iniciaron un proyecto especial llamado Secure Data Network System (SDNS). [26] El programa fue descrito en septiembre de 1987 en la 10ª Conferencia Nacional de Seguridad Informática en un extenso 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 que se implementarán en aplicaciones en Internet públicas y privadas. Su objetivo era complementar los nuevos estándares de Internet OSI que emergen rápidamente y que avanzan tanto en los perfiles GOSIP del gobierno de EE. UU. como en el enorme esfuerzo de Internet ITU-ISO JTC1 a nivel internacional. Originalmente conocido como protocolo SP4, pasó a llamarse TLS y posteriormente se publicó en 1995 como estándar internacional ITU-T X.274|ISO/IEC 10736:1995.
Programación de red segura
Los primeros esfuerzos de investigación hacia la seguridad de la capa de transporte incluyeron la interfaz de programación de aplicaciones (API) de Programación de Red Segura (SNP), que en 1993 exploró el enfoque de tener una API de capa de transporte segura muy parecida a los sockets Berkeley , para facilitar la modernización de aplicaciones de red preexistentes con seguridad. medidas. [27] [28]
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". [29] [30] [31] [32] La versión 1.0 de SSL nunca se publicó públicamente debido a graves fallas de seguridad en el protocolo. Después de su lanzamiento en febrero de 1995, se descubrió rápidamente que la versión 2.0 contenía una serie de fallas de seguridad y usabilidad. Utilizó 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 lo 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 el cierre de un mensaje explícito, lo que significaba que los ataques de intermediario podían pasar desapercibidos. Además, SSL 2.0 suponí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 no podían utilizar SSL.
Estas fallas requirieron el rediseño completo del protocolo a SSL versión 3.0. [33] [31] 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 recientes de SSL/TLS se basan en SSL 3.0. El IETF publicó el borrador de SSL 3.0 de 1996 como documento histórico en RFC 6101.
SSL 2.0 quedó obsoleto en 2011 por RFC 6176. En 2014, se descubrió que SSL 3.0 era vulnerable al ataque POODLE que afecta a todos los cifrados de bloque en SSL; RC4 , el único cifrado sin bloque compatible con SSL 3.0, también es factible romperlo tal como se usa en SSL 3.0. [34] SSL 3.0 quedó obsoleto en junio de 2015 por RFC 7568.
TLS 1.0
TLS 1.0 se definió por primera vez en RFC 2246 en enero de 1999 como una actualización de SSL Versión 3.0 y 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 hacia Microsoft, "para que no pareciera [como si] el IETF estuviera simplemente aprobando el protocolo de Netscape". [35]
El Consejo PCI sugirió que las organizaciones migren de TLS 1.0 a TLS 1.1 o superior antes del 30 de junio de 2018. [36] [37] En octubre de 2018, Apple , Google , Microsoft y Mozilla anunciaron conjuntamente que dejarían de usar TLS 1.0 y 1.1 en marzo. 2020. [20] TLS 1.0 y 1.1 quedaron formalmente obsoletos en RFC 8996 en marzo de 2021.
TLS 1.1
TLS 1.1 se definió en RFC 4346 en abril de 2006. [38] Es una actualización de TLS versión 1.0. Las diferencias significativas en esta versión incluyen:
Soporte para el registro de parámetros de IANA . [39]
La compatibilidad con las versiones 1.0 y 1.1 de TLS quedó ampliamente obsoleta en 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. [40] [41] [42]
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 terminado se reemplazó por SHA-256, con una opción para usar algoritmos hash específicos del conjunto de cifrado. Sin embargo, el tamaño del hash en el mensaje finalizado debe ser de al menos 96 bits . [23] : §7.4.9
La combinación MD5 y SHA-1 en el elemento firmado digitalmente se reemplazó con un único hash negociado durante el protocolo de enlace , cuyo valor predeterminado es SHA-1.
Mejora en la capacidad del cliente y del servidor para especificar qué hashes y algoritmos de firma aceptan.
Se agregaron definiciones de extensiones TLS y conjuntos de cifrado AES. [39]
Todas las versiones de TLS se perfeccionaron aún más en RFC 6176 en marzo de 2011, eliminando su compatibilidad con SSL, de modo que las sesiones de TLS nunca negocian el uso de Secure Sockets Layer (SSL) versión 2.0. Actualmente no hay una fecha formal para que TLS 1.2 quede obsoleto.
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: [43]
Separación de los algoritmos de autenticación y acuerdo de claves de los conjuntos de cifrado [39] [6] : §11
Requerir firmas digitales incluso cuando se utiliza una configuración previa
Integrando HKDF y la propuesta semi-efímera DH
Reemplazo de reanudación con PSK y boletos.
Admite apretones de manos de 1- RTT y soporte inicial para 0- RTT
Exigir un secreto directo perfecto mediante el uso de claves efímeras durante el acuerdo de claves (EC)DH
Eliminación del soporte para muchas características inseguras u obsoletas, incluyendo compresión , renegociación, cifrados que no son AEAD , intercambio de claves que no son PFS (entre los cuales se encuentran los intercambios de claves estáticas RSA y DH estáticas ), grupos DHE personalizados , negociación de formato de puntos EC, protocolo de cambio de especificación de cifrado, Mensaje de saludo, hora UNIX y campo de longitud de entrada AD a cifrados AEAD
Prohibir la 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
Mover algunos detalles del algoritmo relacionados con la seguridad de un apéndice a la especificación y relegar ClientKeyShare a un apéndice
Agregar el cifrado de flujo ChaCha20 con el código de autenticación de mensajes Poly1305
Agregar los algoritmos de firma digital Ed25519 y Ed448
Agregar los protocolos de intercambio de claves x25519 y x448
Agregar soporte para enviar múltiples respuestas OCSP
Cifrar todos los mensajes de protocolo de enlace después de ServerHello
Network Security Services (NSS), la biblioteca de criptografía desarrollada por Mozilla y utilizada por su navegador web Firefox , habilitó TLS 1.3 de forma predeterminada en febrero de 2017. [44] Posteriormente se agregó compatibilidad con TLS 1.3, pero debido a problemas de compatibilidad para una pequeña cantidad de usuarios, no habilitados automáticamente [45] - 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 . [46]
Google Chrome configuró 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 servidores proxy web de Blue Coat . [47]
La intolerancia a la nueva versión de TLS fue la osificación del protocolo ; Las cajas intermedias 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. [48] El descubrimiento de esta intolerancia también llevó a que la estrategia de negociación de la versión anterior, donde se elegía la versión más coincidente, fuera abandonada debido a niveles inviables de osificación. [49] ' Engrasar ' un punto de extensión, donde un participante del protocolo afirma admitir extensiones inexistentes para garantizar que se toleren extensiones no reconocidas pero realmente existentes y, por lo tanto, resistir la osificación, fue diseñado originalmente para TLS, pero desde entonces ha sido adoptado en otros lugares. [50]
Durante el Hackathon IETF 100 , 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. [51] [52] El grupo TLS estaba formado por personas de Japón, Reino Unido y Mauricio a través del equipo cyberstorm.mu. [52] Este trabajo continuó en el Hackathon IETF 101 en Londres , [53] y el Hackathon IETF 102 en Montreal. [54]
wolfSSL permitió el uso de TLS 1.3 a partir de la versión 3.11.1, lanzada en mayo de 2017. [55] Como la primera implementación comercial de TLS 1.3, wolfSSL 3.11.1 admitió el Draft 18 y ahora admite el Draft 28, [56] la versión final, así como muchas versiones anteriores. Se publicaron una serie de blogs sobre la diferencia de rendimiento entre TLS 1.2 y 1.3. [57]
En, el popular proyecto OpenSSL lanzó la versión 1.1.1 de su biblioteca, en la que la compatibilidad con TLS 1.3 era "la nueva característica principal". [58]
La Electronic Frontier Foundation elogió a TLS 1.3 y expresó su preocupación por la variante del protocolo Enterprise Transport Security (ETS) que desactiva intencionalmente importantes medidas de seguridad en TLS 1.3. [60] Originalmente llamado Enterprise TLS (eTLS), ETS es un estándar publicado conocido como ' ETSI TS103523-3', "Protocolo de seguridad Middlebox, Parte 3: Seguridad del transporte empresarial". Está destinado a ser utilizado exclusivamente dentro de redes propietarias, como los sistemas bancarios. ETS no admite el secreto directo para permitir que organizaciones de terceros conectadas a las redes propietarias puedan usar su clave privada para monitorear el tráfico de la red para detectar malware y facilitar la realización de auditorías. [61] [62] A pesar de los beneficios declarados, la EFF advirtió que la pérdida del secreto directo podría facilitar la exposición de los datos, además de decir que hay mejores formas de analizar el tráfico.
Certificados digitales
Ejemplo de una 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 firmas o afirmaciones realizadas por la clave privada que corresponde a la clave pública certificada. Los almacenes de claves y los almacenes de confianza pueden estar en varios formatos, como .pem , .crt, .pfx y .jks .
Autoridades certificadoras
TLS normalmente se basa en un conjunto de autoridades certificadoras de terceros confiables para establecer la autenticidad de los certificados. La confianza suele estar anclada en una lista de certificados distribuidos con el software del agente de usuario [63] y la parte que confía puede modificarla.
Según Netcraft , que monitorea los certificados TLS activos, la autoridad de certificación (CA) líder en el mercado ha sido Symantec desde el comienzo de su encuesta (o VeriSign antes de que Symantec comprara la unidad de negocios de servicios de autenticación). 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 concurridos, según contabilizó Netcraft. [64] En 2017, Symantec vendió su negocio TLS/SSL a DigiCert. [65] En un informe actualizado, se demostró que IdenTrust , DigiCert y Sectigo son las tres principales autoridades de certificación en términos de participación de mercado desde mayo de 2019. [66]
Como consecuencia de la elección de los certificados X.509 , se necesitan autoridades certificadoras 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 más conocido que las autoridades certificadoras son un punto débil desde el punto de vista de la seguridad, permitiendo ataques de intermediario (MITM). si la autoridad certificadora coopera (o se ve comprometida). [67] [68]
Importancia de los certificados SSL
Cifrado : los certificados SSL cifran los datos enviados entre un servidor web y el navegador de un usuario, garantizando que la información confidencial esté protegida durante toda la transmisión. Esta tecnología de cifrado impide que partes no autorizadas intercepten e interpreten datos, protegiéndolos así de posibles riesgos como piratería informática o 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 conectan al servidor correcto en lugar de 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 sin modificaciones durante el tránsito. Esto evita que actores malévolos interfieran con los datos, asegurando 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 utilizar al cifrar datos (consulte § Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves se encuentran: claves públicas y privadas generadas con RSA (denominadas TLS_RSA en el protocolo de intercambio de claves TLS), Diffie-Hellman (TLS_DH), Diffie-Hellman efímera (TLS_DHE), Diffie-Hellman de curva elíptica ( TLS_ECDH), Diffie-Hellman de curva elíptica efímera (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon), [23] clave precompartida (TLS_PSK) [69] y contraseña remota segura (TLS_SRP). [70]
Los métodos de acuerdo de claves TLS_DH_anon y TLS_ECDH_anon no autentican al servidor ni al usuario y, por lo tanto, rara vez se utilizan porque son vulnerables a ataques de intermediario . Sólo TLS_DHE y TLS_ECDHE proporcionan secreto directo.
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 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, en su lugar, cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios porque la intensidad del cifrado está directamente relacionada con el tamaño de la clave. . [71] [72]
Cifrar
Notas
^ Se debe implementar abcd RFC 5746 para corregir una falla de renegociación que de otro modo rompería este protocolo.
^ Si las bibliotecas implementan las correcciones enumeradas en RFC 5746, esto viola la especificación SSL 3.0, que el IETF no puede cambiar a diferencia de TLS. La mayoría de las bibliotecas actuales implementan la solución y ignoran la infracció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 lo mitigue el cliente y/o el servidor. Ver § Navegadores web.
^ El ataque POODLE rompe todos los cifrados de bloque (cifrados CBC) utilizados en SSL 3.0 a menos que lo mitigue el cliente y/o el servidor. Ver § Navegadores web.
^ Los cifrados abcdefg AEAD (como GCM y CCM ) solo se pueden usar en TLS 1.2 o posterior.
^ Los cifrados abcdefgh CBC pueden ser atacados con el ataque Lucky Thirteen si la biblioteca no está escrita cuidadosamente para eliminar los canales laterales de sincronización.
^ abcdef El ataque Sweet32 rompe cifrados de bloques con un tamaño de bloque de 64 bits. [82]
^ Aunque la longitud de la clave de 3DES es de 168 bits, la fuerza de seguridad efectiva de 3DES es de solo 112 bits, [83] que está por debajo del mínimo recomendado de 128 bits. [84]
^ ab IDEA y DES se eliminaron de TLS 1.2. [85]
^ Los conjuntos de cifrado abc de 40 bits se diseñaron intencionalmente con longitudes de clave reducidas para cumplir con las regulaciones estadounidenses ya rescindidas que prohíben la exportación de software criptográfico que contenga ciertos algoritmos de cifrado potentes (consulte Exportación de criptografía desde los Estados Unidos ). Estas suites débiles están prohibidas en TLS 1.1 y posteriores.
^ El uso de RC4 en todas las versiones de TLS está prohibido por RFC 7465 (porque los ataques RC4 debilitan o rompen el RC4 utilizado en SSL/TLS).
En el diseño de aplicaciones, TLS generalmente se implementa sobre los protocolos de la capa de transporte, cifrando todos los datos relacionados con protocolos como HTTP , FTP , SMTP , NNTP y XMPP .
Un uso principal de TLS es proteger el tráfico de la World Wide Web entre un sitio web y un navegador web codificado con el protocolo HTTP. Este uso de TLS para proteger el tráfico HTTP constituye el protocolo HTTPS . [87]
Notas
^ ver § Tabla de cifrado arriba
^ ver § Navegadores web y § Ataques contra secciones TLS/SSL
navegadores web
A partir de abril de 2016 [update], las últimas versiones de todos los principales navegadores web son compatibles con 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 son compatibles con la última versión de IE. Además, muchos sistemas operativos de Microsoft actualmente admiten 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: "a partir del 12 de enero de 2016, solo recibirá la versión más actual de Internet Explorer disponible para un sistema operativo compatible". soporte técnico y actualizaciones de seguridad." Luego, la página continúa enumerando la última versión compatible de IE en esa fecha para cada sistema operativo. La próxima fecha crítica sería cuando un sistema operativo llegue a la etapa de final de vida. 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. [91] [92]
Las mitigaciones contra ataques conocidos aún no son suficientes:
Mitigaciones contra el ataque POODLE: algunos navegadores ya impiden el respaldo a SSL 3.0; sin embargo, esta mitigación debe ser compatible no solo con los clientes sino también con los servidores. Se requiere deshabilitar SSL 3.0, implementar una "división de registros anti-POODLE" o negar 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 está deshabilitado de forma predeterminada desde la versión 40. La compatibilidad con SSL 3.0 se eliminó desde la versión 44).
Mozilla Firefox: completo (la compatibilidad con SSL 3.0 se ha eliminado desde la versión 39. SSL 3.0 está deshabilitado de forma predeterminada y el respaldo a SSL 3.0 está deshabilitado desde la versión 34 , TLS_FALLBACK_SCSV se implementa desde la versión 35. En ESR, SSL 3.0 está deshabilitado por predeterminado y TLS_FALLBACK_SCSV está implementado desde ESR 31.3.0.)
Internet Explorer: parcial (solo en la versión 11, SSL 3.0 está deshabilitado de forma predeterminada desde abril de 2015. La versión 10 y anteriores siguen siendo vulnerables contra POODLE).
Opera : completo (TLS_FALLBACK_SCSV se implementa desde la versión 20, la "división de registros anti-POODLE", que es efectiva solo con la implementación del lado del cliente, se implementa desde la versión 25, SSL 3.0 está deshabilitado de forma predeterminada desde la versión 27. Soporte de SSL 3.0 se eliminará desde la versión 31.)
Safari: completo (solo en OS X 10.8 y posteriores y iOS 8, se deniegan los cifrados CBC durante el respaldo a SSL 3.0, pero esto significa que usará RC4, que tampoco se recomienda. La compatibilidad con SSL 3.0 en sí se elimina en OS X 10.11 y posteriores y iOS 9.)
Mitigación contra ataques RC4:
Google Chrome deshabilitó RC4 excepto como alternativa desde la versión 43. RC4 está deshabilitado desde Chrome 48.
Firefox deshabilitó RC4 excepto como alternativa desde la versión 36. Firefox 44 deshabilitó RC4 de forma predeterminada.
Opera deshabilitó RC4 excepto como alternativa 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 han establecido la prioridad de RC4 en la más baja y también puede desactivar RC4, excepto como alternativa a través de la configuración del registro. Internet Explorer 11 Mobile 11 para Windows Phone 8.1 deshabilita RC4 excepto como alternativa si ningún otro algoritmo habilitado funciona. Edge e IE 11 desactivaron RC4 por completo en agosto de 2016.
Mitigación contra el ataque FREAK:
El navegador de Android incluido con Android 4.0 y versiones anteriores sigue siendo vulnerable al ataque FREAK.
Internet Explorer 11 Mobile sigue siendo vulnerable al ataque FREAK.
Google Chrome, Internet Explorer (escritorio), Safari (escritorio y móvil) y Opera (móvil) cuentan con 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 [94] 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 terrible diseño de las API para las bibliotecas SSL subyacentes. En lugar de expresar propiedades de seguridad de alto nivel de los túneles de red, como la confidencialidad y la autenticación, estas API exponen detalles de bajo nivel del protocolo SSL. a los desarrolladores de aplicaciones. Como consecuencia, los desarrolladores a menudo utilizan las API 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 crear un túnel en una pila de red completa para crear una VPN , como es el caso de OpenVPN y OpenConnect . Muchos proveedores ya han combinado las capacidades de autenticación y cifrado de TLS con autorización. También ha habido un desarrollo sustancial desde finales de la década de 1990 en la creación de tecnología de cliente fuera de los navegadores web, con el fin de permitir el soporte para aplicaciones cliente/servidor. En comparación con las tecnologías VPN IPsec tradicionales , TLS tiene algunas ventajas inherentes en el firewall y el cruce de NAT que facilitan la administración para grandes poblaciones de acceso remoto.
TLS también es un método estándar para proteger la señalización de aplicaciones del Protocolo de inicio de sesión (SIP). TLS se puede utilizar para proporcionar autenticación y cifrado de la señalización SIP asociada con VoIP y otras aplicaciones basadas en SIP. [95]
Seguridad
Ataques contra TLS/SSL
A continuación se enumeran los ataques importantes contra TLS/SSL.
En febrero de 2015, el IETF emitió un RFC informativo [96] que resume los diversos ataques conocidos contra TLS/SSL.
Ataque de renegociación
En agosto de 2009 se descubrió una vulnerabilidad en el procedimiento de renegociación que puede provocar ataques de inyección de texto plano contra SSL 3.0 y todas las versiones actuales de TLS. [97] Por ejemplo, permite a un atacante que puede secuestrar una conexión https unir sus propias solicitudes al comienzo de la conversación que el cliente tiene con el servidor web. En realidad, el atacante no puede descifrar la comunicación cliente-servidor, por lo que es diferente de un típico ataque 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 del certificado del 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 apretones de manos anteriores en cualquier apretón de manos de renegociación. [98] 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. [99] [100] [101]
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.
Modificaciones anteriores a los protocolos originales, como False Start [102] (adoptado y habilitado por Google Chrome [103] ) o Snap Start , supuestamente introdujeron ataques limitados de degradación del protocolo TLS [104] o permitieron modificaciones a la lista del conjunto de cifrado enviada por el cliente. al servidor. Al hacerlo, un atacante podría lograr influir en la selección del conjunto de cifrado en un intento de degradar el conjunto de cifrado negociado para utilizar un algoritmo de cifrado simétrico más débil o un intercambio de claves más débil. [105] Un artículo presentado en una conferencia de ACM sobre seguridad informática y de las comunicaciones en 2012 demostró que la extensión False Start estaba en riesgo: en determinadas circunstancias, podría permitir a un atacante recuperar las claves de cifrado fuera de línea y acceder a los datos cifrados. [106]
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 . [107] El ataque implicó engañar a los servidores para que negociaran una conexión TLS utilizando claves de cifrado de 512 bits criptográficamente débiles.
Logjam es un exploit de seguridad descubierto en mayo de 2015 que aprovecha la opción de utilizar grupos Diffie-Hellman de 512 bits heredados de "grado de exportación" que se remontan a la década de 1990. [108] Obliga a los servidores susceptibles a degradarse a grupos Diffie-Hellman de 512 bits criptográficamente débiles. Luego, un atacante puede deducir las claves que el cliente y el servidor determinan mediante el intercambio de claves Diffie-Hellman .
Ataques entre protocolos: DROWN
El ataque DROWN es un exploit que ataca servidores que soportan conjuntos de protocolos SSL/TLS contemporáneos explotando su soporte para el protocolo SSLv2 obsoleto e inseguro para aprovechar un ataque a conexiones que utilizan protocolos actualizados que de otro modo serían seguros. [109] [110] 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 del millón de sitios web más populares se encontraban entre los sitios web protegidos por TLS que eran vulnerables al ataque DROWN. [110]
Ataque 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 ) [111] utilizando un subprograma de Java para violar las restricciones de la política del mismo origen , para un encadenamiento de bloques de cifrado conocido desde hace mucho tiempo ( CBC) vulnerabilidad en TLS 1.0: [112] [113] un atacante que observa 2 bloques de texto cifrado consecutivos C0, C1 puede probar si el bloque de texto sin formato P1 es igual a x eligiendo el siguiente bloque de texto sin formato P2 = x ⊕ C0 ⊕ C1 ; según la operación CBC, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , que será igual a C1 si x = P1 . No se habían demostrado previamente explotaciones prácticas para esta vulnerabilidad , que fue descubierta originalmente por Phillip Rogaway [114] en 2002. La vulnerabilidad del ataque se había solucionado con TLS 1.1 en 2006, pero TLS 1.1 no había tenido una adopción amplia antes de este ataque. demostración.
RC4 como cifrado de flujo es inmune al ataque de BEAST. Por lo tanto, RC4 se utilizó ampliamente como una forma de mitigar el ataque BEAST en el lado del servidor. Sin embargo, en 2013, los investigadores encontraron más debilidades en RC4. A partir de entonces, ya no se recomendó habilitar RC4 en el lado del servidor. [115]
Microsoft publicó el Boletín de seguridad MS12-006 el 10 de enero de 2012, que solucionó la vulnerabilidad BEAST cambiando la forma en que el componente Windows Secure Channel ( Schannel ) transmite paquetes de red cifrados desde el extremo del servidor. [119] Los usuarios de Internet Explorer (anterior a la versión 11) que ejecutan versiones anteriores de Windows ( Windows 7 , Windows 8 y Windows Server 2008 R2 ) pueden restringir el uso de TLS a 1.1 o superior.
Apple solucionó la vulnerabilidad BEAST implementando la división 1/n-1 y activándola de forma predeterminada en OS X Mavericks , lanzado el 22 de octubre de 2013. [120]
Ataques de DELITOS e INFRACCIONES
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. [121] [122] Cuando se utiliza para recuperar el contenido de las cookies de autenticación secretas , permite a un atacante realizar un secuestro de sesión en una sesión web autenticada.
Si bien el ataque CRIME se presentó como un ataque general que podría funcionar eficazmente contra una gran cantidad de protocolos, incluidos, entre otros, TLS y protocolos de capa de aplicación como SPDY o HTTP , solo se demostraron y mitigaron en gran medida los exploits contra TLS y SPDY. en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, aunque los autores de CRIME han advertido que esta vulnerabilidad podría estar 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 TLS en tan solo 30 segundos (dependiendo de la cantidad de bytes que se extraerán), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso o puede inyectar contenido en páginas válidas que el usuario está visitando (por ejemplo, una red inalámbrica bajo el control del atacante). [123] Todas las versiones de TLS y SSL están en riesgo de INCUMPLIMIENTO, independientemente del algoritmo de cifrado o cifrado utilizado. [124] A diferencia de instancias anteriores de CRIME, que se pueden defender con éxito desactivando la compresión TLS o la compresión de encabezado SPDY, BREACH explota la compresión HTTP que, en realidad, no se puede desactivar, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para usuarios. [123] Esta es una limitación conocida de TLS, ya que es susceptible a ataques de texto sin formato elegido contra los datos de la capa de aplicación que debía proteger.
Algunos expertos [84] también recomendaron evitar el CBC con triple DES . 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á en desuso (consulte la discusión sobre los ataques RC4 ), esto lo hace difícil. para admitir cualquier versión de SSL para cualquier programa que utilice esta biblioteca en XP.
Se publicó una solución como extensión Encrypt-then-MAC para la especificación TLS, publicada como RFC 7366. [125] El ataque Lucky Thirteen se puede mitigar en TLS 1.2 usando 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). Llamaron a este ataque POODLE ( Padding Oracle On Downgraded Legacy Encryption ). En promedio, los atacantes sólo necesitan realizar 256 solicitudes SSL 3.0 para revelar un byte de mensajes cifrados. [90]
Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayoría de los clientes y servidores admiten TLS 1.0 y superior, todos los principales navegadores cambian voluntariamente a SSL 3.0 si fallan los protocolos de enlace con versiones más recientes de TLS, a menos que brinden la opción para que un usuario o administrador deshabilite SSL 3.0. y el usuario o administrador lo hace [ cita necesaria ] . Por lo tanto, el intermediario puede primero realizar un ataque de reversión de versión y luego explotar esta vulnerabilidad. [90]
El 8 de diciembre de 2014, se anunció una variante de POODLE que afecta las implementaciones de TLS que no aplican adecuadamente los requisitos de bytes de relleno. [126]
ataques RC4
A pesar de la existencia de ataques a RC4 que rompieron su seguridad, los conjuntos de cifrado en SSL y TLS basados en RC4 todavía se consideraban seguros antes de 2013 según la forma en que se usaban en SSL y TLS. En 2011, se recomendó la suite RC4 como solución alternativa al ataque BEAST . [127] Las nuevas formas de ataque reveladas en marzo de 2013 demostraron de manera concluyente la viabilidad de romper RC4 en TLS, lo que sugiere que no era una buena solución para BEAST. [89] AlFardan, Bernstein, Paterson, Poettering y Schuldt propusieron un escenario de ataque que utilizó sesgos estadísticos recientemente descubiertos en la tabla de claves RC4 [128] para recuperar partes del texto sin formato con una gran cantidad de cifrados TLS. [129] [130] El 8 de julio de 2013 se dio a conocer un ataque a RC4 en TLS y SSL que requiere cifrados 13 × 2 20 para romper RC4 y luego se describió como "factible" en la presentación adjunta en un Simposio de seguridad de USENIX en agosto de 2013. [131] [132] En julio de 2015, las mejoras posteriores en el ataque hacen que sea cada vez más práctico derrotar la seguridad del TLS cifrado con RC4. [133]
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 § 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 de protección más popular. [84] Mozilla y Microsoft recomiendan desactivar RC4 siempre que sea posible. [134] [135] RFC 7465 prohíbe el uso de conjuntos de cifrado RC4 en todas las versiones de TLS.
El 1 de septiembre de 2015, Microsoft, Google y Mozilla anunciaron que los conjuntos de cifrado RC4 se desactivarían de forma predeterminada en sus navegadores ( Microsoft Edge , Internet Explorer 11 en Windows 7/8.1/10, Firefox y Chrome ) a principios de 2016. [136 ] [137] [138]
Ataque de truncamiento
Un ataque de truncamiento TLS (cierre de sesión) bloquea las solicitudes de cierre de sesión de la cuenta de la víctima para que el usuario, sin saberlo, permanezca conectado a un servicio web. Cuando se envía la solicitud para cerrar sesión, el atacante inyecta un mensaje TCP FIN no cifrado (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 terminación anormal. [139]
Publicado en julio de 2013, [140] [141] el ataque hace que servicios web como Gmail y Hotmail muestren una página que informa al usuario que ha cerrado sesión correctamente, al tiempo que garantiza que el navegador del usuario mantenga la autorización con el servicio, lo que permite un atacante con acceso posterior al navegador para acceder y tomar el control de la cuenta del usuario que ha iniciado sesión. El ataque no se basa en instalar malware en la computadora de la víctima; los atacantes sólo necesitan colocarse entre la víctima y el servidor web (por ejemplo, configurando un punto de acceso inalámbrico fraudulento). [139] 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 plano contra DTLS
En febrero de 2013, dos investigadores de Royal Holloway, Universidad de Londres, descubrieron un ataque de sincronización [142] que les permitió recuperar (partes del) texto sin formato de una conexión DTLS utilizando la implementación OpenSSL o GnuTLS de DTLS cuando se utilizaba el cifrado en modo Cipher Block Chaining. .
Ataque impío de PAC
Este ataque, descubierto a mediados de 2016, aprovecha las debilidades del Protocolo de detección automática de proxy web (WPAD) para exponer la URL a la que un usuario web intenta acceder a través de un enlace web habilitado para TLS. [143] La divulgación de una URL puede violar la privacidad de un usuario, no sólo 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 para compartir documentos, como los que ofrecen Google y Dropbox, también funcionan enviando al usuario un token de seguridad que se incluye en la URL. Un atacante que obtenga dichas URL puede obtener acceso completo a la cuenta o los datos de la víctima.
El exploit funciona contra casi todos los navegadores y sistemas operativos.
ataque dulce32
El ataque Sweet32 rompe todos los cifrados de bloques de 64 bits utilizados en el modo CBC tal como se utilizan en TLS al explotar un ataque de cumpleaños y un ataque de intermediario o la inyección de un JavaScript malicioso en una página web. El propósito del ataque de intermediario o la inyección de JavaScript es permitir que el atacante capture suficiente tráfico para montar un ataque de cumpleaños. [144]
Errores de implementación:Bicho sangrante,Ataque BERserk, error de Cloudflare
El error Heartbleed es una vulnerabilidad grave específica de la implementación de SSL/TLS en la popular biblioteca de software criptográfico OpenSSL y afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad, reportada en abril de 2014, permite a los atacantes robar claves privadas de servidores que normalmente deberían estar protegidos. [145] El error Heartbleed permite que cualquier persona en Internet lea 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 cifrar el tráfico, los nombres y contraseñas de los usuarios y el contenido real. Esto permite a los atacantes escuchar las comunicaciones, robar datos directamente de los servicios y usuarios y hacerse pasar por servicios y usuarios. [146] La vulnerabilidad es causada por un error de lectura excesiva del búfer en el software OpenSSL, en lugar de un defecto en la especificación del protocolo SSL o TLS.
En septiembre de 2014, Intel Security Advanced Threat Research anunció una variante de la vulnerabilidad de falsificación de firma RSA PKCS#1 v1.5 de Daniel Bleichenbacher [147] . Este ataque, denominado BERserk, es el resultado de una decodificación incompleta de la longitud ASN.1 de firmas de clave pública en algunas implementaciones SSL y permite un ataque de intermediario falsificando una firma de clave pública. [148]
En febrero de 2015, después de que los medios informaran sobre la preinstalación oculta de software publicitario Superfish en algunas computadoras portátiles Lenovo, [149] un investigador descubrió que un certificado raíz confiable en las máquinas Lenovo afectadas era inseguro, ya que se podía acceder fácilmente a las claves usando el nombre de la empresa. Komodia, como frase de contraseña. [150] La biblioteca Komodia fue diseñada para interceptar el tráfico TLS/SSL del lado del cliente para control y vigilancia parental, pero también se usó en numerosos programas publicitarios, incluido Superfish, que a menudo se instalaban subrepticiamente sin que el usuario de la computadora lo supiera. A su vez, estos programas potencialmente no deseados instalaron el certificado raíz corrupto, lo que permitió a los atacantes controlar completamente el tráfico web y confirmar que los sitios web falsos son auténticos.
En mayo de 2016, se informó que docenas de sitios web daneses protegidos por HTTPS pertenecientes a Visa Inc. eran vulnerables a ataques que permitían a los piratas informáticos inyectar códigos maliciosos y contenido falsificado en los navegadores de los visitantes. [151] 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. [151]
En febrero de 2017, un error de implementación causado por un solo carácter mal escrito en el código utilizado para analizar HTML creó un error de desbordamiento del búfer en los servidores de Cloudflare . Similar en sus efectos al error Heartbleed descubierto en 2014, este error de desbordamiento, ampliamente conocido como Cloudbleed , permitió 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. [152]
Encuesta de sitios web vulnerables a ataques
En julio de 2021 [update], el Trustworthy Internet Movement estimó la proporción de sitios web que son vulnerables a ataques TLS. [88]
secreto hacia adelante
El secreto directo 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. [153] Sin secreto directo, si la clave privada del servidor se ve comprometida, no solo se verán comprometidas todas las sesiones futuras cifradas con TLS que utilicen ese certificado de servidor, sino también cualquier sesión pasada que lo haya utilizado (siempre que estas sesiones pasadas hayan sido interceptadas y almacenados en el momento de la transmisión). [154] Una implementación de TLS puede proporcionar secreto directo al requerir el uso de intercambio de claves efímeras Diffie-Hellman para establecer claves de sesión, y algunas implementaciones de TLS notables lo hacen exclusivamente: por ejemplo, Gmail y otros servicios HTTPS de Google que usan OpenSSL . [155] Sin embargo, muchos clientes y servidores que admiten TLS (incluidos navegadores y servidores web) no están configurados para implementar tales restricciones. [156] [157] En la práctica, a menos que un servicio web utilice el intercambio de claves Diffie-Hellman para implementar el secreto directo, todo el tráfico web cifrado hacia y desde ese servicio puede ser descifrado por un tercero si obtiene el servidor maestro (privado). ) llave; por ejemplo, mediante una orden judicial. [158]
Incluso cuando se implementa el intercambio de claves Diffie-Hellman, los mecanismos de gestión de sesiones del lado del servidor pueden afectar el secreto directo. El uso de tickets de sesión TLS (una extensión de TLS) hace que la sesión esté protegida por AES128-CBC-SHA256 independientemente de cualquier otro parámetro TLS negociado, incluidos los conjuntos de cifrado de secreto directo, y las claves de ticket de sesión TLS de larga duración frustran el intento de implementar secreto hacia delante. [159] [160] [161] La investigación de la Universidad de Stanford en 2014 también encontró que de 473,802 servidores TLS encuestados, el 82,9% de los servidores que implementaban el intercambio de claves efímero Diffie-Hellman (DHE) para respaldar el secreto directo utilizaban parámetros Diffie-Hellman débiles. Estas elecciones de parámetros débiles podrían potencialmente comprometer la efectividad del secreto directo que los servidores buscaban proporcionar. [162]
Desde finales de 2011, Google ha proporcionado confidencialidad directa con TLS de forma predeterminada a los usuarios de su servicio Gmail , junto con Google Docs y búsqueda cifrada, entre otros servicios. [163]
Desde noviembre de 2013, Twitter ha proporcionado confidencialidad directa con TLS a los usuarios de su servicio. [164] En agosto de 2019 [update], aproximadamente el 80% de los sitios web habilitados para TLS están configurados para utilizar conjuntos de cifrado que brindan confidencialidad directa a la mayoría de los navegadores web. [88]
interceptación TLS
La interceptación TLS (o la 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 enviar los datos nuevamente. Esto se hace mediante un " proxy transparente ": el software de interceptación finaliza la conexión TLS entrante, inspecciona el texto sin formato HTTP y luego crea una nueva conexión TLS con el destino. [165]
Los operadores de red utilizan la interceptación TLS/HTTPS como medida de seguridad de la información para poder escanear y proteger contra la intrusión de contenido malicioso en la red, como virus informáticos y otro malware . [165] De lo contrario, dicho contenido no podría detectarse siempre que esté protegido mediante cifrado, lo que es cada vez más frecuente como resultado del uso rutinario de HTTPS y otros protocolos seguros.
Un inconveniente importante de la interceptación TLS/HTTPS es que introduce nuevos riesgos de seguridad propios. Una limitación notable es que proporciona un punto donde el tráfico de red está disponible sin cifrar, lo que brinda 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 la 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 encontró que "la interceptación HTTPS se ha generalizado sorprendentemente y que los productos de interceptación como clase tienen un impacto dramáticamente negativo en la seguridad de la conexión". [165]
Detalles del protocolo
El protocolo TLS intercambia registros , que encapsulan los datos a intercambiar en un formato específico (ver más abajo). Cada registro se puede comprimir, rellenar, agregar un código de autenticación de mensaje (MAC) o cifrar, todo dependiendo 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 la aplicación que TLS debe transferir. Las especificaciones (conjunto de cifrado, claves, etc.) necesarias para intercambiar datos de aplicaciones 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 lo tanto, el protocolo define tanto la estructura de las cargas útiles transferidas en TLS como el procedimiento para establecer y monitorear la transferencia.
apretón de manos TLS
Ilustración simplificada del protocolo de enlace TLS 1.2 completo con información de sincronización
Cuando se inicia la conexión, el registro encapsula un protocolo de "control": el protocolo de mensajería de protocolo de enlace ( tipo de contenido 22). Este protocolo se utiliza para intercambiar toda la información requerida por ambas partes para el intercambio de los datos 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 configurar 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) se autentica mediante su certificado:
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 sugeridos. Si el cliente intenta realizar un protocolo de enlace reanudado, puede enviar una ID de sesión . Si el cliente puede utilizar la negociación del protocolo de capa de aplicación , puede incluir una lista de protocolos de aplicación compatibles , como HTTP/2 .
El servidor responde con un mensaje ServerHello , que contiene la versión del protocolo elegido, un número aleatorio, un conjunto de cifrado y un método de compresión entre las opciones ofrecidas por el cliente. Para confirmar o permitir la reanudación de los apretones de manos, el servidor puede enviar una ID de sesión . La versión del 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 omitirlo). [166]
El servidor envía su mensaje ServerKeyExchange (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrado DHE , ECDHE y DH_anon. [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. (Nuevamente, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
Luego, el cliente y el servidor utilizan 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étrica , clave MAC [167] ) 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 un sistema cuidadosamente diseñado. función pseudoaleatoria .
El cliente ahora envía un registro ChangeCipherSpec , esencialmente diciéndole al servidor: "Todo lo que le diga a partir de ahora será autenticado (y cifrado si los parámetros de cifrado estaban presentes en el certificado del servidor)". ChangeCipherSpec es en sí mismo un protocolo de nivel de registro con un tipo de contenido de 20.
El cliente envía un mensaje Finalizado autenticado y cifrado , que contiene un hash y una MAC sobre los mensajes de protocolo de enlace anteriores.
El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y se debe finalizar la conexión.
Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente: "Todo lo que le diga a partir de ahora será autenticado (y cifrado, si se negoció el cifrado)".
El servidor envía su mensaje Finalizado autenticado y cifrado .
El cliente realiza el mismo procedimiento de descifrado y verificación que realizó 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 la autenticación de un cliente (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 elegido, un número aleatorio, un conjunto de cifrado y un método de compresión entre las opciones ofrecidas por el cliente. El servidor también puede enviar una identificación de sesión como parte del mensaje para realizar un protocolo de enlace reanudado.
El servidor envía su mensaje de Certificado (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitirlo). [166]
El servidor envía su mensaje ServerKeyExchange (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrado DHE, ECDHE y DH_anon. [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. (Nuevamente, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
El cliente envía un mensaje CertificateVerify , que es una firma sobre los mensajes de protocolo de enlace anteriores utilizando la clave privada del certificado del cliente. Esta firma se puede verificar utilizando la clave pública del certificado del cliente. Esto le permite al servidor saber que el cliente tiene acceso a la clave privada del certificado y, por lo tanto, es propietario del certificado.
Luego, el cliente y el servidor utilizan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave ("claves de sesión") para esta conexión se derivan de este secreto maestro (y 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 , esencialmente diciéndole al servidor: "Todo lo que le diga de ahora en adelante será autenticado (y cifrado si se negoció el cifrado). "ChangeCipherSpec es en sí mismo un protocolo de 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 sobre los mensajes de protocolo de enlace anteriores.
El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y se debe interrumpir la conexión.
Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente: "Todo lo que le diga a partir de ahora será autenticado (y cifrado si se negoció el cifrado)".
El servidor envía su propio mensaje cifrado de finalización .
El cliente realiza el mismo procedimiento de descifrado y verificación que realizó 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 .
Protocolo de enlace TLS reanudado
Las operaciones de clave pública (por ejemplo, RSA) son relativamente caras en términos de potencia computacional. TLS proporciona un atajo seguro en el mecanismo de protocolo de enlace para evitar estas operaciones: sesiones reanudadas. Las sesiones reanudadas se implementan mediante ID de sesión o tickets de sesión.
Además del beneficio de rendimiento, las sesiones reanudadas también se pueden utilizar para el inicio de sesión único , ya que garantiza que tanto la sesión original como cualquier sesión reanudada se originen en el mismo cliente. Esto es de particular importancia para el protocolo FTP sobre TLS/SSL , que de otro modo sufriría un ataque de intermediario en el que un atacante podría interceptar el contenido de las conexiones de datos secundarias. [168]
Apretón de manos TLS 1.3
El protocolo de enlace TLS 1.3 se condensó en un solo viaje de ida y vuelta en comparación con los dos viajes de ida y vuelta requeridos en versiones anteriores de TLS/SSL.
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 claves. intercambiar conjeturas. Si el cliente adivina con éxito el algoritmo de intercambio de claves, se elimina 1 viaje de ida y vuelta del protocolo de enlace. Después de recibir ClientHello , el servidor selecciona un cifrado y devuelve un ServerHello con su propia clave pública, seguido del Certificado del servidor y los mensajes Finalizados . [169]
Después de que el cliente recibe el mensaje finalizado del servidor, ahora se coordina con el servidor qué conjunto de cifrado utilizar. [170]
ID de sesión
En un protocolo de enlace completo normal , el servidor envía una identificación de sesión como parte del mensaje ServerHello . El cliente asocia esta identificación de sesión con la dirección IP y el puerto TCP del servidor, de modo que cuando el cliente se conecte nuevamente a ese servidor, pueda usar la identificación de sesión para atajar el protocolo de enlace. En el servidor, la identificación de la sesión se asigna a los parámetros criptográficos negociados previamente, específicamente el "secreto maestro". Ambas partes deben tener el mismo "secreto maestro" o el protocolo de enlace reanudado fallará (esto evita que un espía use una identificación 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 los RFC, este tipo de apretón de manos se denomina apretón de manos abreviado . También se describe en la literatura como un apretón de manos de reinicio .
Fase de negociación:
Un cliente envía un mensaje ClientHello especificando la versión 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. En el mensaje se incluye la identificación de la sesión de la conexión TLS anterior.
El servidor responde con un mensaje ServerHello , que contiene la versión del protocolo elegido, un número aleatorio, un conjunto de cifrado y un método de compresión entre las opciones ofrecidas por el cliente. Si el servidor reconoce la identificación de sesión enviada por el cliente, responde con la misma identificación de sesión . El cliente usa esto para reconocer que se está realizando un protocolo de enlace reanudado. Si el servidor no reconoce la identificación de sesión enviada por el cliente, envía un valor diferente para su identificación de sesión . Esto le dice al cliente que no se realizará un protocolo de enlace reanudado. En este punto, tanto el cliente como el servidor tienen el "secreto maestro" y datos aleatorios para generar los datos clave que se utilizarán para esta conexión.
El servidor ahora envía un registro ChangeCipherSpec , esencialmente diciéndole al cliente: "Todo lo que le diga a partir de ahora estará cifrado". 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 de finalización cifrado que contiene un hash y una MAC sobre los mensajes de protocolo de enlace anteriores.
El cliente intentará descifrar el mensaje Finalizado del servidor y verificará el hash y la MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y 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 estará cifrado".
El cliente envía su propio mensaje finalizado cifrado .
El servidor realiza el mismo procedimiento de descifrado y verificación que realizó 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 de sesión
RFC 5077 amplía TLS mediante el uso de tickets de sesión, en lugar de ID de sesión. Define una forma de reanudar una sesión TLS sin necesidad de que el estado específico de la sesión se almacene en el servidor TLS.
Cuando se utilizan tickets de sesión, el servidor TLS almacena su estado específico de la 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. [160] Esto significa que la información de estado (el ticket de sesión TLS) no está tan bien protegida como la propia sesión TLS. De particular preocupación es el almacenamiento de las claves por parte de OpenSSL en un contexto de toda la aplicación ( SSL_CTX), es decir, durante la vida útil de la aplicación, y no permitir volver a ingresar las claves de los AES128-CBC-SHA256tickets de sesión TLS sin restablecer el contexto de OpenSSL de toda la aplicación (lo cual es poco común). , propenso a errores y a menudo requiere intervención administrativa manual). [161] [159]
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 contenido. Para un mensaje ClientHello, no es necesario que sea la versión más alta admitida por el cliente. Para TLS 1.3 y posteriores, se debe configurar 0x0303 y la aplicación debe enviar 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 exceder 2 14 bytes (16 KiB).
Mensaje(s) de protocolo
Uno o más mensajes identificados por el campo Protocolo. Tenga en cuenta que este campo puede estar cifrado según el estado de la conexión.
MAC y relleno
Un código de autenticación de mensaje 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 incluirse por completo, según el estado de la conexión.
No puede haber campos "MAC" o "relleno" al final de los registros TLS antes de que todos los algoritmos y parámetros de cifrado hayan sido negociados y aceptados y luego confirmados enviando un registro CipherStateChange (ver más abajo) para indicar que estos parámetros tendrán efecto en todos registros adicionales enviados por el mismo par.
Protocolo de apretón de manos
La mayoría de los mensajes intercambiados durante la configuración de la sesión TLS se basan en este registro, a menos que ocurra un error o advertencia y deba ser señalado por un registro de protocolo de alerta (ver más abajo), o que otro registro modifique el modo de cifrado de la sesión ( consulte 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 en un registro.
Protocolo de alerta
Normalmente, este registro no debe enviarse durante un protocolo de enlace normal o 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 esto se usa para señalar un error fatal, la sesión se cerrará inmediatamente después de enviar este registro, por lo que este registro se usa para dar una razón para este cierre. Si el nivel de alerta se marca como 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, 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 faltan antes del cierre de la sesión, la sesión puede reanudarse automáticamente (con sus apretones de manos).
El cierre normal de una sesión después de la finalización de la aplicación transportada debe alertarse preferiblemente con al menos el tipo 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 duración predeterminada que el destinatario de los datos seguros puede 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 la MAC y los trailers de relleno)
MAC
32 bytes para HMAC basado en SHA-256 , 20 bytes para HMAC basado en SHA-1 , 16 bytes para HMAC basado en MD5 .
Relleno
Longitud variable; El último byte contiene la longitud del relleno.
Soporte para servidores virtuales basados en nombres
Desde el punto de vista del protocolo de aplicación, TLS pertenece a una capa inferior, aunque el modelo TCP/IP es demasiado tosco para mostrarlo. Esto significa que el protocolo de enlace TLS generalmente se realiza (excepto en el caso STARTTLS ) antes de que pueda iniciarse el protocolo de aplicación. En la función de servidor virtual basado en nombres que proporciona la capa de aplicación, todos los servidores virtuales cohospedados comparten el mismo certificado porque el servidor tiene que seleccionar y enviar un certificado inmediatamente después del mensaje ClientHello. Este es un gran problema en entornos de hosting 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 conocidas proporcionadas por X.509 :
Si todos los servidores virtuales pertenecen al mismo dominio, se puede utilizar un certificado comodín . [171] Además de la selección vaga del nombre de host que podría ser un problema o no, no existe un acuerdo común sobre cómo hacer coincidir los certificados comodín. Se aplican diferentes reglas según el protocolo de aplicación o el software utilizado. [172]
Agregue cada nombre de host virtual en la extensión sujetoAltName. El principal problema es que es necesario volver a emitir el certificado cada vez que se agrega un nuevo servidor virtual.
Para proporcionar el nombre del servidor, las extensiones RFC 4366 Transport Layer Security (TLS) permiten a los clientes incluir una extensión de indicación de nombre de servidor (SNI) en el mensaje ClientHello extendido. Esta extensión le indica al servidor inmediatamente a qué nombre desea conectarse el cliente, para que el servidor pueda seleccionar el certificado apropiado para enviar a los clientes.
RFC 2817 también documenta un método para implementar alojamiento virtual basado en nombres actualizando HTTP a TLS a través de un encabezado de actualización HTTP/1.1 . Normalmente, esto es para implementar de forma segura HTTP sobre TLS dentro del esquema principal de URI "http" (que evita bifurcar el espacio de URI y reduce la cantidad de puertos utilizados); sin embargo, actualmente, pocas implementaciones admiten esto. [ cita necesaria ]
Estándares
Estándares primarios
La versión actual aprobada de (D)TLS es la versión 1.3, que se especifica en:
RFC 8446: "Protocolo de seguridad de la capa de transporte (TLS) versión 1.3".
RFC 9147: "Protocolo de seguridad de la capa de transporte de datagramas (DTLS) versión 1.3"
La norma actual sustituye a estas versiones anteriores, que ahora se consideran obsoletas:
RFC 5246: "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: "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: "Protocolo Secure Sockets Layer (SSL) versión 3.0".
Borrador de Internet (1995): "El protocolo SSL"
Extensiones
Otros RFC ampliaron posteriormente (D)TLS.
Las extensiones de (D)TLS 1.3 incluyen:
RFC 9367: "Suites de cifrado GOST para el protocolo de seguridad de la capa de transporte (TLS) versión 1.3".
RFC 7366: "Cifrar y luego MAC para seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS)".
RFC 7465: "Prohibición de conjuntos de cifrado RC4".
RFC 7507: "Valor del conjunto de cifrado de señalización alternativa (SCSV) de TLS para prevenir ataques de degradación de protocolo".
RFC 7568: "Desaprobación 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 secreta maestra extendida".
RFC 7685: "Una extensión de relleno ClientHello de seguridad de la capa de transporte (TLS)".
RFC 9189: "Suites 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 tanto un conjunto de extensiones específicas como un mecanismo de extensión genérico.
RFC 5077: "Reanudación de la 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 permiten al servidor y al cliente utilizar la seguridad de la capa de transporte para proporcionar comunicación privada y autenticada a través de Internet.
RFC 2712: "Adición de conjuntos de cifrado Kerberos a la seguridad de la capa de transporte (TLS)". Los conjuntos de cifrado de 40 bits definidos en este memorando aparecen únicamente con el fin de documentar el hecho de que esos códigos de conjunto de cifrado ya han sido asignados.
RFC 2817: "Actualización a TLS dentro de HTTP/1.1", explica cómo utilizar el mecanismo de actualización en HTTP/1.1 para iniciar 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 la seguridad de la capa de transporte para proporcionar comunicación privada y autenticada a través de Internet.
RFC 3268: "Suites de cifrado AES para TLS". Agrega conjuntos de cifrado del Estándar de cifrado avanzado (AES) a los cifrados simétricos previamente existentes.
RFC 3546: "Extensiones de seguridad de la capa de transporte (TLS)", agrega un mecanismo para negociar extensiones de protocolo durante la inicialización de la sesión y define algunas extensiones. Quedó obsoleto por RFC 4366.
RFC 3749: "Métodos de compresión del protocolo de seguridad de la capa de transporte", especifica el marco para los métodos de compresión y el método de compresión DEFLATE .
RFC 3943: "Compresión del protocolo de seguridad de la capa de transporte (TLS) mediante Lempel-Ziv-Stac (LZS)".
RFC 4132: "Adición de Camellia Cipher Suites a Transport Layer Security (TLS)".
RFC 4162: "Adición de SEED Cipher Suites a Transport Layer Security (TLS)".
RFC 4279: "Suites de cifrado de claves precompartidas para seguridad de la capa de transporte (TLS)", agrega tres conjuntos de nuevos conjuntos de cifrado para el protocolo TLS para admitir la autenticación basada en claves precompartidas.
RFC informativos
RFC 7457: "Resumen de los ataques conocidos a la seguridad de la capa de transporte (TLS) y a los datagramas TLS (DTLS)"
RFC 7525: "Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS)"
QUIC (Conexiones rápidas a Internet UDP): "...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.
^ es decir, "Credenciales delegadas para (D) TLS". Rastreador de datos del IETF . Consultado el 29 de noviembre de 2022 .
^ 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 . Consultado el 15 de diciembre de 2018 .
^ "SSL/TLS en detalle". Technet . Documentos de Microsoft . 8 de octubre de 2009 . Consultado el 24 de octubre de 2021 .
^ ab Hooper, Howard (2012). Guía oficial de certificados CCNP Security VPN 642-648 (2 ed.). Prensa de Cisco. pag. 22.ISBN _9780132966382.
^ ab Spott, Andrew; Puerro, Tom; et al. "¿Qué capa es TLS?". Intercambio de pilas de seguridad de la información .
^ abcdef E. Rescorla (agosto de 2018). Protocolo de seguridad de la capa de transporte (TLS), versión 1.3. Grupo de trabajo IETF TLS. doi : 10.17487/RFC8446 . RFC 8446.Norma propuesta. Obsoletos RFC 5077, 5246 y 6961; actualiza 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" . 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 un extremo a otro". En Atiquzzaman, Mahoma; Balandin, Sergey I (eds.). Rendimiento, calidad de servicio y control de redes de sensores y comunicaciones de próxima generación III . vol. 6011. Código bibliográfico : 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".
^ "Preguntas frecuentes de AnyConnect: túneles, comportamiento de reconexión y temporizador de inactividad". Cisco . Consultado el 26 de febrero de 2017 .
^ "Descripción general de la arquitectura de Cisco InterCloud" (PDF) . Sistemas Cisco .
^ "Conexión abierta". OpenConnect . Consultado el 26 de febrero de 2017 .
^ "Seguridad de la capa de transporte de datagramas f5 (DTLS)". Redes f5 .
^ "Configuración de un servidor virtual DTLS". Sistemas Citrix .
^ "Notas de 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 acabar con TLS 1.0» . Consultado el 17 de octubre de 2018 .
^ abcd "Esto es lo nuevo y lo cambiado en Firefox 74.0 estable - gHacks Tech News". www.ghacks.net . 10 de marzo de 2020 . Consultado el 10 de marzo de 2020 .
^ abcd "TLS 1.0 y TLS 1.1: estado de la plataforma Chrome". chromestatus.com . Consultado el 10 de marzo de 2020 .
^ abcde T. Dierks; E. Rescorla (agosto de 2008). Protocolo de seguridad de la capa de transporte (TLS), versión 1.2. Grupo de trabajo IETF TLS. doi : 10.17487/RFC5246 . RFC 5246.Obsoleto. Obsoleto por RFC 8446; obsoletos RFC 3268, 4346 y 4366; actualiza RFC 4492.
^ ab "Uso de TLS para proteger 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".
^ Woo, Thomas YC; Bindignavle, Raghuram; Su, Shaowen; Lam, Simon S. (junio de 1994). SNP: una interfaz para programación de redes segura (PDF) . Actas de la Conferencia técnica de verano de USENIX.
^ "Programa de conferencias técnicas de verano de USENIX de 1994, Boston, 6 a 10 de junio de 1994".
^ Messmer, Ellen. "El padre de SSL, Dr. Taher Elgamal, encuentra proyectos de TI de rápido avance en el Medio Oriente". Mundo de la Red . Archivado desde el original el 31 de mayo de 2014 . Consultado el 30 de mayo de 2014 .
^ Greene, Tim. "El padre de SSL dice que a pesar de los ataques, al eje de seguridad le queda mucha vida". Mundo de la Red . Archivado desde el original el 31 de mayo de 2014 . Consultado el 30 de mayo de 2014 .
^ ab Oppliger, Rolf (2016). "Introducción". SSL y TLS: teoría y práctica (2ª ed.). Casa Artech . pag. 13.ISBN _978-1-60807-999-5. Consultado el 1 de marzo de 2018 a través de Google Books.
^ "EL PROTOCOLO SSL". Corporación Netscape. 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 los navegadores" . Consultado el 29 de febrero de 2020 .
^ "Los cambios en el cumplimiento de PCI llegarán el 30 de junio. ¿Está listo su negocio de comercio electrónico?". Forbes . Consultado el 20 de junio de 2018 .
^ T. Dierks; E. Rescorla (abril de 2006). Protocolo de seguridad de la capa de transporte (TLS), versión 1.1. Grupo de trabajo IETF TLS. doi : 10.17487/RFC4346 . RFC 4346.Histórico. Obsoleto por RFC 5246. Obsoleto RFC 2246.
^ abc "Parámetros de seguridad de la capa de transporte: conjuntos de cifrado". Autoridad de Números Asignados de Internet (IANA) . Consultado el 16 de diciembre de 2022 .
^ "Twitter dejará de admitir TLS 1.0 y TLS 1.1 el 15 de julio". "Hashed Out por The SSL Store" . 2019-07-12 . Consultado el 14 de junio de 2021 .
^ Mackie, Kurt. "Microsoft retrasa el fin del soporte para TLS 1.0 y 1.1 -". Revista profesional certificada de Microsoft en línea .
^ "Preguntas frecuentes sobre TLS 1.2: base de conocimientos". Respuestas.psionline.com . Consultado el 20 de febrero de 2022 .
^ "Diferencias entre TLS 1.2 y TLS 1.3 (#TLS13)". LoboSSL . 2019-09-18. Archivado desde el original el 19 de septiembre de 2019 . Consultado el 18 de septiembre de 2019 .
^ "Notas de la versión NSS 3.29". Red de desarrolladores de Mozilla. Febrero de 2017. Archivado desde el original el 22 de febrero de 2017.
^ "Habilite TLS 1.3 de forma predeterminada". Bugzilla@Mozilla. 16 de octubre de 2016 . Consultado el 10 de octubre de 2017 .
^ "Firefox: Notas (60.0)". Mozilla . Consultado el 10 de mayo de 2018 .
^ "ProxySG, ASG y WSS interrumpirán las conexiones SSL cuando los clientes que usan TLS 1.3 accedan a sitios que también usan TLS 1.3". BlueTouch en línea . 16 de mayo de 2017. Archivado desde el original el 12 de septiembre de 2017 . Consultado el 11 de septiembre de 2017 .
^ Sullivan 2017.
^ Thomson y Pauly 2021, A.6. TLS.
^ Thomson y Pauly 2021, 3.3. Falsificar el uso activo.
^ "Hackatón TLS 1.3 IETF 100". Archivado desde el original el 15 de enero de 2018.
^ ab IETF - Grupo de trabajo de ingeniería de Internet (12 de noviembre de 2017), Presentaciones y premios del Hackathon del IETF, archivado desde el original el 28 de octubre de 2021 , consultado el 14 de noviembre de 2017
^ "¡Hurra! TLS 1.3 ya está aquí. Ahora a implementarlo y ponerlo en software" . Consultado el 28 de marzo de 2018 .
^ 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
^ "La versión BETA de wolfSSL TLS 1.3 ya está disponible". [email protected]. 11 de mayo de 2017 . Consultado el 11 de mayo de 2017 .
^ "Compatibilidad con TLS 1.3 Draft 28 en wolfSSL". [email protected]. 14 de junio de 2018 . Consultado el 14 de junio de 2018 .
^ "Se lanza OpenSSL 1.1.1". Matt Caswell. 11 de septiembre de 2018 . Consultado el 19 de diciembre de 2018 .
^ "Protocolos en TLS/SSL (Schannel SSP)". Documentos de Microsoft . 25 de mayo de 2022 . Consultado el 21 de febrero de 2023 .
^ Hoffman-Andrews, Jacob (26 de febrero de 2019). "ETS no es TLS y no debería usarlo". Fundación Frontera Electrónica . Consultado el 27 de febrero de 2019 .
^ TS 103 523-3 - V1.1.1 - CIBERNÉTICO; Protocolo de seguridad de Middlebox; Parte 3: Perfil para control de acceso a centros de datos y redes empresariales ( PDF ) . ETSI.org . Archivado (PDF) desde el original el 14 de noviembre de 2018.
^ Cory Doctorow (26 de febrero de 2019). "Imprudencia 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) . Conferencia RSA Asia Pacífico. Archivado (PDF) desde el original el 7 de octubre de 2016 . Consultado el 7 de septiembre de 2016 .
^ "Contando certificados SSL". 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 al competidor de seguridad web en un acuerdo de mil millones de dólares". Noticias de Deseret . 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). "El dispositivo de aplicación de la ley subvierte SSL". cableado.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.). "Suites de cifrado de claves precompartidas para seguridad de la capa de transporte (TLS)". Grupo de Trabajo de Ingeniería de Internet . doi :10.17487/RFC4279. RFC 4279 . Archivado desde el original el 5 de septiembre de 2013 . 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 . Archivado desde el original el 7 de diciembre de 2014 . Consultado el 21 de diciembre de 2014 .
^ Gothard, Peter (31 de julio de 2013). "Google actualiza los certificados SSL con cifrado de 2048 bits". Informática . Medios incisivos. Archivado desde el original el 22 de septiembre de 2013 . Consultado el 9 de septiembre de 2013 .
^ "El valor del cifrado de 2048 bits: por qué es importante la longitud de la clave de cifrado". BuscarSeguridad . 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
^ ab RFC 6209
^ RFC 4162
^ "Sobre la (in)seguridad práctica de los cifrados de bloques de 64 bits: ataques de colisión en HTTP a través de TLS y OpenVPN" (PDF) . 2016-10-28. Archivado (PDF) desde el original el 24 de abril de 2017 . Consultado el 8 de junio de 2017 .
^ "Recomendación de la publicación especial 800-57 del NIST para la gestión de claves - Parte 1: General (revisada)" (PDF) . 2007-03-08. Archivado desde el original (PDF) el 6 de junio de 2014 . Consultado el 3 de julio de 2014 .
^ Laboratorios abc Qualys SSL. "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 frente a https". Archivado desde el original el 12 de febrero de 2015 . Consultado el 12 de febrero de 2015 .
^ abcd Al 3 de septiembre de 2023. "SSL Pulse: encuesta sobre la implementación de SSL en los sitios web más populares". Qualys . Consultado el 5 de octubre de 2023 .
^ ab ivanr (19 de marzo de 2013). "RC4 en TLS está roto: ¿y ahora qué?". Laboratorios de seguridad de Qualsys. Archivado desde el original el 27 de agosto de 2013 . Consultado el 30 de julio de 2013 .
^ a b C Bodo Möller, Thai Duong y Krzysztof Kotowicz. "Este POODLE muerde: aprovechando el respaldo de SSL 3.0" (PDF) . Archivado (PDF) desde el original el 14 de octubre de 2014 . Consultado el 15 de octubre de 2014 .
^ "Internet Explorer 11 se ha retirado y oficialmente ya no es compatible: lo que necesita saber". 15 de junio de 2022 . Consultado el 15 de junio de 2022 .
^ "La compatibilidad con la aplicación de escritorio Internet Explorer 11 finalizó para determinadas versiones de Windows 10" . Consultado el 17 de junio de 2022 .
^ "Guía de referencia de Java Secure Socket Extension (JSSE)". Centro de ayuda de Oracle . Consultado el 24 de diciembre de 2021 .
^ Georgiev, Martín; Iyengar, Subodh; Jana, Sumán; Anubhai, Rishita; Boneh, Dan; Shmatikov, Vitaly (2012). El código más peligroso del mundo: validar certificados SSL en software que no es un navegador. Actas de la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones (PDF) . Asociación para Maquinaria de Computación. págs. 38–49. ISBN978-1-4503-1651-4. Archivado (PDF) desde el 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-André, P. (2015). Resumiendo los ataques conocidos a la seguridad de la capa de transporte (TLS) y a los datagramas TLS (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). "Comprensión del ataque de renegociación de TLS". Conjeturas educadas . Archivado desde el original el 11 de febrero de 2012 . Consultado el 27 de noviembre de 2009 .
^ "SSL_CTX_set_options SECURE_RENEGOTIATION". Documentos 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 la versión de GnuTLS . 25 de junio de 2010. Archivado desde el original el 17 de octubre de 2015 . Consultado el 24 de julio de 2011 .
^ "Notas de la versión de NSS 3.12.6". Notas de la versión de NSS . 2010-03-03. Archivado desde el original el 6 de marzo de 2012 . Consultado el 24 de julio de 2011 .
^ A. Langley; N. Modadugu; B. Moeller (2 de junio de 2010). "Inicio en falso de seguridad de la capa de transporte (TLS)". Grupo de Trabajo de Ingeniería de Internet . IETF. Archivado desde el original el 5 de septiembre de 2013 . Consultado el 31 de julio de 2013 .
^ Gruener, Wolfgang. "Comienzo en falso: Google propone una Web más rápida, Chrome ya la admite". Archivado desde el original el 7 de octubre de 2010 . Consultado el 9 de marzo de 2011 .
^ 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, Adrián. "Inicio en falso". SSL/TLS aleatorio 101 . Archivado desde el original el 4 de mayo de 2011 . Consultado el 9 de marzo de 2011 .
^ Mavrogiannopoulos, Nikos; Vercautern, Federico; 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) . Asociación para Maquinaria de Computación. págs. 62–72. ISBN978-1-4503-1651-4. Archivado (PDF) desde el original el 6 de julio de 2015.
^ "SMACK: ataques a máquinas de estado". Archivado desde el original el 12 de marzo de 2015.
^ Goodin, Dan (20 de mayo de 2015). "Un ataque paralizante HTTPS amenaza a decenas de miles de servidores web y de correo". Ars Técnica . 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 se abren a ataques DROWN". El registro . 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 Técnica . Marzo de 2016. Archivado desde el original el 1 de marzo de 2016 . Consultado el 2 de marzo de 2016 .
^ Thai Duong y Juliano Rizzo (13 de mayo de 2011). "Aquí vienen los ⊕ ninjas". Archivado desde el original el 3 de junio de 2014.
^ Goodin, Dan (19 de septiembre de 2011). "Los piratas informáticos rompen el cifrado SSL utilizado por millones de sitios". El registro . Archivado desde el original el 10 de febrero de 2012.
^ "Y Combinator comenta sobre el tema". 2011-09-20. Archivado desde el original el 31 de marzo de 2012.
^ "Seguridad de CBC Ciphersuites en SSL/TLS: problemas y contramedidas". 2004-05-20. Archivado desde el original el 30 de junio de 2012.
^ Ristic, Ivan (10 de septiembre de 2013). "¿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 . 2011-10-25. 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. 2011-09-27. 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 eligió el ataque de texto plano (BEAST) en SSL/TLS 1.0 (facilitado por websockets-76)".
^ MSRC (10 de enero de 2012). Una 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 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). "La grieta en la base de confianza de Internet permite el secuestro de sesiones HTTPS". Ars Técnica . Archivado desde el original el 1 de agosto de 2013 . Consultado el 31 de julio de 2013 .
^ Fisher, Dennis (13 de septiembre de 2012). "CRIME Attack utiliza la relación de compresión de solicitudes TLS como canal lateral para secuestrar sesiones seguras". Publicación de amenazas. 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). "Desapareció en 30 segundos: un nuevo ataque extrae secretos de páginas protegidas por HTTPS". Ars Técnica . Conde Nast. Archivado desde el original el 3 de agosto de 2013 . Consultado el 2 de agosto de 2013 .
^ Leyden, John (2 de agosto de 2013). "Adéntrese en la INCUMPLIMIENTO: nuevo ataque desarrollado para leer datos web cifrados". El registro . Archivado desde el original el 5 de agosto de 2013 . Consultado el 2 de agosto de 2013 .
^ P. Gutmann (septiembre de 2014). "Cifrar 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. Archivado desde el original el 12 de mayo de 2015.
^ Langley, Adam (8 de diciembre de 2014). "El CANICHE vuelve a morder". Archivado desde el original el 8 de diciembre de 2014 . Consultado el 8 de diciembre de 2014 .
^ "ssl: ¿los cifrados más seguros para usar con BEAST? (Explotación TLS 1.0) He leído que RC4 es inmune". Serverfault.com . Consultado el 20 de febrero de 2022 .
^ Pouyan Sepehrdad; Serge Vaudenay; Martín Vuagnoux (2011). "Descubrimiento y explotación de nuevos sesgos en RC4". En Alex Biryukov; Guang Gong; Douglas R. Stinson (eds.). Áreas seleccionadas en criptografía: 17º taller internacional, SAC 2010, Waterloo, Ontario, Canadá, 12 y 13 de agosto de 2010, artículos seleccionados revisados . Apuntes de conferencias sobre 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á algo roto en TLS". Ingeniería de Criptografía . Archivado desde el original el 14 de marzo de 2013 . Consultado el 12 de marzo de 2013 .
^ AlFardan, Nadhem; Bernstein, Dan; Paterson, Kenny; Poettering, Bertram; Schuldt, Jacob. "Sobre la seguridad de RC4 en TLS". Universidad Royal Holloway de Londres. Archivado desde el original el 15 de marzo de 2013 . Consultado el 13 de marzo de 2013 .
^ 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) . Grupo de Seguridad de la Información . 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 USENIX . pag. 51. Archivado (PDF) desde el original el 22 de septiembre de 2013 . Consultado el 2 de septiembre de 2013 . Los ataques de recuperación de texto sin formato contra RC4 en TLS son factibles aunque no realmente prácticos
^ Goodin, Dan (15 de julio de 2015). "El ataque criptográfico que alguna vez fue teórico contra HTTPS ahora roza la practicidad". Ars Técnico . Conde Nast. Archivado desde el original el 16 de julio de 2015 . Consultado el 16 de julio de 2015 .
^ "Configuraciones recomendadas TLS del lado del servidor de Mozilla Security". Mozilla. Archivado desde el original el 3 de enero de 2015 . Consultado el 3 de enero de 2015 .
^ "Aviso de seguridad 2868725: Recomendación para desactivar RC4". Microsoft. 2013-11-12. 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 de Microsoft Edge. 1 de septiembre de 2015. Archivado desde el original el 2 de septiembre de 2015.
^ Langley, Adam (1 de septiembre de 2015). "Intención de desaprobar: RC4".
^ Barnes, Richard (1 de septiembre de 2015). "Intención de envío: RC4 deshabilitado de forma predeterminada en Firefox 44". Archivado desde el original el 22 de enero de 2011.
^ ab John Leyden (1 de agosto de 2013). "Gmail, Outlook.com y el voto electrónico 'arrebatados' en el escenario en un truco para esquivar criptomonedas". El registro . Archivado desde el original el 1 de agosto de 2013 . Consultado el 1 de agosto de 2013 .
^ "Reuniones informativas de BlackHat USA". Sombrero Negro 2013 . Archivado desde el original el 30 de julio de 2013 . Consultado el 1 de agosto de 2013 .
^ Smith, Ben; Pironti, Alfredo (2013). Truncar conexiones TLS para violar creencias en aplicaciones web. Séptimo 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 sin formato contra datagramas TLS (PDF) ". Simposio de 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). "El nuevo ataque elude la protección HTTPS en Mac, Windows y Linux". Ars Técnica . Conde Nast. Archivado desde el original el 27 de julio de 2016 . Consultado el 28 de julio de 2016 .
^ Goodin, Dan (24 de agosto de 2016). "HTTPS y OpenVPN se enfrentan a un nuevo ataque que puede descifrar cookies secretas". Ars Técnica . Archivado desde el original el 24 de agosto de 2016 . Consultado el 24 de agosto de 2016 .
^ "¿Por qué se llama 'Heartbleed Bug'?". El Washington Post . 2014-04-09. Archivado desde el original el 9 de octubre de 2014.
^ "Vulnerabilidad del error Heartbleed [9 de abril de 2014]". Grupo Comodo . Archivado desde el original el 5 de julio de 2014.
^ Bleichenbacher, Daniel (agosto de 2006). "Falsificación de firma RSA de Bleichenbacher basada en un error de implementación". Archivado desde el original el 16 de diciembre de 2014.
^ "BERserk". Seguridad Intel: investigación de amenazas avanzadas. Septiembre de 2014. Archivado desde el original el 12 de enero de 2015.
^ Goodin, Dan (19 de febrero de 2015). "Las PC Lenovo se envían con software publicitario intermediario que interrumpe las conexiones HTTPS". Ars Técnica . 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). "El " ataque prohibido "hace que docenas de sitios HTTPS Visa sean vulnerables a la manipulación". Ars Técnica . 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 autenticados". Diseños, Códigos y Criptografía . 2 (2): 107–125. CiteSeerX 10.1.1.59.6682 . doi :10.1007/BF00124891. S2CID 7356608. Archivado desde el original el 13 de marzo de 2008 . Consultado el 11 de febrero de 2008 .
^ "Discusión sobre la lista de correo de TLS en octubre de 2007". Archivado desde el original el 22 de septiembre de 2013 . Consultado el 20 de febrero de 2022 .
^ "Protección de datos a largo plazo con secreto directo". 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 secreto directo perfecto". Archivado desde el original el 27 de agosto de 2012 . Consultado el 5 de noviembre de 2012 .
^ "SSL Labs: implementación del secreto directo". Qualys.com. 2013-06-25. Archivado desde el original el 26 de junio de 2013 . Consultado el 10 de julio de 2013 .
^ Rístico, Ivan (5 de agosto de 2013). "SSL Labs: implementación del secreto directo". 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 directo de TLS". imperialviolet.org . Archivado desde el original el 8 de agosto de 2013.
^ ab Daignière, Florent. "TLS" Secrets ": documento técnico que presenta las implicaciones de seguridad de la implementación de tickets de sesión (RFC 5077) tal como se implementa en OpenSSL" (PDF) . Matta Consulting Limitado. Archivado (PDF) desde el original el 6 de agosto de 2013 . Consultado el 7 de agosto de 2013 .
^ ab Daignière, Florent. "TLS" Secretos ": Lo que todos olvidaron decirte ..." (PDF) . Matta Consulting Limitado. Archivado (PDF) desde el original el 5 de agosto de 2013 . Consultado el 7 de agosto de 2013 .
^ LS Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "Un estudio experimental de implementaciones de secreto directo de TLS". Computación de Internet IEEE . 18 (6): 43–51. CiteSeerX 10.1.1.663.4653 . doi :10.1109/MIC.2014.86. S2CID 11264303. Archivado desde el original el 20 de septiembre de 2015 . Consultado el 16 de octubre de 2015 .
^ "Protección de datos a largo plazo con secreto directo". Archivado desde el original el 12 de febrero de 2014 . Consultado el 7 de marzo de 2014 .
^ Hoffman-Andrews, Jacob. "Secreto directo en Twitter". Gorjeo. Archivado desde el original el 16 de febrero de 2014 . Consultado el 7 de marzo de 2014 .
^ abc Durumeric, Zakir; Mamá, Zane; Springall, dibujó; Barnes, Ricardo; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 de septiembre de 2017). "El impacto en la seguridad de la interceptación HTTPS". Simposio NDSS . doi :10.14722/ndss.2017.23456. ISBN978-1-891562-46-4.
^ ab Estos certificados son actualmente X.509 , pero RFC 6091 también especifica el uso de certificados basados en OpenPGP .
^ "tls - ¿Diferencias entre los términos" secreto previo al maestro ", "secreto maestro", "clave privada" y "secreto compartido"? Intercambio de pila de criptografía . Consultado el 1 de octubre de 2020 .
^ Chris (18 de febrero de 2009). "Lanzamiento de vsftpd-2.1.0: uso de la reanudación de sesión TLS para la autenticación de conexión de datos FTPS". Seguridad de la bestia aterradora. blogspot.com. Archivado desde el original el 7 de julio de 2012 . Consultado el 17 de mayo de 2012 .
^ Rescorla, Eric (agosto de 2018). "Protocolo de seguridad de la capa de transporte (TLS) versión 1.3". Editor RFC del IETF .
^ Valsorda, Filippo (23 de septiembre de 2016). "Una descripción general de TLS 1.3 y preguntas y respuestas". El blog de Cloudflare .
^ 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) desde el original el 3 de agosto de 2012 , consultado el 17 de mayo de 2012
Trabajos citados
Sullivan, Nick (26 de diciembre de 2017). "Por qué TLS 1.3 aún no está en los navegadores". El blog de Cloudflare . Consultado el 14 de marzo de 2020 .
Thomson, Martín; Pauly, Tommy (diciembre de 2021). Viabilidad a largo plazo de los mecanismos de extensión del protocolo. doi : 10.17487/RFC9170 . RFC 9170.
Otras lecturas
Wikimedia Commons tiene medios relacionados con SSL y TLS .
Wagner, David; Schneier, Bruce (noviembre de 1996). «Análisis del Protocolo SSL 3.0» (PDF) . El Segundo Taller USENIX sobre Procedimientos de Comercio Electrónico . Prensa USENIX. págs. 29–40.
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). Conceptos básicos de SSL y TLS para proteger la Web . Nueva York: Wiley. ISBN 978-0-471-38354-3.
Bardo, Gregory (2006). "Un ataque de texto sin formato elegido, desafiante pero factible, adaptable en bloques a SSL". Asociación Internacional para la Investigación Criptológica (136) . Consultado el 23 de septiembre de 2011 .
Canvel, Brice. "Interceptació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 Renegociación TLS . 2010. doi : 10.17487/RFC5746. RFC 5746 .
Creación de VPN con IPsec y SSL/TLS Artículo de Linux Journal de Rami Rosen
Josué Davies (2010). Implementación de SSL/TLS . Wiley. ISBN 978-0470920411.
Polk, Tim; McKay, Kerry; Chokhani, Santosh (abril de 2014). "Directrices para la selección, configuración y uso de implementaciones de seguridad de la capa de transporte (TLS)" (PDF) . Instituto Nacional de Estándares y Tecnología. Archivado desde el original (PDF) el 8 de mayo de 2014 . Consultado el 7 de mayo de 2014 .
Abdou, AbdelRahman; van Oorschot, Paul (agosto de 2017). "Verificación de la ubicación del servidor (SLV) y fijación de la ubicación del servidor: aumento de la autenticación TLS". Transacciones sobre Privacidad y Seguridad . ACM. 21 (1): 1:1–1:26. doi :10.1145/3139294. S2CID 5869541.
Iván Ristic (2022). TLS y PKI a prueba de balas, segunda edición . Pato luchador. ISBN 978-1907117091.
enlaces externos
Grupo de trabajo de ingeniería de Internet: grupo de trabajo TLS
