Seguridad de la capa de transporte

Transport Layer Security ( TLS ) es un protocolo criptográfico diseñado para proporcionar seguridad en las comunicaciones a través de una red informática, como Internet . El protocolo se utiliza ampliamente en aplicaciones como el correo electrónico , la mensajería instantánea y la voz sobre IP , pero su uso para proteger HTTPS sigue siendo el más visible públicamente.

El protocolo TLS tiene como objetivo principal proporcionar seguridad, incluida la privacidad (confidencialidad), integridad y autenticidad mediante el uso de criptografía , como el uso de certificados , entre dos o más aplicaciones informáticas que se comunican. Se ejecuta en la capa de presentación y está compuesto por dos capas: el registro TLS y los protocolos de enlace TLS .

El protocolo de seguridad de la capa de transporte de datagramas ( DTLS ) es un protocolo de comunicaciones estrechamente relacionado que proporciona seguridad a las aplicaciones basadas en datagramas . En los textos técnicos, se suelen ver referencias a "( D ) TLS " cuando se aplica a ambas versiones. ^[1]

TLS es un estándar propuesto por el Internet Engineering Task Force (IETF), definido por primera vez en 1999, y la versión actual es TLS 1.3, definida en agosto de 2018. TLS se basa en las especificaciones SSL ( Secure Sockets Layer ) ahora obsoletas (1994, 1995, 1996) desarrolladas por Netscape Communications para agregar el protocolo HTTPS a su navegador web Netscape Navigator .

Las aplicaciones cliente-servidor utilizan el protocolo TLS para comunicarse a través de una red de un modo que evita escuchas clandestinas y manipulaciones .

Dado que las aplicaciones pueden comunicarse con o sin TLS (o SSL), es necesario que el cliente solicite al servidor que configure una conexión TLS. ^[2] Una de las principales formas de lograr esto es utilizar un número de puerto diferente para las conexiones TLS. El puerto 80 se utiliza normalmente para el tráfico HTTP sin cifrar, mientras que el puerto 443 es el puerto común utilizado para el tráfico HTTPS cifrado . Otro mecanismo es realizar una solicitud STARTTLS específica del protocolo al servidor para cambiar la conexión a TLS, por ejemplo, cuando se utilizan los protocolos de correo y noticias .

Una vez que el cliente y el servidor han acordado utilizar TLS, negocian una conexión con estado mediante un procedimiento de protocolo de enlace (consulte § Protocolo de enlace TLS). ^[3] Los protocolos utilizan un protocolo de enlace con un cifrado asimétrico para establecer no solo las configuraciones de cifrado sino también una clave compartida específica de la sesión con la que se cifra la comunicación posterior mediante un cifrado simétrico . Durante este protocolo de enlace, el cliente y el servidor acuerdan varios parámetros utilizados para establecer la seguridad de la conexión:

• El protocolo de enlace comienza cuando un cliente se conecta a un servidor habilitado para TLS solicitando una conexión segura y el cliente presenta una lista de conjuntos de cifrados compatibles ( cifrados y funciones hash ).
• De esta lista, el servidor selecciona un cifrado y una función hash que también admite y notifica la decisión al cliente.
• El servidor suele proporcionar una identificación en forma de certificado digital . El certificado contiene el nombre del servidor , la autoridad de certificación (CA) de confianza que garantiza la autenticidad del certificado y la clave de cifrado pública del servidor.
• El cliente confirma la validez del certificado antes de continuar.
• Para generar las claves de sesión utilizadas para la conexión segura, el cliente:
  • cifra un número aleatorio ( PreMasterSecret ) con la clave pública del servidor y envía el resultado al servidor (que sólo el servidor debería poder descifrar con su clave privada); ambas partes utilizan el número aleatorio para generar una clave de sesión única para el cifrado y descifrado posterior de datos durante la sesión, o
  • utiliza el intercambio de claves Diffie-Hellman (o su variante DH de curva elíptica ) para generar de forma segura una clave de sesión aleatoria y única para el cifrado y descifrado que tiene la propiedad adicional de secreto hacia adelante : si la clave privada del servidor se divulga en el futuro, no se puede utilizar para descifrar la sesión actual, incluso si la sesión es interceptada y grabada por un tercero.

Esto concluye el protocolo de enlace y comienza la conexión segura, que se cifra y descifra con la clave de sesión hasta que se cierra la conexión. Si alguno de los pasos anteriores falla, el protocolo de enlace TLS falla y la conexión no se crea.

TLS y SSL no encajan perfectamente en ninguna capa del modelo OSI o del modelo TCP/IP . ^{[4] [5]} TLS se ejecuta "sobre algún protocolo de transporte confiable (por ejemplo, TCP)", ^{[6] : §1,} lo que implicaría que está por encima de la capa de transporte . Proporciona cifrado a capas superiores, que normalmente es la función de la capa de presentación . Sin embargo, las aplicaciones generalmente usan TLS como si fuera una capa de transporte, ^{[4] [5]} aunque las aplicaciones que usan TLS deben controlar activamente el inicio de los protocolos de enlace TLS y el manejo de los certificados de autenticación intercambiados. ^{[6] : §1}

Cuando están protegidas por TLS, las conexiones entre un cliente (por ejemplo, un navegador web) y un servidor (por ejemplo, wikipedia.org) tendrán todas las siguientes propiedades: ^{[6] : §1}

• La conexión es privada (o tiene confidencialidad ) porque se utiliza un algoritmo de clave simétrica para cifrar los datos transmitidos. Las claves para este cifrado simétrico se generan de forma única para cada conexión y se basan en un secreto compartido que se negoció al inicio de la sesión. El servidor y el cliente negocian los detalles de qué algoritmo de cifrado y claves criptográficas utilizar antes de que se transmita el primer byte de datos (ver más abajo). La negociación de un secreto compartido es a la vez segura (el secreto negociado no está disponible para los espías y no puede ser obtenido, ni siquiera por un atacante que se coloque en medio de la conexión) y fiable (ningún atacante puede modificar las comunicaciones durante la negociación sin ser detectado).
• La identidad de las partes que se comunican puede autenticarse mediante criptografía de clave pública . Esta autenticación es obligatoria para el servidor y opcional para el cliente.
• La conexión es confiable (o tiene integridad ) porque cada mensaje transmitido incluye una verificación de integridad del mensaje utilizando un código de autenticación de mensaje para evitar la pérdida o alteración no detectada de los datos durante la transmisión.

TLS admite muchos métodos diferentes para intercambiar claves, cifrar datos y autenticar la integridad de los mensajes. Como resultado, la configuración segura de TLS implica muchos parámetros configurables y no todas las opciones proporcionan todas las propiedades relacionadas con la privacidad descritas en la lista anterior (consulte las tablas a continuación § Intercambio de claves, § Seguridad de cifrado y § Integridad de datos).

Se han hecho intentos para subvertir aspectos de la seguridad de las comunicaciones que TLS busca proporcionar, y el protocolo ha sido revisado varias veces para abordar estas amenazas de seguridad. Los desarrolladores de navegadores web han revisado repetidamente sus productos para defenderse de posibles debilidades de seguridad después de que estas se descubrieran (consulte el historial de compatibilidad de TLS/SSL de los navegadores web).

Datagram Transport Layer Security, abreviado DTLS, es un protocolo de comunicaciones relacionado que proporciona seguridad a las aplicaciones basadas en datagramas al permitirles comunicarse de una manera diseñada ^{[7] [8]} para evitar escuchas clandestinas , manipulaciones o falsificación de mensajes . El protocolo DTLS se basa en el protocolo Transport Layer Security (TLS) orientado a flujos y está destinado a proporcionar garantías de seguridad similares. Sin embargo, a diferencia de TLS, se puede utilizar con la mayoría de los protocolos orientados a datagramas, incluidos el Protocolo de datagramas de usuario (UDP), el Protocolo de control de congestión de datagramas (DCCP), el Control y aprovisionamiento de puntos de acceso inalámbricos (CAPWAP), la encapsulación del Protocolo de transmisión de control de flujo (SCTP) y el Protocolo de transporte seguro en tiempo real (SRTP).

Como el datagrama del protocolo DTLS conserva la semántica del transporte subyacente (la aplicación no sufre los retrasos asociados con los protocolos de flujo), sin embargo, la aplicación tiene que lidiar con la reordenación de paquetes , la pérdida de datagramas y datos más grandes que el tamaño de un paquete de red de datagramas . Debido a que DTLS utiliza UDP o SCTP en lugar de TCP, evita el problema de la fusión de TCP [ ^{9] [10]} cuando se utiliza para crear un túnel VPN.

La versión 1.0 de DTLS publicada originalmente en 2006 no era un documento independiente, sino que se presentó como una serie de modificaciones de TLS 1.1. ^[11] De manera similar, la versión 2012 de DTLS es una modificación de TLS 1.2. Se le asignó el número de versión de DTLS 1.2 para que coincida con su versión de TLS. Por último, la versión 1.3 de DTLS de 2022 es una modificación de TLS 1.3. Al igual que las dos versiones anteriores, DTLS 1.3 tiene como objetivo proporcionar "garantías de seguridad equivalentes [a TLS 1.3] con la excepción de la protección de órdenes y la imposibilidad de volver a reproducir". ^[12]

Muchos clientes VPN, incluidos Cisco AnyConnect ^[13] e InterCloud Fabric, ^[14] OpenConnect , ^{[15] el túnel} ZScaler , ^[16] el cliente VPN Edge de F5 Networks , ^[17] y Citrix Systems NetScaler ^[18], utilizan DTLS para proteger el tráfico UDP. Además, todos los navegadores web modernos admiten DTLS-SRTP ^[19] para WebRTC .

El Protocolo de Seguridad de la Capa de Transporte (TLS), junto con otras plataformas básicas de seguridad de red, fue desarrollado a través de una iniciativa conjunta que comenzó en agosto de 1986, entre la Agencia de Seguridad Nacional, la Oficina Nacional de Normas, la Agencia de Comunicaciones de Defensa y doce corporaciones de comunicaciones e informáticas que iniciaron un proyecto especial llamado Sistema de Red de Datos Seguros (SDNS). ^[26] El programa fue descrito en septiembre de 1987 en la 10.ª Conferencia Nacional de Seguridad Informática en un amplio conjunto de artículos publicados. El innovador programa de investigación se centró en el diseño de la próxima generación de redes de comunicaciones informáticas seguras y especificaciones de productos para su implementación en aplicaciones en internets públicas y privadas. Su objetivo era complementar los nuevos estándares de internet OSI que estaban surgiendo rápidamente y que avanzaban tanto en los perfiles GOSIP del gobierno de los EE. UU. como en el enorme esfuerzo internacional de internet ITU-ISO JTC1. Originalmente conocido como protocolo SP4, fue renombrado TLS y posteriormente publicado en 1995 como estándar internacional ITU-T X.274|ISO/IEC 10736:1995.

Los primeros esfuerzos de investigación en pos de la seguridad de la capa de transporte incluyeron la interfaz de programación de aplicaciones (API) Secure Network Programming (SNP ), que en 1993 exploró el enfoque de tener una API de capa de transporte segura que se asemejara mucho a los sockets de Berkeley , para facilitar la modernización de aplicaciones de red preexistentes con medidas de seguridad. SNP se publicó y presentó en la Conferencia Técnica de Verano USENIX de 1994. ^{[27] [28]} El proyecto SNP fue financiado por una subvención de la NSA al profesor Simon Lam en UT-Austin en 1991. ^[29] Secure Network Programming ganó el premio ACM Software System Award en 2004. ^{[30] [31]} Simon Lam fue incluido en el Salón de la Fama de Internet por "inventar sockets seguros e implementar la primera capa de sockets seguros, llamada SNP, en 1993". ^{[32] [33]}

Netscape desarrolló los protocolos SSL originales, y Taher Elgamal , científico jefe de Netscape Communications de 1995 a 1998, ha sido descrito como el "padre de SSL". ^{[34] [35] [36] [37]} La ​​versión 1.0 de SSL nunca se lanzó públicamente debido a graves fallos de seguridad en el protocolo. La versión 2.0, después de ser lanzada en febrero de 1995, se descubrió rápidamente que contenía una serie de fallos de seguridad y usabilidad. Utilizaba las mismas claves criptográficas para la autenticación y el cifrado de mensajes. Tenía una construcción MAC débil que utilizaba la función hash MD5 con un prefijo secreto, lo que la hacía vulnerable a ataques de extensión de longitud. Tampoco proporcionaba protección ni para el apretón de manos de apertura ni para un cierre explícito de mensaje, lo que significaba que los ataques de intermediario podían pasar desapercibidos. Además, SSL 2.0 asumía un servicio único y un certificado de dominio fijo, lo que entraba en conflicto con la característica ampliamente utilizada de alojamiento virtual en servidores web, por lo que la mayoría de los sitios web se veían efectivamente afectados por el uso de SSL.

Estas fallas hicieron necesario un rediseño completo del protocolo a la versión SSL 3.0. ^{[38] [36]} Lanzado en 1996, fue producido por Paul Kocher en colaboración con los ingenieros de Netscape Phil Karlton y Alan Freier, con una implementación de referencia de Christopher Allen y Tim Dierks de Certicom. Las versiones más nuevas de SSL/TLS se basan en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por IETF como un documento histórico en RFC  6101.

SSL 2.0 quedó obsoleto en 2011 por RFC  6176. En 2014, se descubrió que SSL 3.0 era vulnerable al ataque POODLE que afecta a todos los cifrados de bloque en SSL; RC4 , el único cifrado no de bloque compatible con SSL 3.0, también es factiblemente vulnerado tal como se usa en SSL 3.0. ^[39] SSL 3.0 quedó obsoleto en junio de 2015 por RFC  7568.

TLS 1.0 se definió por primera vez en el RFC  2246 en enero de 1999 como una actualización de SSL versión 3.0, y fue escrito por Christopher Allen y Tim Dierks de Certicom. Como se indica en el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dramáticas, pero son lo suficientemente significativas como para impedir la interoperabilidad entre TLS 1.0 y SSL 3.0". Tim Dierks escribió más tarde que estos cambios, y el cambio de nombre de "SSL" a "TLS", fueron un gesto para salvar las apariencias ante Microsoft, "para que no pareciera que la IETF estaba simplemente aprobando el protocolo de Netscape". ^[40]

El PCI Council sugirió que las organizaciones migren de TLS 1.0 a TLS 1.1 o superior antes del 30 de junio de 2018. ^{[41] [42]} En octubre de 2018, Apple , Google , Microsoft y Mozilla anunciaron conjuntamente que dejarían obsoletos TLS 1.0 y 1.1 en marzo de 2020. ^[20] TLS 1.0 y 1.1 quedaron obsoletos formalmente en RFC  8996 en marzo de 2021.

TLS 1.1 se definió en RFC 4346 en abril de 2006. ^[43] Es una actualización de la versión 1.0 de TLS. Las diferencias significativas en esta versión incluyen:

• Protección adicional contra ataques de encadenamiento de bloques cifrados (CBC).
  • El vector de inicialización implícito (IV) fue reemplazado por un IV explícito.
  • Cambio en el manejo de errores de relleno .
• Soporte para el registro de parámetros de la IANA . ^[44]

La compatibilidad con las versiones 1.0 y 1.1 de TLS fue ampliamente descontinuada por los sitios web alrededor de 2020, lo que deshabilitó el acceso a las versiones de Firefox anteriores a la 24 y a los navegadores basados ​​en Chromium anteriores a la 29. ^{[45] [46]}

TLS 1.2 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 la función pseudoaleatoria (PRF) fue reemplazada por SHA-256 , con una opción para usar PRF especificadas por el conjunto de cifrado .
• La combinación MD5 y SHA-1 en el hash del mensaje final fue reemplazada por SHA-256, con una opción para usar algoritmos hash específicos del conjunto de cifrados. Sin embargo, el tamaño del hash en el mensaje final debe seguir siendo de al menos 96 bits . ^{[23] : §7.4.9}
• La combinación MD5 y SHA-1 en el elemento firmado digitalmente fue reemplazada por un único hash negociado durante el protocolo de enlace , que por defecto es SHA-1.
• Mejora en la capacidad del cliente y del servidor para especificar qué hashes y algoritmos de firma aceptan.
• Ampliación del soporte para cifrados autenticados , utilizados principalmente para el modo Galois/Counter (GCM) y el modo CCM del cifrado del Estándar de cifrado avanzado (AES).
• Se agregaron la definición de extensiones TLS y conjuntos de cifrado AES. ^[44]

Todas las versiones de TLS se perfeccionaron en el RFC  6176 en marzo de 2011, eliminando su compatibilidad con SSL de modo que las sesiones TLS nunca negocien el uso de la versión 2.0 de Secure Sockets Layer (SSL). Actualmente no hay una fecha oficial para que TLS 1.2 quede obsoleto. Las especificaciones para TLS 1.2 también se redefinieron en el Documento de seguimiento de estándares RFC  8446 para mantenerlo lo más seguro posible; ahora debe verse como un protocolo de conmutación por error, destinado solo a ser negociado con clientes que no pueden comunicarse a través de TLS 1.3 (la definición original de RFC 5246 para TLS 1.2 está obsoleta desde entonces).

TLS 1.3 se definió en RFC 8446 en agosto de 2018. ^[6] Se basa en la especificación TLS 1.2 anterior. Las principales diferencias con TLS 1.2 incluyen: ^[47]

• Separación de los algoritmos de acuerdo de clave y autenticación de los conjuntos de cifrados ^{[44] [6] : §11}
• Eliminación del soporte para curvas elípticas con nombre débiles y menos utilizadas
• Eliminación de la compatibilidad con las funciones hash criptográficas MD5 y SHA-224
• Requerir firmas digitales incluso cuando se utiliza una configuración previa
• Integrando HKDF y la propuesta semiefímera DH
• Sustitución de la reanudación con PSK y billetes
• Compatibilidad con protocolos de enlace RTT 1 y compatibilidad inicial con RTT 0
• Obligación de mantener un secreto perfecto hacia adelante , mediante el uso de claves efímeras durante el acuerdo de claves (EC)DH
• Abandono del soporte para muchas características inseguras u obsoletas, incluyendo compresión , renegociación, cifrados no AEAD , cifrados nulos , ^[48] intercambio de claves no PFS (entre los que se encuentran los intercambios de claves RSA estáticas y DH estáticas), grupos DHE personalizados , negociación de formato de punto EC, protocolo de cambio de especificación de cifrado, tiempo UNIX de mensaje Hello y el campo de longitud de entrada AD a cifrados AEAD
• Prohibición de negociación SSL o RC4 por compatibilidad con versiones anteriores
• Integración del uso del hash de sesión
• Desaprobar el uso del número de versión de la capa de registro y congelar el número para mejorar la compatibilidad con versiones anteriores
• Trasladar algunos detalles del algoritmo relacionados con la seguridad de un apéndice a la especificación y relegar ClientKeyShare a un apéndice
• Cómo agregar el cifrado de flujo ChaCha20 con el código de autenticación de mensajes Poly1305
• Adición de los algoritmos de firma digital Ed25519 y Ed448
• Adición de los protocolos de intercambio de claves x25519 y x448
• Agregar compatibilidad para enviar múltiples respuestas OCSP
• Cifrado de todos los mensajes de protocolo de enlace después de ServerHello

Network Security Services (NSS), la biblioteca de criptografía desarrollada por Mozilla y utilizada por su navegador web Firefox , habilitó TLS 1.3 de forma predeterminada en febrero de 2017. ^[49] Posteriormente, se agregó soporte para TLS 1.3 (pero debido a problemas de compatibilidad para una pequeña cantidad de usuarios, no se habilitó automáticamente ^[50] ) a Firefox 52.0 , que se lanzó en marzo de 2017. TLS 1.3 se habilitó de forma predeterminada en mayo de 2018 con el lanzamiento de Firefox 60.0 . ^[51]

Google Chrome estableció TLS 1.3 como la versión predeterminada por un corto tiempo en 2017. Luego lo eliminó como predeterminado, debido a middleboxes incompatibles como los proxies web Blue Coat . ^[52]

La intolerancia de la nueva versión de TLS fue la osificación del protocolo ; los middleboxes habían osificado el parámetro de versión del protocolo. Como resultado, la versión 1.3 imita la imagen de cable de la versión 1.2. Este cambio se produjo muy tarde en el proceso de diseño, y solo se descubrió durante la implementación del navegador. ^[53] El descubrimiento de esta intolerancia también llevó a que se abandonara la estrategia de negociación de la versión anterior, en la que se elegía la versión con mayor coincidencia, debido a niveles de osificación inviables. ^[54] El " engrasado " de un punto de extensión, en el que un participante del protocolo reclama soporte para extensiones inexistentes para garantizar que se toleren extensiones no reconocidas pero realmente existentes y, por lo tanto, para resistir la osificación, fue diseñado originalmente para TLS, pero desde entonces se ha adoptado en otros lugares. ^[54]

Durante el IETF 100 Hackathon , que tuvo lugar en Singapur en 2017, el Grupo TLS trabajó en la adaptación de aplicaciones de código abierto para utilizar TLS 1.3. ^{[55] [56]} El grupo TLS estaba formado por personas de Japón, Reino Unido y Mauricio a través del equipo cyberstorm.mu. ^[56] Este trabajo continuó en el IETF 101 Hackathon en Londres , ^[57] y el IETF 102 Hackathon en Montreal. ^[58]

wolfSSL habilitó el uso de TLS 1.3 a partir de la versión 3.11.1, lanzada en mayo de 2017. ^[59] Como la primera implementación comercial de TLS 1.3, wolfSSL 3.11.1 admitía el borrador 18 y ahora admite el borrador 28, ^[60] la versión final, así como muchas versiones anteriores. Se publicó una serie de blogs sobre la diferencia de rendimiento entre TLS 1.2 y 1.3. ^[61]

EnSeptiembre de 2018El popular proyecto OpenSSL lanzó la versión 1.1.1 de su biblioteca, en la que el soporte para TLS 1.3 era "la característica principal". ^[62]

Se agregó compatibilidad con TLS 1.3 a Secure Channel (schannel) para las versiones GA de Windows 11 y Windows Server 2022. [ ^63]

La Electronic Frontier Foundation elogió a TLS 1.3 y expresó su preocupación por el protocolo variante Enterprise Transport Security (ETS) que deshabilita intencionalmente importantes medidas de seguridad en TLS 1.3. ^[64] Originalmente llamado Enterprise TLS (eTLS), ETS es un estándar publicado conocido como ' ETSI TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". Está destinado a usarse completamente dentro de redes propietarias como sistemas bancarios. ETS no admite el secreto hacia adelante para permitir que las organizaciones de terceros conectadas a las redes propietarias puedan usar su clave privada para monitorear el tráfico de la red para la detección de malware y para facilitar la realización de auditorías. ^{[65] [66]} A pesar de los supuestos beneficios, la EFF advirtió que la pérdida del secreto hacia adelante podría facilitar la exposición de los datos y dijo que existen mejores formas de analizar el tráfico. ^[64]

Un certificado digital certifica la propiedad de una clave pública por parte del sujeto designado del certificado e indica ciertos usos esperados de esa clave. Esto permite que otros (partes que confían) confíen en las firmas o en las afirmaciones realizadas por la clave privada que corresponde a la clave pública certificada. Los almacenes de claves y los almacenes de confianza pueden tener varios formatos, como .pem , .crt, .pfx y .jks .

TLS generalmente depende de un conjunto de autoridades de certificación de terceros de confianza para establecer la autenticidad de los certificados. La confianza suele estar anclada en una lista de certificados distribuidos con software de agente de usuario ^[67] y puede ser modificada por la parte que confía.

Según Netcraft , que monitorea los certificados TLS activos, la autoridad de certificación (CA) líder del mercado ha sido Symantec desde el comienzo de su encuesta (o VeriSign antes de que Symantec comprara la unidad de negocios de servicios de autenticación). En 2015, Symantec representaba poco menos de un tercio de todos los certificados y el 44% de los certificados válidos utilizados por el millón de sitios web más activos, según los recuentos de Netcraft. ^[68] En 2017, Symantec vendió su negocio TLS/SSL a DigiCert. ^[69] En un informe actualizado, se mostró que IdenTrust , DigiCert y Sectigo son las 3 principales autoridades de certificación en términos de participación de mercado desde mayo de 2019. ^[70]

Como consecuencia de la elección de los certificados X.509 , se necesitan autoridades de certificación y una infraestructura de clave pública para verificar la relación entre un certificado y su propietario, así como para generar, firmar y administrar la validez de los certificados. Si bien esto puede ser más conveniente que verificar las identidades a través de una red de confianza , las revelaciones de vigilancia masiva de 2013 hicieron que se conociera más ampliamente que las autoridades de certificación son un punto débil desde el punto de vista de la seguridad, ya que permiten ataques de intermediarios (MITM) si la autoridad de certificación coopera (o se ve comprometida). ^{[71] [72]}

• Cifrado : los certificados SSL cifran los datos enviados entre un servidor web y el navegador de un usuario, lo que garantiza que la información confidencial esté protegida durante toda la transmisión. Esta tecnología de cifrado impide que terceros no autorizados intercepten e interpreten los datos, lo que los protege de posibles riesgos como la piratería o las violaciones de datos.
• Autenticación : los certificados SSL también ofrecen autenticación, certificando la integridad de un sitio web y que los visitantes se están conectando al servidor correcto y no a un impostor malicioso. Este método de autenticación ayuda a los consumidores a ganar confianza al garantizar que están tratando con un sitio web seguro y confiable.
• Integridad : otra función importante de los certificados SSL es garantizar la integridad de los datos. SSL utiliza técnicas criptográficas para verificar que los datos comunicados entre el servidor y el navegador estén intactos y no se hayan modificado durante el tránsito. Esto evita que actores maliciosos interfieran con los datos, lo que garantiza su integridad y confiabilidad.

Antes de que un cliente y un servidor puedan comenzar a intercambiar información protegida por TLS, deben intercambiar o acordar de forma segura una clave de cifrado y un cifrado para usar al cifrar los datos (consulte § Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves se encuentran: claves públicas y privadas generadas con RSA (denominadas TLS_RSA en el protocolo de enlace TLS), Diffie-Hellman (TLS_DH), Diffie-Hellman efímero (TLS_DHE), Diffie-Hellman de curva elíptica (TLS_ECDH), Diffie-Hellman efímero de curva elíptica (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon), ^[23] clave precompartida (TLS_PSK) ^[73] y contraseña remota segura (TLS_SRP). ^[74]

Los métodos de acuerdo de claves TLS_DH_anon y TLS_ECDH_anon no autentican al servidor ni al usuario y, por lo tanto, rara vez se utilizan porque son vulnerables a ataques de intermediarios . Solo TLS_DHE y TLS_ECDHE brindan confidencialidad hacia adelante.

Los certificados de clave pública utilizados durante el intercambio/acuerdo también varían en el tamaño de las claves de cifrado públicas/privadas utilizadas durante el intercambio y, por lo tanto, en la solidez de la seguridad proporcionada. En julio de 2013, Google anunció que ya no utilizaría claves públicas de 1024 bits y que cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios porque la solidez del cifrado está directamente relacionada con el tamaño de la clave . ^{[75] [76]}

Notas

Se utiliza un código de autenticación de mensajes (MAC) para la integridad de los datos. HMAC se utiliza para el modo CBC de cifrados de bloques. El cifrado autenticado (AEAD), como el modo GCM y CCM, utiliza MAC integrado con AEAD y no utiliza HMAC . ^{[6] : §8.4} Se utiliza PRF basado en HMAC o HKDF para el protocolo de enlace 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 .

Históricamente, TLS se ha utilizado principalmente con protocolos de transporte fiables como el Protocolo de Control de Transmisión (TCP). Sin embargo, también se ha implementado con protocolos de transporte orientados a datagramas, como el Protocolo de Datagramas de Usuario (UDP) y el Protocolo de Control de Congestión de Datagramas (DCCP), cuyo uso se ha estandarizado de forma independiente utilizando el término Seguridad de la Capa de Transporte de Datagramas ( DTLS ).

Un uso principal de TLS es proteger el tráfico de la World Wide Web entre un sitio web y un navegador web codificado con el protocolo HTTP. Este uso de TLS para proteger el tráfico HTTP constituye el protocolo HTTPS . ^[91]

Notas

A partir de abril de 2016 ^[actualizar], las últimas versiones de los principales navegadores web admiten TLS 1.0, 1.1 y 1.2, y los tienen habilitados de forma predeterminada. Sin embargo, no todos los sistemas operativos de Microsoft compatibles admiten la última versión de IE. Además, muchos sistemas operativos de Microsoft admiten actualmente varias versiones de IE, pero esto ha cambiado según las Preguntas frecuentes sobre la política de ciclo de vida de soporte de Internet Explorer de Microsoft Archivado el 20 de junio de 2023 en Wayback Machine , "a partir del 12 de enero de 2016, solo la versión más actual de Internet Explorer disponible para un sistema operativo compatible recibirá soporte técnico y actualizaciones de seguridad". La página luego continúa enumerando la última versión compatible de IE en esa fecha para cada sistema operativo. La próxima fecha crítica sería cuando un sistema operativo llegue al final de la etapa de vida útil. Desde el 15 de junio de 2022, Internet Explorer 11 dejó de ser compatible con las ediciones de Windows 10 que siguen la Política de ciclo de vida moderno de Microsoft. ^{[95] [96]}

Las mitigaciones contra ataques conocidos aún no son suficientes:

• Medidas de mitigación contra ataques POODLE: algunos navegadores ya impiden la reversión a SSL 3.0; sin embargo, esta mitigación debe ser compatible no solo con los clientes sino también con los servidores. Es necesario deshabilitar SSL 3.0, implementar una "división de registros anti-POODLE" o denegar los cifrados CBC en SSL 3.0.
  • Google Chrome: completo (TLS_FALLBACK_SCSV está implementado desde la versión 33, el respaldo a SSL 3.0 está deshabilitado desde la versión 39, SSL 3.0 en sí está deshabilitado de manera predeterminada desde la versión 40. El soporte de SSL 3.0 en sí se eliminó desde la versión 44).
  • Mozilla Firefox: completo (el soporte de SSL 3.0 en sí se abandonó desde la versión 39. SSL 3.0 en sí está deshabilitado de manera predeterminada y el respaldo a SSL 3.0 está deshabilitado desde la versión 34 , TLS_FALLBACK_SCSV se implementó desde la versión 35. En ESR, SSL 3.0 en sí está deshabilitado de manera predeterminada y TLS_FALLBACK_SCSV se implementó desde ESR 31.3.0.)
  • Internet Explorer: parcial (sólo en la versión 11, SSL 3.0 está deshabilitado por defecto desde abril de 2015. La versión 10 y anteriores siguen siendo vulnerables a POODLE).
  • Opera : completo (TLS_FALLBACK_SCSV se implementa desde la versión 20, la "división de registros anti-POODLE", que es efectiva solo con la implementación del lado del cliente, se implementa desde la versión 25, SSL 3.0 en sí está deshabilitado de manera predeterminada desde la versión 27. El soporte de SSL 3.0 en sí se abandonará desde la versión 31).
  • Safari: completo (solo en OS X 10.8 y posteriores e iOS 8, los cifrados CBC durante la transición a SSL 3.0 están denegados, pero esto significa que utilizará RC4, que tampoco se recomienda. El soporte de SSL 3.0 en sí se abandonó en OS X 10.11 y posteriores e iOS 9).
• Mitigación contra ataques RC4:
  • Google Chrome deshabilitó RC4 excepto como respaldo desde la versión 43. RC4 está deshabilitado desde Chrome 48.
  • Firefox deshabilitó RC4 excepto como respaldo desde la versión 36. Firefox 44 deshabilitó RC4 de manera predeterminada.
  • Opera deshabilitó RC4 excepto como respaldo desde la versión 30. RC4 está deshabilitado desde Opera 35.
  • Internet Explorer para Windows 7 /Server 2008 R2 y para Windows 8 /Server 2012 ha establecido la prioridad de RC4 en la más baja y también puede deshabilitar RC4 excepto como una alternativa a través de la configuración del registro. Internet Explorer 11 Mobile 11 para Windows Phone 8.1 deshabilita RC4 excepto como una alternativa si no funciona ningún otro algoritmo habilitado. Edge e IE 11 deshabilitan RC4 por completo en agosto de 2016.
• Mitigación contra el ataque FREAK:
  • El navegador de Android incluido con Android 4.0 y versiones anteriores todavía es vulnerable al ataque FREAK.
  • Internet Explorer 11 Mobile todavía es vulnerable al ataque FREAK.
  • Google Chrome, Internet Explorer (computadora de escritorio), Safari (computadora de escritorio y dispositivo móvil) y Opera (dispositivo móvil) tienen implementadas mitigaciones FREAK.
  • Mozilla Firefox en todas las plataformas y Google Chrome en Windows no se vieron afectados por FREAK.

La mayoría de las bibliotecas de programación SSL y TLS son software gratuito y de código abierto .

• BoringSSL , una bifurcación de OpenSSL para Chrome/Chromium y Android, así como otras aplicaciones de Google.
• Botan , una biblioteca criptográfica con licencia BSD escrita en C++.
• BSAFE Micro Edition Suite: una implementación multiplataforma de TLS escrita en C utilizando un módulo criptográfico validado por FIPS
• BSAFE SSL-J: una biblioteca TLS que proporciona una API propietaria y una API JSSE , utilizando un módulo criptográfico validado por FIPS
• cryptlib : una biblioteca de criptografía portátil de código abierto (incluye implementación TLS/SSL)
• Los programadores de Delphi pueden utilizar una biblioteca llamada Indy que utiliza OpenSSL o, alternativamente, ICS, que ahora admite TLS 1.3.
• GnuTLS : una implementación libre (licencia LGPL)
• Extensión de sockets seguros de Java (JSSE): la API de Java y la implementación del proveedor (denominada SunJSSE) ^[97]
• LibreSSL : una bifurcación de OpenSSL del proyecto OpenBSD.
• MatrixSSL : una implementación con doble licencia
• Mbed TLS (anteriormente PolarSSL): una pequeña implementación de biblioteca SSL para dispositivos integrados que está diseñada para facilitar su uso.
• Servicios de seguridad de red : biblioteca de código abierto validada según FIPS 140
• OpenSSL : una implementación libre (licencia BSD con algunas extensiones)
• Schannel : una implementación de SSL y TLS de Microsoft Windows como parte de su paquete.
• Transporte seguro : una implementación de SSL y TLS utilizada en OS X e iOS como parte de sus paquetes.
• wolfSSL (anteriormente CyaSSL): biblioteca SSL/TLS integrada con un fuerte enfoque en la velocidad y el tamaño.

Un artículo presentado en la conferencia ACM de 2012 sobre seguridad informática y de las comunicaciones ^[98] mostró que muchas aplicaciones utilizaban algunas de estas bibliotecas SSL de forma incorrecta, lo que generaba vulnerabilidades. Según los autores:

"La causa principal de la mayoría de estas vulnerabilidades es el pésimo diseño de las API de las bibliotecas SSL subyacentes. En lugar de expresar propiedades de seguridad de alto nivel de los túneles de red, como la confidencialidad y la autenticación, estas API exponen detalles de bajo nivel del protocolo SSL a los desarrolladores de aplicaciones. Como consecuencia, los desarrolladores a menudo utilizan las API de SSL de forma incorrecta, malinterpretando y entendiendo mal sus múltiples parámetros, opciones, efectos secundarios y valores de retorno".

El protocolo simple de transferencia de correo (SMTP) también se puede proteger con TLS. Estas aplicaciones utilizan certificados de clave pública para verificar la identidad de los puntos finales.

TLS también se puede utilizar para tunelizar una pila de red completa para crear una VPN , que es el caso de OpenVPN y OpenConnect . Muchos proveedores ya han combinado las capacidades de cifrado y autenticación de TLS con la autorización. También ha habido un desarrollo sustancial desde fines de la década de 1990 en la creación de tecnología de cliente fuera de los navegadores web, con el fin de permitir la compatibilidad con aplicaciones cliente/servidor. En comparación con las tecnologías VPN IPsec tradicionales , TLS tiene algunas ventajas inherentes en el firewall y la travesía NAT que facilitan la administración para grandes poblaciones de acceso remoto.

TLS también es un método estándar para proteger la señalización de aplicaciones del Protocolo de inicio de sesión (SIP). TLS se puede utilizar para proporcionar autenticación y cifrado de la señalización SIP asociada con VoIP y otras aplicaciones basadas en SIP. ^[99]

A continuación se enumeran los ataques significativos contra TLS/SSL.

En febrero de 2015, la IETF emitió un RFC informativo ^[100] que resume los diversos ataques conocidos contra TLS/SSL.

En agosto de 2009 se descubrió una vulnerabilidad del procedimiento de renegociación que puede conducir a ataques de inyección de texto simple contra SSL 3.0 y todas las versiones actuales de TLS. ^[101] Por ejemplo, permite a un atacante que puede secuestrar una conexión https insertar sus propias solicitudes al comienzo de la conversación que el cliente tiene con el servidor web. El atacante no puede descifrar la comunicación cliente-servidor, por lo que es diferente de un ataque típico de intermediario. Una solución a corto plazo es que los servidores web dejen de permitir la renegociación, lo que normalmente no requerirá otros cambios a menos que se utilice la autenticación de certificado de cliente . Para solucionar la vulnerabilidad, se propuso una extensión de indicación de renegociación para TLS. Requerirá que el cliente y el servidor incluyan y verifiquen información sobre los protocolos de enlace anteriores en cualquier protocolo de enlace de renegociación. ^[102] Esta extensión se ha convertido en un estándar propuesto y se le ha asignado el número RFC  5746. El RFC ha sido implementado por varias bibliotecas. ^{[103] [104] [105]}

Un ataque de degradación de protocolo (también llamado ataque de reversión de versión) engaña a un servidor web para que negocie conexiones con versiones anteriores de TLS (como SSLv2) que hace tiempo que se abandonaron por ser inseguras.

Las modificaciones previas a los protocolos originales, como False Start ^[106] (adoptado y habilitado por Google Chrome ^[107] ) o Snap Start , introdujeron ataques limitados de degradación del protocolo TLS ^[108] o permitieron modificaciones a la lista de conjuntos de cifrados enviada por el cliente al servidor. Al hacerlo, un atacante podría tener éxito en influir en la selección del conjunto de cifrados en un intento de degradar el conjunto de cifrados negociado para usar un algoritmo de cifrado simétrico más débil o un intercambio de claves más débil. ^[109] Un artículo presentado en una conferencia de ACM sobre seguridad informática y de comunicaciones en 2012 demostró que la extensión False Start estaba en riesgo: en ciertas circunstancias podría permitir a un atacante recuperar las claves de cifrado fuera de línea y acceder a los datos cifrados. ^[110]

Los ataques de degradación del cifrado pueden obligar a los servidores y clientes a negociar una conexión utilizando claves criptográficamente débiles. En 2014, se descubrió un ataque de intermediario llamado FREAK que afectaba a la pila OpenSSL , el navegador web predeterminado de Android y algunos navegadores Safari . ^[111] El ataque consistía en engañar a los servidores para que negociaran una conexión TLS utilizando claves de cifrado de 512 bits criptográficamente débiles.

Logjam es un exploit de seguridad descubierto en mayo de 2015 que aprovecha la opción de usar grupos Diffie-Hellman de 512 bits "de grado de exportación" heredados de la década de 1990. ^[112] Obliga a los servidores susceptibles a degradarse a grupos Diffie-Hellman de 512 bits criptográficamente débiles. Un atacante puede entonces deducir las claves que el cliente y el servidor determinan utilizando el intercambio de claves Diffie-Hellman .

El ataque DROWN es un exploit que ataca a servidores que admiten conjuntos de protocolos SSL/TLS contemporáneos, explotando su compatibilidad con el protocolo SSLv2, obsoleto e inseguro, para aprovechar un ataque a conexiones que utilizan protocolos actualizados que, de otro modo, serían seguros. ^{[113] [114]} DROWN explota una vulnerabilidad en los protocolos utilizados y la configuración del servidor, en lugar de cualquier error de implementación específico. Los detalles completos de DROWN se anunciaron en marzo de 2016, junto con un parche para el exploit. En ese momento, más de 81 000 de los 1 millón de sitios web más populares se encontraban entre los sitios web protegidos con TLS que eran vulnerables al ataque DROWN. ^[114]

El 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una prueba de concepto llamada BEAST ( Browser Exploit Against SSL/TLS ) ^[115] usando un applet de Java para violar las restricciones de la política del mismo origen , para una vulnerabilidad de encadenamiento de bloques de cifrado (CBC) conocida desde hace mucho tiempo en TLS 1.0: ^{[116] [117]} un atacante que observa 2 bloques de texto cifrado consecutivos C0, C1 puede probar si el bloque de texto simple P1 es igual a x eligiendo el siguiente bloque de texto simple P2 = x ⊕ C0 ⊕ C1 ; según la operación CBC, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , que será igual a C1 si x = P1 . No se habían demostrado anteriormente explotaciones prácticas para esta vulnerabilidad , que fue descubierta originalmente por Phillip Rogaway ^[118] en 2002. La vulnerabilidad del ataque se había solucionado con TLS 1.1 en 2006, pero TLS 1.1 no había sido ampliamente adoptado antes de esta demostración de ataque.

RC4 como cifrador de flujo es inmune a los ataques BEAST. Por lo tanto, RC4 se utilizó ampliamente como una forma de mitigar los ataques BEAST en el lado del servidor. Sin embargo, en 2013, los investigadores encontraron más debilidades en RC4. A partir de entonces, ya no se recomendó habilitar RC4 en el lado del servidor. ^[119]

Chrome y Firefox no son vulnerables a los ataques BEAST, ^{[120] [121]} sin embargo, Mozilla actualizó sus bibliotecas NSS para mitigar ataques similares a BEAST. Mozilla Firefox y Google Chrome utilizan NSS para implementar SSL. Algunos servidores web que tienen una implementación defectuosa de la especificación SSL pueden dejar de funcionar como resultado. ^[122]

El 10 de enero de 2012, Microsoft publicó el boletín de seguridad MS12-006, que solucionó la vulnerabilidad BEAST al cambiar la forma en que el componente Windows Secure Channel ( Schannel ) transmite paquetes de red cifrados desde el extremo del servidor. ^[123] Los usuarios de Internet Explorer (anterior a la versión 11) que se ejecutan en versiones anteriores de Windows ( Windows 7 , Windows 8 y Windows Server 2008 R2 ) pueden restringir el uso de TLS a 1.1 o superior.

Apple corrigió la vulnerabilidad de BEAST implementando la división 1/n-1 y activándola de forma predeterminada en OS X Mavericks , lanzado el 22 de octubre de 2013. ^[124]

Los autores del ataque BEAST también son los creadores del posterior ataque CRIME , que puede permitir a un atacante recuperar el contenido de las cookies web cuando se utiliza la compresión de datos junto con TLS. ^{[125] [126]} Cuando se utiliza para recuperar el contenido de las cookies de autenticación secretas , permite a un atacante realizar un secuestro de sesión en una sesión web autenticada.

Aunque el ataque CRIME se presentó como un ataque general que podría funcionar de manera efectiva contra una gran cantidad de protocolos, incluidos, entre otros, TLS y protocolos de capa de aplicación como SPDY o HTTP , solo se demostraron y mitigaron en gran medida los exploits contra TLS y SPDY en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, a pesar de que los autores de CRIME han advertido que esta vulnerabilidad podría estar incluso más extendida que la compresión SPDY y TLS combinadas. En 2013, se anunció una nueva instancia del ataque CRIME contra la compresión HTTP, denominada BREACH . Basado en el ataque CRIME, un ataque BREACH puede extraer tokens de inicio de sesión, direcciones de correo electrónico u otra información confidencial del tráfico web cifrado con TLS en tan solo 30 segundos (dependiendo de la cantidad de bytes que se extraigan), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso o pueda inyectar contenido en páginas válidas que el usuario esté visitando (por ejemplo, una red inalámbrica bajo el control del atacante). ^[127] Todas las versiones de TLS y SSL están en riesgo de BREACH independientemente del algoritmo de cifrado o la clave utilizada. ^[128] A diferencia de casos anteriores de CRIME, contra los que se puede defender con éxito desactivando la compresión TLS o la compresión del encabezado SPDY, BREACH explota la compresión HTTP, que no se puede desactivar de manera realista, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para los usuarios. ^[127] Esta es una limitación conocida de TLS, ya que es susceptible a ataques de texto simple elegido contra los datos de la capa de aplicación que se supone que debe proteger.

Las versiones anteriores de TLS eran vulnerables al ataque de relleno de Oracle descubierto en 2002. Una nueva variante, llamada ataque Lucky Thirteen , se publicó en 2013.

Algunos expertos ^[88] también recomendaron evitar el triple DES CBC. Dado que los últimos cifrados compatibles desarrollados para admitir cualquier programa que utilice la biblioteca SSL/TLS de Windows XP como Internet Explorer en Windows XP son RC4 y Triple-DES, y dado que RC4 ahora está obsoleto (consulte la discusión sobre los ataques RC4 ), esto dificulta la compatibilidad con cualquier versión de SSL para cualquier programa que utilice esta biblioteca en XP.

Se publicó una solución como la extensión Encrypt-then-MAC para la especificación TLS, publicada como RFC  7366. ^[129] El ataque Lucky Thirteen se puede mitigar en TLS 1.2 utilizando solo cifrados AES_GCM; AES_CBC sigue siendo vulnerable. SSL puede proteger el correo electrónico, VoIP y otros tipos de comunicaciones a través de redes inseguras, además de su caso de uso principal de transmisión segura de datos entre un cliente y el servidor ^[2]

El 14 de octubre de 2014, los investigadores de Google publicaron una vulnerabilidad en el diseño de SSL 3.0 que hace que el modo de funcionamiento CBC con SSL 3.0 sea vulnerable a un ataque de relleno ( CVE - 2014-3566). A este ataque lo llamaron POODLE ( Padding Oracle On Downgraded Legacy Encryption ). En promedio, los atacantes solo necesitan realizar 256 solicitudes SSL 3.0 para revelar un byte de mensajes cifrados. ^[94]

Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayoría de los clientes y servidores admiten TLS 1.0 y versiones posteriores, todos los navegadores principales cambian voluntariamente a SSL 3.0 si fallan los protocolos de enlace con versiones más nuevas de TLS, a menos que proporcionen la opción para que un usuario o administrador deshabilite SSL 3.0 y el usuario o administrador lo haga ^{[ cita requerida ]} . Por lo tanto, el intermediario puede realizar primero un ataque de reversión de versión y luego explotar esta vulnerabilidad. ^[94]

El 8 de diciembre de 2014, se anunció una variante de POODLE que afecta las implementaciones de TLS que no aplican correctamente los requisitos de bytes de relleno. ^[130]

A pesar de la existencia de ataques a RC4 que rompieron su seguridad, las suites de cifrado en SSL y TLS que se basaban en RC4 todavía se consideraban seguras antes de 2013 en función de la forma en que se usaban en SSL y TLS. En 2011, la suite RC4 fue recomendada como una solución alternativa para el ataque BEAST . ^[131] Nuevas formas de ataque reveladas en marzo de 2013 demostraron de manera concluyente la viabilidad de romper RC4 en TLS, lo que sugiere que no era una buena solución alternativa para BEAST. ^[93] AlFardan, Bernstein, Paterson, Poettering y Schuldt propusieron un escenario de ataque que utilizó sesgos estadísticos recientemente descubiertos en la tabla de claves RC4 ^[132] para recuperar partes del texto simple con una gran cantidad de cifrados TLS. ^{[133] [134]} Un ataque a RC4 en TLS y SSL que requiere cifrados 13 × 2 ²⁰ para romper RC4 fue presentado el 8 de julio de 2013 y luego descrito como "factible" en la presentación adjunta en un Simposio de Seguridad USENIX en agosto de 2013. ^{[135] [136]} En julio de 2015, mejoras posteriores en el ataque hacen que sea cada vez más práctico vencer la seguridad de TLS cifrado con RC4. ^[137]

Como muchos navegadores modernos han sido diseñados para derrotar los ataques BEAST (excepto Safari para Mac OS X 10.7 o anterior, para iOS 6 o anterior y para Windows; consulte el § Navegadores web), RC4 ya no es una buena opción para TLS 1.0. Los cifrados CBC que se vieron afectados por el ataque BEAST en el pasado se han convertido en una opción más popular para la protección. ^[88] Mozilla y Microsoft recomiendan deshabilitar RC4 siempre que sea posible. ^{[138] [139]} RFC  7465 prohíbe el uso de conjuntos de cifrados RC4 en todas las versiones de TLS.

El 1 de septiembre de 2015, Microsoft, Google y Mozilla anunciaron que los conjuntos de cifrado RC4 se deshabilitarían de forma predeterminada en sus navegadores ( Microsoft Edge , Internet Explorer 11 en Windows 7/8.1/10, Firefox y Chrome ) a principios de 2016. ^{[140] [141] [142]}

Un ataque de truncamiento de TLS (cierre de sesión) bloquea las solicitudes de cierre de sesión de la cuenta de una víctima, de modo que el usuario permanece conectado a un servicio web sin saberlo. Cuando se envía la solicitud de cierre de sesión, el atacante inyecta un mensaje TCP FIN sin cifrar (no más datos del remitente) para cerrar la conexión. Por lo tanto, el servidor no recibe la solicitud de cierre de sesión y no se da cuenta de la finalización anormal. ^[143]

Publicado en julio de 2013, ^{[144] [145]} el ataque hace que los servicios web como Gmail y Hotmail muestren una página que informa al usuario que ha cerrado sesión correctamente, al mismo tiempo que garantiza que el navegador del usuario mantenga la autorización con el servicio, lo que permite que un atacante con acceso posterior al navegador acceda y tome el control de la cuenta iniciada del usuario. El ataque no se basa en la instalación de malware en la computadora de la víctima; los atacantes solo necesitan colocarse entre la víctima y el servidor web (por ejemplo, configurando un punto de acceso inalámbrico no autorizado). ^[143] Esta vulnerabilidad también requiere acceso a la computadora de la víctima. Otra posibilidad es que cuando se utiliza FTP, la conexión de datos puede tener un FIN falso en el flujo de datos, y si las reglas del protocolo para intercambiar alertas close_notify no se cumplen, un archivo puede truncarse.

En febrero de 2013, dos investigadores de Royal Holloway, Universidad de Londres, descubrieron un ataque de temporización ^[146] que les permitió recuperar (partes del) texto simple de una conexión DTLS utilizando la implementación OpenSSL o GnuTLS de DTLS cuando se utilizaba el modo de cifrado en cadena de bloques de cifrado .

Este ataque, descubierto a mediados de 2016, explota las debilidades del protocolo de detección automática de proxy web (WPAD) para exponer la URL a la que un usuario web intenta acceder a través de un enlace web habilitado con TLS. ^[147] La ​​divulgación de una URL puede violar la privacidad de un usuario, no solo por el sitio web al que se accede, sino también porque las URL a veces se utilizan para autenticar a los usuarios. Los servicios de intercambio de documentos, como los que ofrecen Google y Dropbox, también funcionan enviando al usuario un token de seguridad que está incluido en la URL. Un atacante que obtenga dichas URL puede obtener acceso completo a la cuenta o los datos de una víctima.

El exploit funciona contra casi todos los navegadores y sistemas operativos.

El ataque Sweet32 rompe todos los cifrados de bloques de 64 bits utilizados en modo CBC, tal como se utiliza en TLS, explotando un ataque de cumpleaños y un ataque de intermediario o la inyección de un código JavaScript malicioso en una página web. El objetivo del ataque de intermediario o la inyección de código JavaScript es permitir que el atacante capture suficiente tráfico para montar un ataque de cumpleaños. ^[148]

El fallo Heartbleed es una vulnerabilidad grave específica de la implementación de SSL/TLS en la popular biblioteca de software criptográfico OpenSSL , que afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad, informada en abril de 2014, permite a los atacantes robar claves privadas de servidores que normalmente deberían estar protegidos. ^[149] El fallo Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves privadas secretas asociadas con los certificados públicos utilizados para identificar a los proveedores de servicios y para cifrar el tráfico, los nombres y contraseñas de los usuarios y el contenido real. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y usuarios y suplantar servicios y usuarios. ^[150] La vulnerabilidad es causada por un error de sobrelectura de búfer en el software OpenSSL, en lugar de un defecto en la especificación del protocolo SSL o TLS.

En septiembre de 2014, Intel Security Advanced Threat Research anunció una variante de la vulnerabilidad de falsificación de firma RSA PKCS#1 v1.5 de Daniel Bleichenbacher ^[151] . Este ataque, denominado BERserk, es el resultado de una decodificación incompleta de la longitud ASN.1 de firmas de clave pública en algunas implementaciones de SSL y permite un ataque de intermediario falsificando una firma de clave pública. ^[152]

En febrero de 2015, después de que los medios de comunicación informaran sobre la preinstalación oculta del adware Superfish en algunas computadoras portátiles Lenovo, ^[153] un investigador descubrió que un certificado raíz confiable en las máquinas Lenovo afectadas no era seguro, ya que se podía acceder fácilmente a las claves utilizando el nombre de la empresa, Komodia, como frase de contraseña. ^[154] La biblioteca Komodia fue diseñada para interceptar el tráfico TLS/SSL del lado del cliente para el control y la vigilancia parental, pero también se utilizó en numerosos programas de adware, incluido Superfish, que a menudo se instalaban subrepticiamente sin el conocimiento del usuario de la computadora. A su vez, estos programas potencialmente no deseados instalaban el certificado raíz corrupto, lo que permitía a los atacantes controlar por completo el tráfico web y confirmar los sitios web falsos como auténticos.

En mayo de 2016, se informó que docenas de sitios web daneses protegidos con HTTPS pertenecientes a Visa Inc. eran vulnerables a ataques que permitían a los piratas informáticos inyectar código malicioso y contenido falsificado en los navegadores de los visitantes. ^[155] Los ataques funcionaron porque la implementación de TLS utilizada en los servidores afectados reutilizó incorrectamente números aleatorios ( nonces ) que están destinados a usarse solo una vez, lo que garantiza que cada protocolo de enlace TLS sea único. ^[155]

En febrero de 2017, un error de implementación causado por un solo carácter mal escrito en el código utilizado para analizar HTML generó un error de desbordamiento de búfer en los servidores de Cloudflare . Este error, conocido como Cloudbleed , es similar en sus efectos al error Heartbleed descubierto en 2014 y permitió que terceros no autorizados leyeran datos en la memoria de los programas que se ejecutaban en los servidores, datos que de otro modo deberían haber estado protegidos por TLS. ^[156]

En julio de 2021 ^[actualizar], el Movimiento por una Internet Confiable estimó la proporción de sitios web que son vulnerables a ataques TLS. ^[92]

El secreto hacia adelante es una propiedad de los sistemas criptográficos que garantiza que una clave de sesión derivada de un conjunto de claves públicas y privadas no se verá comprometida si una de las claves privadas se ve comprometida en el futuro. ^[157] Sin secreto hacia adelante, si la clave privada del servidor se ve comprometida, no solo se verán comprometidas todas las futuras sesiones cifradas con TLS que utilicen ese certificado de servidor, sino también cualquier sesión anterior que lo haya utilizado (siempre que estas sesiones anteriores se hayan interceptado y almacenado en el momento de la transmisión). ^[158] Una implementación de TLS puede proporcionar secreto hacia adelante al requerir el uso de un intercambio de claves Diffie-Hellman efímero para establecer claves de sesión, y algunas implementaciones notables de TLS lo hacen exclusivamente: por ejemplo, Gmail y otros servicios HTTPS de Google que utilizan OpenSSL . ^[159] Sin embargo, muchos clientes y servidores que admiten TLS (incluidos navegadores y servidores web) no están configurados para implementar dichas restricciones. ^{[160] [161]} En la práctica, a menos que un servicio web utilice el intercambio de claves Diffie-Hellman para implementar el secreto hacia adelante, todo el tráfico web cifrado hacia y desde ese servicio puede ser descifrado por un tercero si obtiene la clave maestra (privada) del servidor; por ejemplo, mediante una orden judicial. ^[162]

Incluso cuando se implementa el intercambio de claves Diffie-Hellman, los mecanismos de gestión de sesiones del lado del servidor pueden afectar la confidencialidad hacia adelante. El uso de tickets de sesión TLS (una extensión TLS) hace que la sesión esté protegida por AES128-CBC-SHA256 independientemente de cualquier otro parámetro TLS negociado, incluidos los conjuntos de cifrados de confidencialidad hacia adelante, y las claves de tickets de sesión TLS de larga duración frustran el intento de implementar la confidencialidad hacia adelante. ^{[163] [164] [165]} Una investigación de la Universidad de Stanford en 2014 también encontró que de los 473.802 servidores TLS encuestados, el 82,9% de los servidores que implementaban el intercambio de claves efímeras Diffie-Hellman (DHE) para respaldar la confidencialidad hacia adelante usaban parámetros Diffie-Hellman débiles. Estas elecciones de parámetros débiles podrían comprometer potencialmente la efectividad de la confidencialidad hacia adelante que los servidores buscaban proporcionar. ^[166]

Desde finales de 2011, Google ha proporcionado confidencialidad hacia adelante con TLS de forma predeterminada a los usuarios de su servicio Gmail , junto con Google Docs y la búsqueda cifrada, entre otros servicios. ^[167] Desde noviembre de 2013, Twitter ha proporcionado confidencialidad hacia adelante con TLS a los usuarios de su servicio. ^[168] A partir de agosto de 2019 ^[actualizar], aproximadamente el 80% de los sitios web habilitados para TLS están configurados para usar conjuntos de cifrado que brindan confidencialidad hacia adelante a la mayoría de los navegadores web. ^[92]

La interceptación TLS (o interceptación HTTPS si se aplica particularmente a ese protocolo) es la práctica de interceptar un flujo de datos cifrados para descifrarlos, leerlos y posiblemente manipularlos, y luego volver a cifrarlos y enviarlos nuevamente. Esto se hace por medio de un " proxy transparente ": el software de interceptación finaliza la conexión TLS entrante, inspecciona el texto simple HTTP y luego crea una nueva conexión TLS al destino. ^[169]

Los operadores de red utilizan la interceptación TLS/HTTPS como medida de seguridad de la información para poder escanear y protegerse contra la intrusión de contenido malicioso en la red, como virus informáticos y otro malware . ^[169] De lo contrario, dicho contenido no podría detectarse siempre que esté protegido por cifrado, lo que es cada vez más frecuente como resultado del uso rutinario de HTTPS y otros protocolos seguros.

Una desventaja importante de la interceptación TLS/HTTPS es que introduce nuevos riesgos de seguridad propios. Una limitación notable es que proporciona un punto en el que el tráfico de red está disponible sin cifrar, lo que da a los atacantes un incentivo para atacar este punto en particular con el fin de obtener acceso a contenido que de otro modo sería seguro. La interceptación también permite al operador de red, o a las personas que obtienen acceso a su sistema de interceptación, realizar ataques de intermediario contra los usuarios de la red. Un estudio de 2017 concluyó que "la interceptación HTTPS se ha generalizado de forma sorprendente y que los productos de interceptación como clase tienen un impacto drásticamente negativo en la seguridad de la conexión". ^[169]

El protocolo TLS intercambia registros que encapsulan los datos que se van a intercambiar en un formato específico (ver más abajo). Cada registro puede comprimirse, rellenarse, añadirse un código de autenticación de mensajes (MAC) o cifrarse, todo ello en función del estado de la conexión. Cada registro tiene un campo de tipo de contenido que designa el tipo de datos encapsulados, un campo de longitud y un campo de versión TLS. Los datos encapsulados pueden ser mensajes de control o de procedimiento del propio TLS, o simplemente los datos de aplicación que se necesitan transferir mediante TLS. Las especificaciones (conjunto de cifrados, claves, etc.) necesarias para intercambiar datos de aplicación mediante TLS se acuerdan en el "apretón de manos TLS" entre el cliente que solicita los datos y el servidor que responde a las solicitudes. Por tanto, el protocolo define tanto la estructura de las cargas útiles transferidas en TLS como el procedimiento para establecer y supervisar la transferencia.

Cuando se inicia la conexión, el registro encapsula un protocolo de "control": el protocolo de mensajería de enlace ( tipo de contenido 22). Este protocolo se utiliza para intercambiar toda la información requerida por ambas partes para el intercambio de los datos de la aplicación real mediante TLS. Define el formato de los mensajes y el orden de su intercambio. Estos pueden variar según las demandas del cliente y del servidor, es decir, existen varios procedimientos posibles para establecer la conexión. Este intercambio inicial da como resultado una conexión TLS exitosa (ambas partes listas para transferir datos de la aplicación con TLS) o un mensaje de alerta (como se especifica a continuación).

A continuación se muestra un ejemplo de conexión típico, que ilustra un protocolo de enlace en el que el servidor (pero no el cliente) está autenticado por su certificado:

1. Fase de negociación:
   • Un cliente envía un mensaje ClientHello que especifica la versión más alta del protocolo TLS que admite, un número aleatorio, una lista de conjuntos de cifrados sugeridos y métodos de compresión sugeridos. Si el cliente intenta realizar un protocolo de enlace reanudado, puede enviar un ID de sesión . Si el cliente puede utilizar la negociación de protocolo de capa de aplicación , puede incluir una lista de protocolos de aplicación compatibles , como HTTP/2 .
   • El servidor responde con un mensaje ServerHello , que contiene la versión de protocolo elegida, un número aleatorio, un conjunto de cifrados y un método de compresión de entre las opciones ofrecidas por el cliente. Para confirmar o permitir la reanudación de los protocolos de enlace, el servidor puede enviar un ID de sesión . La versión de protocolo elegida debe ser la más alta que admitan tanto el cliente como el servidor. Por ejemplo, si el cliente admite la versión 1.1 de TLS y el servidor admite la versión 1.2, se debe seleccionar la versión 1.1; no se debe seleccionar la versión 1.2.
   • El servidor envía su mensaje de Certificado (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitir este paso). ^[170]
   • El servidor envía su mensaje ServerKeyExchange (dependiendo del conjunto de cifrados seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrados DHE , ECDHE y DH_anon. ^[23]
   • El servidor envía un mensaje ServerHelloDone , indicando que ha finalizado la negociación del protocolo de enlace.
   • El cliente responde con un mensaje ClientKeyExchange , que puede contener un PreMasterSecret , una clave pública o nada (de nuevo, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
   • El cliente y el servidor utilizan entonces los números aleatorios y PreMasterSecret para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave ( claves de sesión como IV , clave de cifrado simétrico , clave MAC ^[171] ) para esta conexión se derivan de este secreto maestro (y los valores aleatorios generados por el cliente y el servidor), que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada .
2. El cliente ahora envía un registro ChangeCipherSpec , que básicamente le dice al servidor: "Todo lo que le diga de ahora en adelante será autenticado (y encriptado si los parámetros de encriptación estaban presentes en el certificado del servidor)". El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro con un tipo de contenido de 20.
   • El cliente envía un mensaje Finalizado autenticado y encriptado , que contiene un hash y una MAC de los mensajes de protocolo de enlace anteriores.
   • El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la dirección MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y la conexión debe finalizarse.
3. Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente: "Todo lo que te diga de ahora en adelante será autenticado (y encriptado, si se negoció el cifrado)".
   • El servidor envía su mensaje Finalizado autenticado y cifrado.
   • El cliente realiza el mismo procedimiento de descifrado y verificación que el servidor en el paso anterior.
4. 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á.

El siguiente ejemplo completo muestra un cliente que se autentica (además del servidor como en el ejemplo anterior; consulte autenticación mutua ) a través de TLS utilizando certificados intercambiados entre ambos pares.

1. Fase de negociación:
   • Un cliente envía un mensaje ClientHello especificando la versión más alta del protocolo TLS que admite, un número aleatorio, una lista de conjuntos de cifrado sugeridos y métodos de compresión.
   • El servidor responde con un mensaje ServerHello , que contiene la versión del protocolo elegida, un número aleatorio, un conjunto de cifrados y un método de compresión entre las opciones ofrecidas por el cliente. El servidor también puede enviar un identificador de sesión como parte del mensaje para realizar un enlace reanudado.
   • El servidor envía su mensaje de Certificado (dependiendo del conjunto de cifrado seleccionado, el servidor puede omitir este paso). ^[170]
   • El servidor envía su mensaje ServerKeyExchange (según el conjunto de cifrados seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrados DHE, ECDHE y DH_anon. ^[1]
   • El servidor envía un mensaje CertificateRequest para solicitar un certificado al cliente.
   • El servidor envía un mensaje ServerHelloDone , indicando que ha finalizado la negociación del protocolo de enlace.
   • El cliente responde con un mensaje de Certificado , que contiene el certificado del cliente, pero no su clave privada.
   • El cliente envía un mensaje ClientKeyExchange , que puede contener un PreMasterSecret , una clave pública o nada (de nuevo, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
   • El cliente envía un mensaje CertificateVerify , que es una firma sobre los mensajes de protocolo de enlace anteriores utilizando la clave privada del certificado del cliente. Esta firma se puede verificar utilizando la clave pública del certificado del cliente. Esto permite que el servidor sepa que el cliente tiene acceso a la clave privada del certificado y, por lo tanto, es el propietario del certificado.
   • El cliente y el servidor utilizan entonces los números aleatorios y PreMasterSecret para calcular un secreto común, denominado "secreto maestro". Todos los demás datos clave ("claves de sesión") para esta conexión se derivan de este secreto maestro (y de los valores aleatorios generados por el cliente y el servidor), que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada.
2. El cliente ahora envía un registro ChangeCipherSpec , que básicamente le dice al servidor: "Todo lo que le diga de ahora en adelante será autenticado (y encriptado si se negoció el cifrado). "El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro y tiene el tipo 20 y no 22.
   • Finalmente, el cliente envía un mensaje Finalizado cifrado , que contiene un hash y una MAC de los mensajes de protocolo de enlace anteriores.
   • El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y la dirección MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y se debe interrumpir la conexión.
3. Finalmente, el servidor envía un ChangeCipherSpec , diciéndole al cliente: "Todo lo que te diga de ahora en adelante será autenticado (y encriptado si se negoció el cifrado)".
   • El servidor envía su propio mensaje de Finalizado cifrado.
   • El cliente realiza el mismo procedimiento de descifrado y verificación que el servidor en el paso anterior.
4. 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 .

Las operaciones de clave pública (por ejemplo, RSA) son relativamente costosas en términos de potencia computacional. TLS proporciona un atajo seguro en el mecanismo de enlace para evitar estas operaciones: sesiones reanudadas. Las sesiones reanudadas se implementan utilizando identificadores de sesión o tickets de sesión.

Además de las ventajas en términos de rendimiento, las sesiones reanudadas también se pueden utilizar para el inicio de sesión único , ya que garantiza que tanto la sesión original como cualquier sesión reanudada se originen en el mismo cliente. Esto es de particular importancia para el protocolo FTP sobre TLS/SSL , que de otro modo sufriría un ataque de intermediario en el que un atacante podría interceptar el contenido de las conexiones de datos secundarias. ^[172]

El protocolo de enlace TLS 1.3 se condensó a un solo viaje de ida y vuelta en comparación con los dos viajes de ida y vuelta requeridos en versiones anteriores de TLS/SSL.

Para iniciar el protocolo de enlace, el cliente adivina qué algoritmo de intercambio de claves seleccionará el servidor y envía un mensaje ClientHello al servidor que contiene una lista de cifrados admitidos (en orden de preferencia del cliente) y claves públicas para algunas o todas sus suposiciones de intercambio de claves. Si el cliente adivina correctamente el algoritmo de intercambio de claves, se elimina 1 viaje de ida y vuelta del protocolo de enlace. Después de recibir el ClientHello , el servidor selecciona un cifrado y envía de vuelta un ServerHello con su propia clave pública, seguido de los mensajes de certificado y finalización del servidor . ^[173]

Una vez que el cliente recibe el mensaje terminado del servidor, ahora se coordina con el servidor qué conjunto de cifrado utilizar. ^[174]

En un protocolo de enlace completo normal , el servidor envía un identificador de sesión como parte del mensaje ServerHello . El cliente asocia este identificador de sesión con la dirección IP y el puerto TCP del servidor, de modo que cuando el cliente se vuelva a conectar a ese servidor, pueda utilizar el identificador de sesión para acortar el protocolo de enlace. En el servidor, el identificador de sesión se asigna a los parámetros criptográficos negociados previamente, específicamente el "secreto maestro". Ambos lados deben tener el mismo "secreto maestro" o el protocolo de enlace reanudado fallará (esto evita que un espía utilice un identificador de sesión ). Los datos aleatorios en los mensajes ClientHello y ServerHello prácticamente garantizan que las claves de conexión generadas serán diferentes a las de la conexión anterior. En las RFC, este tipo de protocolo de enlace se denomina protocolo de enlace abreviado . También se describe en la literatura como protocolo de enlace de reinicio .

1. Fase de negociación:
   • Un cliente envía un mensaje ClientHello en el que especifica la versión más alta del protocolo TLS que admite, un número aleatorio, una lista de conjuntos de cifrados sugeridos y métodos de compresión. El mensaje incluye el ID de sesión de la conexión TLS anterior.
   • El servidor responde con un mensaje ServerHello , que contiene la versión del protocolo elegida, un número aleatorio, un conjunto de cifrados y un método de compresión de las opciones ofrecidas por el cliente. Si el servidor reconoce el id de sesión enviado por el cliente, responde con el mismo id de sesión . El cliente utiliza esto para reconocer que se está realizando un protocolo de enlace reanudado. Si el servidor no reconoce el id de sesión enviado por el cliente, envía un valor diferente para su id de sesión . Esto le indica al cliente que no se realizará un protocolo de enlace reanudado. En este punto, tanto el cliente como el servidor tienen el "secreto maestro" y los datos aleatorios para generar los datos clave que se utilizarán para esta conexión.
2. El servidor envía ahora un registro ChangeCipherSpec , que básicamente le dice al cliente: "Todo lo que le diga a partir de ahora será cifrado". El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro y tiene el tipo 20 y no 22.
   • Finalmente, el servidor envía un mensaje Finalizado cifrado , que contiene un hash y una MAC de los mensajes de protocolo de enlace anteriores.
   • El cliente intentará descifrar el mensaje Finalizado del servidor y verificar el hash y la dirección MAC. Si el descifrado o la verificación fallan, se considera que el protocolo de enlace ha fallado y se debe interrumpir la conexión.
3. Finalmente, el cliente envía un ChangeCipherSpec , diciéndole al servidor: "Todo lo que te diga a partir de ahora será cifrado".
   • El cliente envía su propio mensaje de Finalizado cifrado .
   • El servidor realiza el mismo procedimiento de descifrado y verificación que el cliente en el paso anterior.
4. 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 .

RFC  5077 amplía TLS mediante el uso de tickets de sesión, en lugar de identificadores de sesión. Define una forma de reanudar una sesión TLS sin necesidad de que el estado específico de la sesión se almacene en el servidor TLS.

Al utilizar tickets de sesión, el servidor TLS almacena su estado específico de sesión en un ticket de sesión y envía el ticket de sesión al cliente TLS para su almacenamiento. El cliente reanuda una sesión TLS enviando el ticket de sesión al servidor, y el servidor reanuda la sesión TLS de acuerdo con el estado específico de la sesión en el ticket. El servidor cifra y autentica el ticket de sesión, y el servidor verifica su validez antes de utilizar su contenido.

Una debilidad particular de este método con OpenSSL es que siempre limita la seguridad de cifrado y autenticación del ticket de sesión TLS transmitido a AES128-CBC-SHA256, sin importar qué otros parámetros TLS se negociaron para la sesión TLS real. ^[164] Esto significa que la información de estado (el ticket de sesión TLS) no está tan bien protegida como la sesión TLS en sí. De particular preocupación es el almacenamiento de OpenSSL de las claves en un contexto de toda la aplicación ( SSL_CTX), es decir, durante la vida de la aplicación, y no permite volver a introducir las claves de los AES128-CBC-SHA256tickets de sesión TLS sin restablecer el contexto OpenSSL de toda la aplicación (lo que es poco común, propenso a errores y a menudo requiere intervención administrativa manual). ^{[165] [163]}

Este es el formato general de todos los registros TLS.

Tipo de contenido

Este campo identifica el tipo de protocolo de capa de registro contenido en este registro.

Versión heredada

Este campo identifica la versión principal y secundaria de TLS anterior a TLS 1.3 para el mensaje incluido. Para un mensaje ClientHello, no es necesario que sea la versión más alta compatible con el cliente. Para TLS 1.3 y versiones posteriores, debe configurarse en 0x0303 y la aplicación debe enviar las versiones compatibles en un bloque de extensión de mensaje adicional.

Longitud

La longitud de los campos "mensaje(s) de protocolo", "MAC" y "relleno" combinados (es decir, q −5), no debe superar los 214 ^bytes (16 KiB).

Mensaje(s) de protocolo

Uno o más mensajes identificados por el campo Protocolo. Tenga en cuenta que este campo puede estar cifrado según el estado de la conexión.

MAC y relleno

Un código de autenticación de mensajes calculado sobre el campo "mensaje(s) de protocolo", con material de clave adicional incluido. Tenga en cuenta que este campo puede estar cifrado o no estar incluido en su totalidad, según el estado de la conexión.

No puede haber campos "MAC" o "padding" al final de los registros TLS antes de que todos los algoritmos y parámetros de cifrado se hayan negociado y aceptado y luego confirmado mediante el envío de un registro CipherStateChange (ver a continuación) para indicar que estos parámetros tendrán efecto en todos los registros posteriores enviados por el mismo par.

La mayoría de los mensajes intercambiados durante la configuración de la sesión TLS se basan en este registro, a menos que se produzca un error o una advertencia que deba ser señalado por un registro del protocolo de alerta (ver a continuación), o el modo de cifrado de la sesión sea modificado por otro registro (ver el protocolo ChangeCipherSpec a continuación).

Tipo de mensaje

Este campo identifica el tipo de mensaje de protocolo de enlace.

Longitud de los datos del mensaje de protocolo de enlace

Este es un campo de 3 bytes que indica la longitud de los datos del protocolo de enlace, sin incluir el encabezado.

Tenga en cuenta que se pueden combinar varios mensajes de protocolo de enlace dentro de un registro.

Este registro normalmente no se debe enviar durante el protocolo de enlace normal o los intercambios de aplicaciones. Sin embargo, este mensaje se puede enviar en cualquier momento durante el protocolo de enlace y hasta el cierre de la sesión. Si se utiliza para señalar un error fatal, la sesión se cerrará inmediatamente después de enviar este registro, por lo que este registro se utiliza para dar una razón para este cierre. Si el nivel de alerta está marcado como advertencia, el control remoto puede decidir cerrar la sesión si decide que la sesión no es lo suficientemente confiable para sus necesidades (antes de hacerlo, el control remoto también puede enviar su propia señal).

Nivel

Este campo identifica el nivel de alerta. Si el nivel es fatal, el remitente debe cerrar la sesión inmediatamente. De lo contrario, el destinatario puede decidir terminar la sesión por sí mismo, enviando su propia alerta fatal y cerrando la sesión inmediatamente después de enviarla. El uso de registros de alerta es opcional, sin embargo, si falta antes del cierre de la sesión, la sesión puede reanudarse automáticamente (con sus protocolos de enlace).

El cierre normal de una sesión después de la finalización de la aplicación transportada debería ser alertado preferiblemente con al menos el tipo de alerta de notificación de cierre (con un nivel de advertencia simple) para evitar la reanudación automática de una nueva sesión. Señalar explícitamente el cierre normal de una sesión segura antes de cerrar efectivamente su capa de transporte es útil para prevenir o detectar ataques (como intentos de truncar los datos transportados de forma segura, si intrínsecamente no tienen una longitud o duración predeterminada que el receptor de los datos seguros pueda esperar).

Descripción

Este campo identifica qué tipo de alerta se está enviando.

Tipo de protocolo CCS

Actualmente solo 1.

Longitud

Longitud de los datos de la aplicación (excluyendo el encabezado del protocolo e incluyendo los trailers MAC y de relleno)

IMPERMEABLE

32 bytes para el HMAC basado en SHA-256 , 20 bytes para el HMAC basado en SHA-1 , 16 bytes para el HMAC basado en MD5 .

Relleno

Longitud variable; el último byte contiene la longitud de relleno.

Desde el punto de vista del protocolo de aplicación, TLS pertenece a una capa inferior, aunque el modelo TCP/IP es demasiado burdo para mostrarlo. Esto significa que el protocolo de enlace TLS se realiza normalmente (excepto en el caso de STARTTLS ) antes de que pueda iniciarse el protocolo de aplicación. En la función de servidor virtual basado en nombre que proporciona la capa de aplicación, todos los servidores virtuales coalojados comparten el mismo certificado porque el servidor tiene que seleccionar y enviar un certificado inmediatamente después del mensaje ClientHello. Esto es un gran problema en los entornos de alojamiento porque significa compartir el mismo certificado entre todos los clientes o usar una dirección IP diferente para cada uno de ellos.

Hay dos soluciones alternativas conocidas proporcionadas por X.509 :

• Si todos los servidores virtuales pertenecen al mismo dominio, se puede utilizar un certificado comodín . ^[175] Además de la selección de nombres de host imprecisos, que puede ser un problema o no, no existe un acuerdo común sobre cómo hacer coincidir los certificados comodín. Se aplican diferentes reglas según el protocolo de aplicación o el software utilizado. ^[176]
• Agregue cada nombre de host virtual en la extensión subjectAltName. El problema principal es que el certificado debe volver a emitirse cada vez que se agrega un nuevo servidor virtual.

Para proporcionar el nombre del servidor, las extensiones de seguridad de la capa de transporte (TLS) RFC  4366 permiten que los clientes incluyan una extensión de indicación de nombre de servidor (SNI) en el mensaje ClientHello extendido. Esta extensión indica al servidor inmediatamente a qué nombre desea conectarse el cliente, de modo que el servidor pueda seleccionar el certificado apropiado para enviar a los clientes.

RFC  2817 también documenta un método para implementar hospedaje virtual basado en nombres mediante la actualización de HTTP a TLS a través de un encabezado de actualización HTTP/1.1 . Normalmente, esto se hace para implementar de forma segura HTTP sobre TLS dentro del esquema de URI "http" principal (lo que evita la bifurcación del espacio de URI y reduce la cantidad de puertos utilizados); sin embargo, actualmente pocas implementaciones admiten esto. ^{[ cita requerida ]}

• Negociación de protocolo de capa de aplicación : una extensión TLS utilizada para SPDY y TLS False Start
• Bullrun (programa de descifrado) : un programa secreto anti-cifrado administrado por la Agencia de Seguridad Nacional de los EE. UU.
• Autoridad de certificación
• Transparencia del certificado
• Credencial delegada
• Seguridad de transporte estricta HTTP (HSTS)
• Archivo de llavero
• Tecnología de comunicaciones privadas (PCT): un competidor histórico de Microsoft para SSL 2.0
• QUIC (Quick UDP Internet Connections) – “…fue diseñado para proporcionar protección de seguridad equivalente a TLS/SSL”; el objetivo principal de QUIC es mejorar el rendimiento percibido de las aplicaciones web orientadas a la conexión que actualmente utilizan TCP
• Criptografía controlada por servidor
• cifrado tcp
• Seguridad de la capa de transporte de datagramas
• Aceleración TLS

Wikimedia Commons tiene medios relacionados con SSL y TLS .

• Wagner, David; Schneier, Bruce (noviembre de 1996). "Análisis del protocolo SSL 3.0" (PDF) . Actas del segundo taller de USENIX sobre comercio electrónico . USENIX Press. págs. 29–40. Archivado (PDF) desde el original el 16 de octubre de 2006. Consultado el 12 de octubre de 2006 .
• Rescorla, Eric (2001). SSL y TLS: diseño y construcción de sistemas seguros . Estados Unidos: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
• Stephen A. Thomas (2000). Fundamentos de SSL y TLS para proteger la Web . Nueva York: Wiley. ISBN 978-0-471-38354-3.
• Bard, Gregory (2006). "Un desafiante pero factible ataque de texto simple elegido adaptativo por bloques contra SSL". Asociación Internacional de Investigación Criptológica (136). Archivado desde el original el 23 de septiembre de 2011. Consultado el 23 de septiembre de 2011 .
• Canvel, Brice. "Intercepción de contraseñas en un canal SSL/TLS". Archivado desde el original el 20 de abril de 2016. Consultado el 20 de abril de 2007 .
• RFC de cambio para la renegociación de TLS . 2010. doi :10.17487/RFC5746. RFC  5746 .
• Creación de VPN con IPsec y SSL/TLS Archivado el 12 de abril de 2015 en Wayback Machine Artículo de Linux Journal de Rami Rosen
• Joshua Davies (2010). Implementación de SSL/TLS . Wiley. ISBN 978-0470920411.
• Polk, Tim; McKay, Kerry; Chokhani, Santosh (abril de 2014). "Directrices para la selección, configuración y uso de implementaciones de seguridad de la capa de transporte (TLS)" (PDF) . Instituto Nacional de Normas y Tecnología. Archivado desde el original (PDF) el 2014-05-08 . Consultado el 2014-05-07 .
• Abdou, AbdelRahman; van Oorschot, Paul (agosto de 2017). "Verificación de la ubicación del servidor (SLV) y fijación de la ubicación del servidor: aumento de la autenticación TLS". ACM Transactions on Privacy and Security . 21 (1): 1:1–1:26. doi :10.1145/3139294. S2CID  5869541. Archivado desde el original el 22 de marzo de 2019. Consultado el 11 de enero de 2018 .
• Ivan Ristic (2022). Bulletproof TLS y PKI, segunda edición . Feisty Duck. ISBN 978-1907117091.

La versión actual aprobada de (D)TLS es la versión 1.3, que se especifica en:

• RFC  8446: "El protocolo de seguridad de la capa de transporte (TLS) versión 1.3".
• RFC  9147: "Protocolo de seguridad de la capa de transporte de datagramas (DTLS) versión 1.3"

Las normas actuales sustituyen a estas versiones anteriores, que hoy se consideran obsoletas:

• RFC  5246: "El protocolo de seguridad de la capa de transporte (TLS) versión 1.2".
• RFC  6347: "Seguridad de la capa de transporte de datagramas versión 1.2"
• RFC  4346: "El protocolo de seguridad de la capa de transporte (TLS) versión 1.1".
• RFC  4347 "Seguridad de la capa de transporte de datagramas"
• RFC  2246: "El protocolo TLS versión 1.0".
• RFC  6101: "El protocolo Secure Sockets Layer (SSL) versión 3.0".
• Borrador de Internet (1995): "El protocolo SSL"

Posteriormente otras RFC ampliaron (D)TLS.

Las extensiones de (D)TLS 1.3 incluyen:

• RFC  9367: "Conjuntos de cifrado GOST para el protocolo de seguridad de la capa de transporte (TLS) versión 1.3".

Las extensiones de (D)TLS 1.2 incluyen:

• RFC  5288: " Conjuntos de cifrados en modo contador Galois (GCM) AES para TLS".
• RFC  5289: "Conjuntos de cifrados de curva elíptica TLS con SHA-256/384 y modo de contador Galois (GCM) AES".
• RFC  5746: "Extensión de indicación de renegociación de seguridad de la capa de transporte (TLS)".
• RFC  5878: "Extensiones de autorización de seguridad de la capa de transporte (TLS)".
• RFC  5932: “Suites de cifrado Camellia para TLS”
• RFC  6066: "Extensiones de seguridad de la capa de transporte (TLS): definiciones de extensión", incluye indicación de nombre de servidor y grapado OCSP .
• RFC  6091: "Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS)".
• RFC  6176: "Prohibición de Secure Sockets Layer (SSL) versión 2.0".
• RFC  6209: "Adición de las suites de cifrado ARIA a la seguridad de la capa de transporte (TLS)".
• RFC  6347: "Seguridad de la capa de transporte de datagramas versión 1.2".
• RFC  6367: "Adición de las suites de cifrado Camellia a la seguridad de la capa de transporte (TLS)".
• RFC  6460: "Perfil Suite B para seguridad de la capa de transporte (TLS)".
• RFC  6655: "Conjuntos de cifrado AES-CCM para seguridad de la capa de transporte (TLS)".
• RFC  7027: "Curvas de Brainpool de criptografía de curva elíptica (ECC) para seguridad de la capa de transporte (TLS)".
• RFC  7251: "Conjuntos de cifrados de criptografía de curva elíptica (ECC) AES-CCM para TLS".
• RFC  7301: " Extensión de negociación del protocolo de capa de aplicación de seguridad de la capa de transporte (TLS) ".
• RFC  7366: "Cifrado y luego MAC para seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS)".
• RFC  7465: "Prohibición de conjuntos de cifrados RC4".
• RFC  7507: "Valor del conjunto de cifrado de señalización de respaldo TLS (SCSV) para prevenir ataques de degradación del protocolo".
• RFC  7568: "Desuso de la versión 3.0 de Secure Sockets Layer".
• RFC  7627: "Hash de sesión de seguridad de la capa de transporte (TLS) y extensión de secreto maestro extendido".
• RFC  7685: "Una extensión de relleno ClientHello de seguridad de la capa de transporte (TLS)".
• RFC  9189: "Conjuntos de cifrado GOST para el protocolo de seguridad de la capa de transporte (TLS) versión 1.2".

Las extensiones de (D)TLS 1.1 incluyen:

• RFC  4366: "Extensiones de seguridad de la capa de transporte (TLS)" describe un conjunto de extensiones específicas y un mecanismo de extensión genérico.
• RFC  4492: " Conjuntos de cifrados de criptografía de curva elíptica (ECC) para seguridad de la capa de transporte (TLS)".
• RFC  4680: "Mensaje de protocolo de enlace TLS para datos complementarios".
• RFC  4681: "Extensión de mapeo de usuarios TLS".
• RFC  4785: "Conjuntos de cifrados de clave precompartida (PSK) con cifrado NULL para seguridad de la capa de transporte (TLS)".
• RFC  5054: "Uso del protocolo de contraseña remota segura (SRP) para la autenticación TLS". Define los conjuntos de cifrados TLS-SRP .
• RFC  5077: "Reanudación de sesión de seguridad de la capa de transporte (TLS) sin estado del lado del servidor".
• RFC  5081: "Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS)", obsoleto por RFC  6091.
• RFC  5216: "El protocolo de autenticación EAP -TLS"

Las extensiones de TLS 1.0 incluyen:

• RFC  2595: "Uso de TLS con IMAP, POP3 y ACAP". Especifica una extensión de los servicios IMAP, POP3 y ACAP que permite al servidor y al cliente utilizar la seguridad de la capa de transporte para proporcionar una comunicación privada y autenticada a través de Internet.
• RFC  2712: "Adición de conjuntos de cifrado Kerberos a la seguridad de la capa de transporte (TLS)". Los conjuntos de cifrado de 40 bits definidos en este memorando aparecen únicamente con el fin de documentar el hecho de que esos códigos de conjuntos de cifrado ya han sido asignados.
• RFC  2817: "Actualización a TLS dentro de HTTP/1.1", explica cómo utilizar el mecanismo de actualización en HTTP/1.1 para iniciar la seguridad de la capa de transporte (TLS) a través de una conexión TCP existente. Esto permite que el tráfico HTTP seguro y no seguro comparta el mismo puerto conocido (en este caso, http: en 80 en lugar de https: en 443).
• RFC  2818: "HTTP sobre TLS", distingue el tráfico seguro del tráfico inseguro mediante el uso de un "puerto de servidor" diferente.
• RFC  3207: "Extensión del servicio SMTP para SMTP seguro sobre seguridad de la capa de transporte". Especifica una extensión del servicio SMTP que permite que un servidor y un cliente SMTP utilicen seguridad de la capa de transporte para proporcionar comunicación privada y autenticada a través de Internet.
• RFC  3268: "Conjuntos de cifrados AES para TLS". Agrega conjuntos de cifrados del Estándar de cifrado avanzado (AES) a los cifrados simétricos existentes anteriormente.
• RFC  3546: "Extensiones de seguridad de la capa de transporte (TLS)", añade un mecanismo para negociar extensiones de protocolo durante la inicialización de la sesión y define algunas extensiones. Quedó obsoleto a partir de RFC  4366.
• RFC  3749: "Métodos de compresión del protocolo de seguridad de la capa de transporte", especifica el marco para los métodos de compresión y el método de compresión DEFLATE .
• RFC  3943: "Compresión del protocolo de seguridad de la capa de transporte (TLS) mediante Lempel-Ziv-Stac (LZS)".
• RFC  4132: "Adición de conjuntos de cifrado Camellia a la seguridad de la capa de transporte (TLS)".
• RFC  4162: "Adición de conjuntos de cifrado SEED a la seguridad de la capa de transporte (TLS)".
• RFC  4217: "Protección de FTP con TLS ".
• RFC  4279: "Conjuntos de cifrados de clave precompartida para seguridad de la capa de transporte (TLS)", agrega tres conjuntos de nuevos conjuntos de cifrados para el protocolo TLS para soportar la autenticación basada en claves precompartidas.

• RFC  7457: "Resumen de ataques conocidos a la seguridad de la capa de transporte (TLS) y a la TLS de datagramas (DTLS)"
• RFC  7525: "Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS)"

• Grupo de trabajo de ingeniería de Internet: grupo de trabajo TLS Archivado el 11 de enero de 2014 en Wayback Machine