Seguridad en la capa de transporte (TLS)

Transport Layer Security (TLS) o Seguridad en la capa de transporte, el sucesor de Secure Sockets Layer (SSL) o capa de puertos seguros, ahora en desuso, es un protocolo criptográfico diseñado para proporcionar seguridad en las comunicaciones a través de una red informática. El protocolo se usa ampliamente en aplicaciones como correo electrónico, mensajería instantánea y 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 criptografía, incluida la privacidad (confidencialidad), la integridad y la autenticidad mediante el uso de certificados, entre dos o más aplicaciones informáticas que se comunican. Se ejecuta en la capa de aplicación y se compone de dos capas: el registro TLS y los protocolos de protocolo de enlace TLS.

TLS es un estándar propuesto del Grupo de trabajo de ingeniería de Internet (IETF), definido por primera vez en 1999, y la versión actual es TLS 1.3, definida en agosto de 2018. TLS se basa en las especificaciones SSL anteriores (1994, 1995, 1996) desarrolladas por Netscape Communications para agregando el protocolo HTTPS a su navegador web Navigator.

Descripción

Las aplicaciones cliente-servidor utilizan el protocolo TLS para comunicarse a través de una red de una manera diseñada para evitar escuchas ilegales y manipulaciones.

Dado que las aplicaciones pueden comunicarse con o sin TLS (o SSL), es necesario que el cliente solicite que el servidor establezca una conexión TLS. Una de las principales formas de lograr esto es usar un número de puerto diferente para las conexiones TLS. Por ejemplo, el puerto 80 se usa normalmente para el tráfico HTTP sin cifrar, mientras que el puerto 443 es el puerto común que se usa para el tráfico HTTPS cifrado. Otro mecanismo es que el cliente realice una solicitud específica de protocolo al servidor para cambiar la conexión a TLS; por ejemplo, al realizar una solicitud STARTTLS al usar los protocolos de correo y noticias.

Una vez que el cliente y el servidor acordaron usar TLS, negocian una conexión con estado mediante un procedimiento de establecimiento de comunicación. Los protocolos utilizan un apretón de manos con un cifrado asimétrico para establecer no solo la configuración del cifrado, sino también una clave compartida específica de la sesión con la que se cifra la comunicación adicional 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 que solicita una conexión segura y el cliente presenta una lista de conjuntos de cifrado admitidos (cifrados y funciones hash).
• De esta lista, el servidor elige una función de cifrado y hash que también admite y notifica al cliente de la decisión.
• El servidor generalmente proporciona 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 solo el servidor debería poder descifrar con su clave privada); ambas partes luego usan el número aleatorio para generar una clave de sesión única para el cifrado y descifrado posterior de los datos durante la sesión
  • utiliza el intercambio de claves Diffie-Hellman para generar de forma segura una clave de sesión única y aleatoria para el cifrado y descifrado que tiene la propiedad adicional de confidencialidad hacia adelante: si la clave privada del servidor se revela en el futuro, no se puede usar 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 no se crea la conexión.

TLS y SSL no encajan perfectamente en ninguna capa del modelo OSI o del modelo TCP/IP. TLS se ejecuta "sobre algún protocolo de transporte confiable (por ejemplo, TCP)", lo que implicaría que está por encima de la capa de transporte. Sirve el cifrado a las 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, 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.

Cuando están protegidas por TLS, las conexiones entre un cliente (p. ej., un navegador web) y un servidor (p. ej., wikipedia.org) deben tener una o más de las siguientes propiedades:

• La conexión es privada (o segura) 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 encriptación y claves criptográficas usar antes de que se transmita el primer byte de datos (ver más abajo). La negociación de un secreto compartido es segura (el secreto negociado no está disponible para los espías y no puede ser obtenido, incluso por un atacante que se coloca en medio de la conexión) y confiable (ningún atacante puede modificar las comunicaciones durante la negociación sin ser detectado).
• La identidad de las partes que se comunican se puede autenticar mediante criptografía de clave pública. Esta autenticación es necesaria para el servidor y opcional para el cliente.
• La conexión es confiable porque cada mensaje transmitido incluye una verificación de integridad del mensaje mediante un código de autenticación de mensajes para evitar la pérdida o alteración no detectada de los datos durante la transmisión.

Además de lo anterior, la configuración cuidadosa de TLS puede proporcionar propiedades adicionales relacionadas con la privacidad, como el secreto de reenvío, lo que garantiza que cualquier divulgación futura de claves de cifrado no se pueda usar para descifrar ninguna comunicación TLS registrada en el pasado.

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 involucra muchos parámetros configurables, y no todas las opciones brindan todas las propiedades relacionadas con la privacidad descritas en la lista anterior (consulte las tablas a continuación § Intercambio de claves, § Seguridad de cifrado e § Integridad de datos).

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

Historia y desarrollo

Sistema de red de datos seguro

El Protocolo de seguridad de la capa de transporte (TLS), junto con varias otras plataformas básicas de seguridad de red, se desarrolló a través de una iniciativa conjunta iniciada en agosto de 1986, entre la Agencia de Seguridad Nacional, la Oficina Nacional de Normas, la Agencia de Comunicaciones de Defensa y doce comunicaciones y corporaciones informáticas que iniciaron un proyecto especial llamado Sistema de Red de Datos Seguros (SDNS).El programa se describió en septiembre de 1987 en la 10ª Conferencia Nacional de Seguridad Informática en un extenso conjunto de artículos publicados. El innovador programa de investigación se centró en el diseño de la próxima generación de redes de comunicaciones informáticas seguras y especificaciones de productos que se implementarán para aplicaciones en Internet públicas y privadas. Estaba destinado a complementar los nuevos estándares de Internet OSI que están surgiendo rápidamente tanto en los perfiles GOSIP del gobierno de EE. UU. como en el enorme esfuerzo de Internet ITU-ISO JTC1 a nivel internacional. Originalmente conocido como el protocolo SP4, pasó a llamarse TLS y posteriormente se publicó en 1995 como estándar internacional ITU-T X.274| ISO/CEI 10736:1995.

Programación de red segura

Los primeros esfuerzos de investigación hacia la seguridad de la capa de transporte incluyeron la interfaz de programación de aplicaciones (API) Secure Network Programming (SNP), que en 1993 exploró el enfoque de tener una API de capa de transporte segura muy parecida a los sockets de Berkeley, para facilitar la actualización de aplicaciones de red preexistentes con seguridad. medidas.

SSL 1.0, 2.0 y 3.0

Netscape desarrolló los protocolos SSL originales y Taher Elgamal, científico jefe de Netscape Communications de 1995 a 1998, ha sido descrito como el "padre de SSL".La versión 1.0 de SSL nunca se hizo pública debido a graves fallas de seguridad en el protocolo. La versión 2.0, después de su lanzamiento en febrero de 1995, se descubrió rápidamente que contenía una serie de fallas de seguridad y usabilidad. Usó las mismas claves criptográficas para la autenticación y el cifrado de mensajes. Tenía una construcción MAC débil que usaba la función hash MD5 con un prefijo secreto, lo que lo hacía vulnerable a los ataques de extensión de longitud. Y no proporcionó protección ni para el apretón de manos de apertura ni para un cierre de mensaje explícito, lo que significaba que los ataques de hombre en el medio podrí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 función ampliamente utilizada de alojamiento virtual en servidores web, por lo que la mayoría de los sitios web se veían afectados por el uso de SSL.

Estas fallas requirieron el rediseño completo del protocolo a SSL versión 3.0. 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 Consensus Development. Las versiones más recientes de SSL/TLS se basan en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por IETF como documento histórico en RFC 6101.

SSL 2.0 quedó obsoleto en 2011 por RFC 6176. En 2014, se descubrió que SSL 3.0 era vulnerable al ataque POODLE que afecta a todos los cifrados de bloque en SSL; RC4, el único cifrado sin bloques compatible con SSL 3.0, también es factible que se rompa como se usa en SSL 3.0. SSL 3.0 quedó obsoleto en junio de 2015 por RFC 7568.

TLS 1.0

TLS 1.0 se definió por primera vez en RFC 2246 en enero de 1999 como una actualización de la versión 3.0 de SSL y fue escrito por Christopher Allen y Tim Dierks de Consensus Development. Como se indica en el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dramáticas, pero son lo suficientemente importantes 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 de Microsoft, "por lo que no parecería [como] que el IETF solo estaba sellando el protocolo de Netscape".

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. En octubre de 2018, Apple, Google, Microsoft y Mozilla anunciaron conjuntamente que dejarían de utilizar TLS 1.0 y 1.1 en marzo de 2020.

TLS 1.1

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

• Se agregó protección contra ataques de encadenamiento de bloques de cifrado (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 registro IANA de parámetros.

La compatibilidad con las versiones 1.0 y 1.1 de TLS quedó ampliamente obsoleta en los sitios web alrededor de 2020, lo que deshabilitó el acceso a las versiones de Firefox anteriores a la 24 y a los navegadores basados ​​en Chromium anteriores a la 29.

TLS 1.2

TLS 1.2 se definió en RFC 5246 en agosto de 2008. Se basa en la especificación TLS 1.1 anterior. Las principales diferencias incluyen:

• La combinación MD5-SHA-1 en la función pseudoaleatoria (PRF) se reemplazó con SHA-256, con una opción para usar PRF especificados por el conjunto de cifrado.
• La combinación MD5-SHA-1 en el hash del mensaje terminado se reemplazó por SHA-256, con una opción para usar algoritmos hash específicos del conjunto de cifrado. Sin embargo, el tamaño del hash en el mensaje terminado aún debe ser de al menos 96 bits.
• La combinación MD5-SHA-1 en el elemento firmado digitalmente se reemplazó con un solo 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 de la compatibilidad con cifrados de cifrado autenticados, que se utilizan principalmente para el modo Galois/Contador (GCM) y el modo CCM del cifrado del estándar de cifrado avanzado (AES).
• Se agregaron la definición de extensiones TLS y los conjuntos de cifrado AES.

Todas las versiones de TLS se refinaron aún más en RFC 6176 en marzo de 2011, eliminando su compatibilidad con versiones anteriores de SSL, de modo que las sesiones de TLS nunca negocien el uso de la versión 2.0 de Secure Sockets Layer (SSL).

TLS 1.3

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

• Separación de acuerdos de clave y algoritmos de autenticación de los conjuntos de cifrado
• Eliminación de soporte para curvas elípticas nombradas 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 anterior
• Integrando HKDF y la propuesta semiefímera de DH
• Reemplazo de reanudación con PSK y boletos
• Compatibilidad con protocolos de enlace 1-RTT y compatibilidad inicial con 0-RTT
• Obligación de secreto directo perfecto, mediante el uso de claves efímeras durante el acuerdo de claves (EC)DH
• Eliminación de la compatibilidad con muchas funciones inseguras u obsoletas, como compresión, renegociación, cifrados que no son AEAD, intercambio de claves que no son PFS (entre las que se encuentran intercambios de claves estáticas RSA y DH estáticas), grupos DHE personalizados, negociación de formato de punto EC, protocolo Change Cipher Spec, Hora de UNIX del mensaje de saludo y entrada AD del campo de longitud a los cifrados AEAD
• Prohibición de negociación SSL o RC4 para compatibilidad con versiones anteriores
• Integración del uso del hash de sesión
• Dejar de usar el número de versión de la capa de registro y congelar el número para mejorar la compatibilidad con versiones anteriores
• Mover algunos detalles de algoritmos relacionados con la seguridad de un apéndice a la especificación y relegar ClientKeyShare a un apéndice
• Agregar el cifrado de flujo ChaCha20 con el código de autenticación de mensajes Poly1305
• Agregar los algoritmos de firma digital Ed25519 y Ed448
• Adición de los protocolos de intercambio de claves x25519 y x448
• Agregar soporte 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 manera predeterminada en febrero de 2017. Posteriormente se agregó compatibilidad con TLS 1.3, pero debido a problemas de compatibilidad para una pequeña cantidad de usuarios, no activado automáticamente: 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.

Google Chrome estableció TLS 1.3 como la versión predeterminada durante un breve período de tiempo en 2017. Luego, la eliminó como predeterminada debido a la incompatibilidad de los middleboxes, como los proxies web de Blue Coat.

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

wolfSSL permitió el uso de TLS 1.3 a partir de la versión 3.11.1, lanzada en mayo de 2017. Como la primera implementación comercial de TLS 1.3, wolfSSL 3.11.1 admitió el Draft 18 y ahora admite el Draft 28, la versión final, así como muchas versiones anteriores.. Se publicaron una serie de blogs sobre la diferencia de rendimiento entre TLS 1.2 y 1.3.

Enseptiembre 2018, el popular proyecto OpenSSL lanzó la versión 1.1.1 de su biblioteca, en la que la compatibilidad con TLS 1.3 era "la nueva característica principal".

La compatibilidad con TLS 1.3 se agregó por primera vez a SChannel con Windows 11 y Windows Server 2022.

Seguridad de transporte empresarial

Electronic Frontier Foundation elogió TLS 1.3 y expresó su preocupación por la variante del protocolo Enterprise Transport Security (ETS) que deshabilita intencionalmente importantes medidas de seguridad en TLS 1.3. Originalmente llamado Enterprise TLS (eTLS), ETS es un estándar publicado conocido como 'ETSI TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". Está diseñado para usarse completamente dentro de redes propietarias, como los sistemas bancarios. ETS no admite el secreto directo 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 detectar malware y facilitar la realización de auditorías.A pesar de los supuestos beneficios, la EFF advirtió que la pérdida del secreto directo podría facilitar la exposición de los datos y dijo que hay mejores formas de analizar el tráfico.

Certificados digitales

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

Autoridades de certificación

TLS generalmente se basa en un conjunto de autoridades de certificación de terceros confiables para establecer la autenticidad de los certificados. La confianza generalmente está anclada en una lista de certificados distribuidos con el software de agente de usuario, y la parte que confía puede modificarla.

Según Netcraft, que supervisa los certificados TLS activos, la autoridad de certificación (CA) líder en el mercado ha sido Symantec desde el comienzo de su encuesta (o VeriSign antes de que Symantec comprara la unidad de negocios de servicios de autenticación). A partir de 2015, Symantec representaba poco menos de un tercio de todos los certificados y el 44 % de los certificados válidos utilizados por el millón de sitios web más concurridos, según el recuento de Netcraft. En 2017, Symantec vendió su negocio TLS/SSL a DigiCert. En un informe actualizado, se demostró 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.

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

Algoritmos

Intercambio de llaves o acuerdo de llaves

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 datos (consulte § Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves se encuentran: claves públicas y privadas generadas con RSA (indicadas como TLS_RSA en el protocolo de protocolo de enlace TLS), Diffie-Hellman (TLS_DH), efímera Diffie-Hellman (TLS_DHE), Diffie-Hellman de curva elíptica (TLS_ECDH), Diffie-Hellman de curva elíptica efímera (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon), clave precompartida (TLS_PSK) y Contraseña remota segura (TLS_SRP).

Los métodos de acuerdo de clave TLS_DH_anon y TLS_ECDH_anon no autentican el servidor o el usuario y, por lo tanto, rara vez se usan porque son vulnerables a los ataques de intermediarios. Solo TLS_DHE y TLS_ECDHE proporcionan confidencialidad directa.

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, la solidez de la seguridad proporcionada. En julio de 2013, Google anunció que ya no usaría claves públicas de 1024 bits y cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios porque la fuerza del cifrado está directamente relacionada con el tamaño de la clave..

Cifrar

notas

1. ^Saltar a: Se debe implementar RFC 5746 para corregir una falla de renegociación que, de lo contrario, rompería este protocolo.
2. ^ Si las bibliotecas implementan correcciones enumeradas en RFC 5746, esto viola la especificación SSL 3.0, que IETF no puede cambiar a diferencia de TLS. La mayoría de las bibliotecas actuales implementan la corrección y pasan por alto la infracción que esto provoca.
3. ^Saltar a: El ataque BEAST rompe todos los cifrados de bloque (cifrados CBC) utilizados en SSL 3.0 y TLS 1.0 a menos que el cliente y/o el servidor lo mitiguen. Ver § Navegadores web.
4. ^ El ataque POODLE rompe todos los cifrados de bloque (cifrados CBC) utilizados en SSL 3.0 a menos que el cliente y/o el servidor lo mitiguen. Ver § Navegadores web.
5. ^Saltar a: Los cifrados AEAD (como GCM y CCM) solo se pueden usar en TLS 1.2 o posterior.
6. ^Saltar a: Los cifrados CBC se pueden atacar con el ataque Lucky Thirteen si la biblioteca no se escribe con cuidado para eliminar los canales secundarios de tiempo.
7. ^Saltar a: El ataque Sweet32 rompe los cifrados de bloque con un tamaño de bloque de 64 bits.
8. ^ Aunque la longitud de la clave de 3DES es de 168 bits, la fuerza de seguridad efectiva de 3DES es de solo 112 bits, que está por debajo del mínimo recomendado de 128 bits.
9. ^Saltar a: IDEA y DES se han eliminado de TLS 1.2.
10. ^Saltar a: Los conjuntos de cifrado de 40 bits de fuerza se diseñaron intencionalmente con longitudes de clave reducidas para cumplir con las regulaciones estadounidenses rescindidas desde entonces que prohíben la exportación de software criptográfico que contenga ciertos algoritmos de cifrado fuertes (consulte Exportación de criptografía de los Estados Unidos). Estas suites débiles están prohibidas en TLS 1.1 y versiones posteriores.
11. ^ El RFC 7465 prohíbe el uso de RC4 en todas las versiones de TLS (porque los ataques de RC4 debilitan o rompen el RC4 utilizado en SSL/TLS).
12. ^ Solo autenticación, sin cifrado.

Integridad de los datos

Se utiliza un código de autenticación de mensajes (MAC) para la integridad de los datos. HMAC se utiliza para el modo CBC de cifrados de bloque. El cifrado autenticado (AEAD), como el modo GCM y el modo CCM, usa MAC integrado con AEAD y no usa HMAC. PRF basado en HMAC o HKDF se utiliza para el protocolo de enlace TLS.

Solicitudes y adopción

En el diseño de aplicaciones, TLS generalmente se implementa sobre los protocolos de la capa de transporte, cifrando todos los datos relacionados con el protocolo de protocolos como HTTP, FTP, SMTP, NNTP y XMPP.

Históricamente, TLS se ha utilizado principalmente con protocolos de transporte confiables, 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)..

Sitios web

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.

notas

1. ^ ver § Tabla de cifrado arriba
2. ^ ver § Navegadores web y § Ataques contra secciones TLS/SSL

Navegadores web

A partir de abril de 2016, las últimas versiones de todos los principales navegadores web son compatibles con TLS 1.0, 1.1 y 1.2, y las tienen habilitadas de manera 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 actualmente admiten varias versiones de IE, pero esto ha cambiado de acuerdo con las Preguntas frecuentes sobre la política de ciclo de vida de soporte de Internet Explorer de Microsoft, "a partir del 12 de enero de 2016, solo la versión más reciente de Internet Explorer disponible para un sistema operativo compatible recibirá soporte técnico y actualizaciones de seguridad." Luego, la página continúa para enumerar 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, que es en Microsoft'

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

• Mitigaciones contra el ataque POODLE: algunos navegadores ya evitan el retroceso a SSL 3.0; sin embargo, esta mitigación debe ser compatible no solo con los clientes sino también con los servidores. Se requiere deshabilitar el propio SSL 3.0, implementar la "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í mismo está deshabilitado de forma predeterminada desde la versión 40. El soporte de SSL 3.0 en sí mismo se eliminó desde la versión 44).
  • Mozilla Firefox: completo (la compatibilidad con SSL 3.0 se eliminó desde la versión 39. SSL 3.0 está deshabilitado de manera predeterminada y el respaldo a SSL 3.0 está deshabilitado desde la versión 34, TLS_FALLBACK_SCSV está implementado desde la versión 35. En ESR, SSL 3.0 está deshabilitado por predeterminado y TLS_FALLBACK_SCSV se implementa desde ESR 31.3.)
  • Internet Explorer: parcial (solo en la versión 11, SSL 3.0 está deshabilitado de forma predeterminada desde abril de 2015. La versión 10 y anteriores aún son vulnerables contra POODLE).
  • Opera: completo (TLS_FALLBACK_SCSV se implementa desde la versión 20, la "división de registros anti-POODLE", que es efectiva solo con la implementación del lado del cliente, se implementa desde la versión 25, SSL 3.0 está deshabilitado de forma predeterminada desde la versión 27. Compatibilidad con SSL 3.0 se eliminará desde la versión 31.)
  • Safari: completo (solo en OS X 10.8 y posteriores e iOS 8, se niegan los cifrados CBC durante el respaldo a SSL 3.0, pero esto significa que usará RC4, que tampoco se recomienda. El soporte de SSL 3.0 en sí se elimina en OS X 10.11 y posteriores e iOS 9.)
• Mitigación contra ataques RC4:
  • Google Chrome deshabilitó RC4 excepto como alternativa desde la versión 43. RC4 está deshabilitado desde Chrome 48.
  • Firefox deshabilitó RC4 excepto como alternativa desde la versión 36. Firefox 44 deshabilitó RC4 de forma predeterminada.
  • Opera deshabilitó RC4 excepto como alternativa desde la versión 30. RC4 está deshabilitado desde Opera 35.
  • Internet Explorer para Windows 7/Server 2008 R2 y para Windows 8/Server 2012 han establecido la prioridad de RC4 en la más baja y también pueden deshabilitar RC4, excepto como respaldo a través de la configuración del registro. Internet Explorer 11 Mobile 11 para Windows Phone 8.1 deshabilite RC4 excepto como alternativa si no funciona ningún otro algoritmo habilitado. Edge e IE 11 deshabilitan RC4 por completo en agosto de 2016.
• Mitigación contra ataque FREAK:
  • El navegador de Android incluido con Android 4.0 y versiones anteriores sigue siendo vulnerable al ataque FREAK.
  • Internet Explorer 11 Mobile sigue siendo vulnerable al ataque FREAK.
  • Google Chrome, Internet Explorer (escritorio), Safari (escritorio y móvil) y Opera (móvil) tienen mitigaciones FREAK en su lugar.
  • Mozilla Firefox en todas las plataformas y Google Chrome en Windows no se vieron afectados por FREAK.

notas

1. ^ ¿El navegador tiene mitigaciones o no es vulnerable a los ataques conocidos? Tenga en cuenta que la seguridad real depende de otros factores, como el cifrado negociado, la fuerza del cifrado, etc. (ver § Tabla de cifrado).
2. ^ Si un usuario o administrador puede elegir los protocolos que se utilizarán o no. En caso afirmativo, se pueden evitar varios ataques como BEAST (vulnerable en SSL 3.0 y TLS 1.0) o POODLE (vulnerable en SSL 3.0).
3. ^Saltar a: Si EV SSL y DV SSL (SSL normal) se pueden distinguir mediante indicadores (icono de candado verde, barra de direcciones verde, etc.) o no.
4. ^Saltar a: por ejemplo, división de registros 1/n-1.
5. ^Saltar a: por ejemplo, deshabilitar la compresión de encabezado en HTTPS/SPDY.
6. ^Saltar a:
   • Mitigaciones completas; deshabilitando SSL 3.0 en sí mismo, "división de registros anti-POODLE". La "división de registros Anti-POODLE" solo es efectiva con la implementación del lado del cliente y es válida de acuerdo con la especificación SSL 3.0; sin embargo, también puede causar problemas de compatibilidad debido a problemas en las implementaciones del lado del servidor.
   • mitigaciones parciales; deshabilitar el respaldo a SSL 3.0, TLS_FALLBACK_SCSV, deshabilitar conjuntos de cifrado con el modo de operación CBC. Si el servidor también es compatible con TLS_FALLBACK_SCSV, el ataque POODLE fallará contra esta combinación de servidor y navegador, pero las conexiones en las que el servidor no es compatible con TLS_FALLBACK_SCSV y admite SSL 3.0 seguirán siendo vulnerables. Si se deshabilitan los conjuntos de cifrado con el modo de operación CBC en SSL 3.0, solo están disponibles los conjuntos de cifrado con RC4, los ataques RC4 se vuelven más fáciles.
   • Al deshabilitar SSL 3.0 manualmente, el ataque POODLE fallará.
7. ^Saltar a:
   • Mitigación completa; deshabilitar suites de cifrado con RC4.
   • Mitigaciones parciales para mantener la compatibilidad con los sistemas antiguos; establecer la prioridad de RC4 a menor.
8. ^ Google Chrome (y Chromium) admite TLS 1.0 y TLS 1.1 desde la versión 22 (se agregó y luego se eliminó de la versión 21). Se agregó compatibilidad con TLS 1.2 y luego se eliminó de Chrome 29.
9. ^ Utiliza la implementación de TLS proporcionada por BoringSSL para Android, OS X y Windows o por NSS para Linux. Google está cambiando la biblioteca TLS utilizada en Chrome a BoringSSL de NSS por completo.
10. ^Saltar a: configure la habilitación/deshabilitación de cada protocolo a través de la configuración/opción (el nombre del menú depende de los navegadores)
11. ^Saltar a: configure la versión máxima y mínima de los protocolos de habilitación con la opción de línea de comandos
12. ^ TLS_FALLBACK_SCSV está implementado. El respaldo a SSL 3.0 está deshabilitado desde la versión 39.
13. ^ Además de TLS_FALLBACK_SCSV y deshabilitar un respaldo a SSL 3.0, SSL 3.0 en sí mismo está deshabilitado de forma predeterminada.
14. ^Saltar a: configure la versión mínima de los protocolos de habilitación a través de chrome://flags (la versión máxima se puede configurar con la opción de línea de comandos)
15. ^Saltar a: Solo cuando no haya disponibles conjuntos de cifrado que no sean RC4, se utilizarán conjuntos de cifrado con RC4 como respaldo.
16. ^Saltar a: Todos los conjuntos de cifrado RC4 están deshabilitados de forma predeterminada.
17. ^ Utiliza la implementación de TLS proporcionada por NSS. A partir de Firefox 22, Firefox solo es compatible con TLS 1.0 a pesar de que el NSS incluido es compatible con TLS 1.1. Desde Firefox 23, TLS 1.1 se puede habilitar, pero no se habilitó de forma predeterminada debido a problemas. Firefox 24 tiene la compatibilidad con TLS 1.2 desactivada de forma predeterminada. TLS 1.1 y TLS 1.2 se habilitaron de forma predeterminada en la versión Firefox 27.
18. ^Saltar a: configure la versión máxima y mínima de los protocolos de habilitación a través de about:config
19. ^ SSL 3.0 en sí mismo está deshabilitado de forma predeterminada. Además, el respaldo a SSL 3.0 está deshabilitado desde la versión 34 y TLS_FALLBACK_SCSV está implementado desde la 35.0 y ESR 31.3.
20. ^Saltar a: IE utiliza la implementación TLS del sistema operativo Microsoft Windows proporcionado por el proveedor de soporte de seguridad SChannel. TLS 1.1 y 1.2 están deshabilitados de forma predeterminada hasta IE11.
21. ^Saltar a: Windows NT 3.1 admite IE 1–2, Windows NT 3.5 admite IE 1–3, Windows NT 3.51 y Windows NT 4.0 admite IE 1–6
22. ^Saltar a: Windows XP, así como Server 2003 y versiones anteriores, solo admiten cifrados débiles como 3DES y RC4 listos para usar. Los cifrados débiles de esta versión de SChannel no solo se usan para IE, sino también para otros productos de Microsoft que se ejecutan en este sistema operativo, como Office o Windows Update. Solo Windows Server 2003 puede obtener una actualización manual para admitir cifrados AES por KB948963
23. ^Saltar a: MS13-095 o MS14-049 para Windows Server 2003, Windows XP x64 y Windows XP SP3 (32 bits)
24. ^ RC4 se puede deshabilitar, excepto como respaldo (solo cuando no hay conjuntos de cifrado con otros que RC4 disponibles, los conjuntos de cifrado con RC4 se utilizarán como respaldo).
25. ^Saltar a: El respaldo a SSL 3.0 son sitios bloqueados de forma predeterminada en Internet Explorer 11 para el modo protegido. SSL 3.0 está deshabilitado de forma predeterminada en Internet Explorer 11 desde abril de 2015.
26. ^Saltar a: Podría deshabilitarse a través de la edición del registro, pero necesita herramientas de terceros para hacerlo.
27. ^ Edge (anteriormente conocido como Project Spartan) se basa en una bifurcación del motor de renderizado de Internet Explorer 11.
28. ^ Safari usa la implementación del sistema operativo en Mac OS X, Windows (XP, Vista, 7) con una versión desconocida, Safari 5 es la última versión disponible para Windows. OS X 10.8 tiene soporte de SecureTransport para TLS 1.1 y 1.2 El informe Qualys SSL simula Safari 5.1.9 conectándose con TLS 1.0 no 1.1 o 1.2
29. ^ En septiembre de 2013, Apple implementó la mitigación BEAST en OS X 10.8 (Mountain Lion), pero no se activó de forma predeterminada, lo que resultó en que Safari aún fuera teóricamente vulnerable al ataque BEAST en esa plataforma. La mitigación BEAST se ha habilitado de forma predeterminada desde OS X 10.8.5 actualizado en febrero de 2014.
30. ^Saltar a: Debido a que Apple eliminó la compatibilidad con todos los protocolos CBC en SSL 3.0 para mitigar POODLE, esto deja solo RC4, que también está completamente dañado por los ataques RC4 en SSL 3.0.
31. ^ Mobile Safari y el software de terceros que utilizan la biblioteca UIWebView del sistema utilizan la implementación del sistema operativo iOS, que admite TLS 1.2 a partir de iOS 5.0.

Bibliotecas

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 de TLS/SSL)
• Los programadores de Delphi pueden usar una biblioteca llamada Indy que utiliza OpenSSL o, alternativamente, ICS que ahora admite TLS 1.3.
• GnuTLS: una implementación gratuita (con licencia LGPL)
• Java Secure Socket Extension (JSSE): la API de Java y la implementación del proveedor (denominada SunJSSE)
• LibreSSL: una bifurcación de OpenSSL por proyecto OpenBSD.
• MatrixSSL: una implementación con licencia dual
• 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 por FIPS 140
• OpenSSL: una implementación gratuita (licencia BSD con algunas extensiones)
• SChannel: una implementación de SSL y TLS 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.

1. ^ SSL 2.0 client hello es compatible por motivos de compatibilidad con versiones anteriores, aunque SSL 2.0 no es compatible.
2. ^ La implementación del lado del servidor del protocolo SSL/TLS todavía admite el procesamiento de mensajes de saludo de cliente compatibles con v2 recibidos.
3. ^ Transporte seguro: SSL 2.0 se suspendió en OS X 10.8. SSL 3.0 se suspendió en OS X 10.11 e iOS 9. TLS 1.1 y 1.2 están disponibles en iOS 5.0 y posteriores, y OS X 10.9 y posteriores.

Un documento presentado en la conferencia ACM de 2012 sobre seguridad informática y de comunicaciones mostró que pocas aplicaciones usaban algunas de estas bibliotecas SSL correctamente, lo que generaba vulnerabilidades. Según los autores

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

Otros usos

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

TLS también se puede usar para tunelizar una pila de red completa para crear una VPN, como es el caso de OpenVPN y OpenConnect. Muchos proveedores ya han casado las capacidades de encriptación y autenticación de TLS con 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, a fin de habilitar el soporte para aplicaciones de cliente/servidor. En comparación con las tecnologías IPsec VPN tradicionales, TLS tiene algunas ventajas inherentes en el firewall y NAT transversal 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 encriptación de la señalización SIP asociada con VoIP y otras aplicaciones basadas en SIP.

Seguridad

Ataques contra TLS/SSL

Los ataques significativos contra TLS/SSL se enumeran a continuación.

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

Ataque de renegociación

En agosto de 2009 se descubrió una vulnerabilidad del procedimiento de renegociación que puede dar lugar a ataques de inyección de texto sin formato contra SSL 3.0 y todas las versiones actuales de TLS.Por ejemplo, permite que un atacante que pueda secuestrar una conexión https empalme sus propias solicitudes al comienzo de la conversación que el cliente tiene con el servidor web. El atacante en realidad no puede descifrar la comunicación cliente-servidor, por lo que es diferente de un ataque típico de hombre en el medio. Una solución a corto plazo es que los servidores web dejen de permitir la renegociación, lo que normalmente no requerirá otros cambios a menos que se utilice la autenticación del certificado del cliente. Para corregir 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 la información sobre los apretones de manos anteriores en cualquier apretón de manos de renegociación. Esta extensión se ha convertido en un estándar propuesto y se le ha asignado el númeroRFC 5746. Varias bibliotecas han implementado el RFC.

Ataques de degradación:Ataque FREAK yAtaque de atasco

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

Las modificaciones anteriores a los protocolos originales, como False Start (adoptado y habilitado por Google Chrome) o Snap Start, supuestamente introdujeron ataques limitados de degradación del protocolo TLS o permitieron modificaciones a la lista de conjuntos de cifrado enviada por el cliente al servidor. Al hacerlo, un atacante podría influir en la selección del conjunto de cifrado en un intento de degradar el conjunto de cifrado negociado para usar un algoritmo de cifrado simétrico más débil o un intercambio de claves más débil. Un documento 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 que un atacante recupere las claves de cifrado sin conexión y acceda a los datos cifrados.

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, al navegador web predeterminado de Android y a algunos navegadores Safari. El ataque implicó engañar a los servidores para que negociaran una conexión TLS utilizando claves de cifrado de 512 bits criptográficamente débiles.

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

Ataques entre protocolos: DROWN

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

Ataque BESTIA

El 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una prueba de concepto llamada BEAST (Browser Exploit Against SSL/TLS) utilizando 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: un atacante que observa 2 bloques de texto cifrado consecutivos C0, C1 puede comprobar si el bloque de texto sin formato P1 es igual a x eligiendo el siguiente bloque de texto sin formato P2 = x C0 C1; según la operación CBC, C2 = E(C1 P2) = E(C1 x C0 C1) = E(C0x), que será igual a C1 si x = P1. No se habían demostrado previamente explotaciones prácticas para esta vulnerabilidad, que fue descubierta originalmente por Phillip Rogaway en 2002. La vulnerabilidad del ataque se solucionó con TLS 1.1 en 2006, pero TLS 1.1 no había tenido una adopción amplia antes de esta demostración de ataque.

RC4 como cifrado de flujo es inmune al ataque BEAST. Por lo tanto, RC4 se usó ampliamente como una forma de mitigar el ataque BEAST en el lado del servidor. Sin embargo, en 2013, los investigadores encontraron más debilidades en RC4. A partir de entonces, ya no se recomendó habilitar RC4 en el lado del servidor.

Chrome y Firefox en sí mismos no son vulnerables al ataque BEAST, 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 rota de la especificación SSL pueden dejar de funcionar como resultado.

Microsoft lanzó el Boletín de seguridad MS12-006 el 10 de enero de 2012, que solucionó la vulnerabilidad BEAST al cambiar la forma en que el componente Canal seguro de Windows (SChannel) transmite paquetes de red encriptados desde el extremo del servidor. Los usuarios de Internet Explorer (anteriores 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 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.

Ataques CRIME y BREACH

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

Si bien el ataque CRIME se presentó como un ataque general que podría funcionar 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 las vulnerabilidades contra TLS y SPDY. en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, aunque los autores de CRIME han advertido que esta vulnerabilidad podría estar incluso más extendida que la compresión SPDY y TLS combinadas. En 2013 se anunció una nueva instancia del ataque CRIME contra la compresión HTTP, denominada BREACH. Basado en el ataque CRIME, un ataque BREACH puede extraer tokens de inicio de sesión, direcciones de correo electrónico u otra información confidencial del tráfico web cifrado con TLS en tan solo 30 segundos (dependiendo de la cantidad de bytes que se extraerán).Todas las versiones de TLS y SSL están en riesgo de BREACH, independientemente del algoritmo de cifrado o cifrado utilizado. A diferencia de las instancias anteriores de CRIME, contra las que se puede defender con éxito desactivando la compresión TLS o la compresión de encabezado SPDY, BREACH aprovecha la compresión HTTP que, de manera realista, no se puede desactivar, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para los usuarios. Esta es una limitación conocida de TLS, ya que es susceptible a un ataque de texto sin formato elegido contra los datos de la capa de aplicación que debe proteger.

Ataques de tiempo en el relleno

Las versiones anteriores de TLS eran vulnerables al ataque del oráculo de relleno descubierto en 2002. En 2013 se publicó una variante novedosa, llamada ataque Lucky Thirteen.

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

Se lanzó una solución como la extensión Encrypt-then-MAC para la especificación TLS, lanzada como RFC 7366. El ataque Lucky Thirteen se puede mitigar en TLS 1.2 usando solo cifrados AES_GCM; AES_CBC sigue siendo vulnerable.

Ataque de caniche

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

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

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

Ataques RC4

A pesar de la existencia de ataques a RC4 que rompieron su seguridad, los conjuntos de cifrado en SSL y TLS que se basaban en RC4 todavía se consideraban seguros antes de 2013 según la forma en que se usaban en SSL y TLS. En 2011, se recomendó la suite RC4 como solución alternativa para el ataque BEAST. Las nuevas formas de ataque reveladas en marzo de 2013 demostraron de manera concluyente la viabilidad de romper RC4 en TLS, lo que sugiere que no era una buena solución para BEAST. AlFardan, Bernstein, Paterson, Poettering y Schuldt propusieron un escenario de ataque que utilizó sesgos estadísticos recientemente descubiertos en la tabla de claves RC4 para recuperar partes del texto sin formato con una gran cantidad de cifrados TLS. Un ataque a RC4 en TLS y SSL que requiere 13×2cifrados para romper RC4 se dio a conocer el 8 de julio de 2013 y luego se describió como "factible" en la presentación adjunta en un Simposio de seguridad de USENIX en agosto de 2013. En julio de 2015, las mejoras posteriores en el ataque hacen que sea cada vez más práctico vencer la seguridad de RC4- TLS encriptado.

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

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

Ataque de truncamiento

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

Publicado en julio de 2013, el ataque hace que los servicios web como Gmail y Hotmail muestren una página que informa al usuario que ha cerrado sesión con éxito, al mismo tiempo que garantiza que el navegador del usuario mantiene la autorización con el servicio, lo que permite que un atacante acceda posteriormente a el navegador para acceder y tomar el control de la cuenta iniciada del usuario. El ataque no se basa en instalar 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).Esta vulnerabilidad también requiere acceso a la computadora de la víctima. Otra posibilidad es cuando se usa FTP, la conexión de datos puede tener un FIN falso en el flujo de datos, y si las reglas del protocolo para intercambiar alertas close_notify no se cumplen, un archivo puede truncarse.

Ataque profano de PAC

Este ataque, descubierto a mediados de 2016, explota las debilidades en el Protocolo de detección automática de proxy web (WPAD) para exponer la URL a la que un usuario web intenta acceder a través de un enlace web habilitado para TLS. 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 usan para autenticar a los usuarios. Los servicios para compartir documentos, como los que ofrecen Google y Dropbox, también funcionan enviando al usuario un token de seguridad que se incluye en la URL. Un atacante que obtiene dichas URL puede obtener acceso total a la cuenta o los datos de la víctima.

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

Dulce32 ataque

El ataque Sweet32 rompe todos los cifrados de bloque de 64 bits utilizados en el modo CBC como se usa en TLS mediante la explotación de un ataque de cumpleaños y un ataque de intermediario o la inyección de un JavaScript malicioso en una página web. El propósito del ataque man-in-the-middle o la inyección de JavaScript es permitir que el atacante capture suficiente tráfico para montar un ataque de cumpleaños.

Errores de implementación:bicho desgarrado,Ataque BERserk, error de Cloudflare

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

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

En febrero de 2015, después de que los medios informaran sobre la preinstalación oculta del adware Superfish en algunas computadoras portátiles Lenovo, 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 usando el nombre de la empresa, Komodia, como una frase de contraseña La biblioteca de Komodia se diseñó para interceptar el tráfico TLS/SSL del lado del cliente para el control y la vigilancia de los padres, pero también se usó en numerosos programas publicitarios, incluido Superfish, que a menudo se instalaban subrepticiamente sin que el usuario de la computadora lo supiera. A su vez, estos programas potencialmente no deseados instalaron el certificado raíz corrupto, lo que permitió a los atacantes controlar 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 por 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. 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.

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. Similar en sus efectos al error Heartbleed descubierto en 2014, este error de desbordamiento, ampliamente conocido como Cloudbleed, permitió que terceros no autorizados leyeran datos en la memoria de los programas que se ejecutan en los servidores, datos que de otro modo deberían haber estado protegidos por TLS.

Encuesta de sitios web vulnerables a ataques

A partir de julio de 2021, el Movimiento de Internet Confiable estimó la proporción de sitios web que son vulnerables a los ataques TLS.

Reenviar secreto

El secreto directo es una propiedad de los sistemas criptográficos que garantiza que una clave de sesión derivada de un conjunto de claves públicas y privadas no se verá comprometida si una de las claves privadas se ve comprometida en el futuro. Sin confidencialidad directa, 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 las sesiones anteriores que lo hayan utilizado (siempre y cuando, por supuesto, estas sesiones pasadas hayan sido interceptadas y almacenadas). en el momento de la transmisión). Una implementación de TLS puede brindar confidencialidad directa al requerir el uso del intercambio efímero de claves Diffie-Hellman 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 usan OpenSSL.Sin embargo, muchos clientes y servidores que admiten TLS (incluidos navegadores y servidores web) no están configurados para implementar tales restricciones. En la práctica, a menos que un servicio web utilice el intercambio de claves Diffie-Hellman para implementar el secreto de reenvío, 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, por medio de una orden judicial.

Incluso cuando se implementa el intercambio de claves Diffie-Hellman, los mecanismos de administración de sesiones del lado del servidor pueden afectar la confidencialidad directa. 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 cifrado de confidencialidad hacia adelante, y las claves de ticket de sesión TLS de larga duración anulan el intento de implementación. adelante el secreto. La investigación de la Universidad de Stanford en 2014 también encontró que de 473.802 servidores TLS encuestados, el 82,9 % de los servidores que implementaban el intercambio efímero de claves Diffie-Hellman (DHE) para respaldar el secreto directo usaban parámetros débiles de Diffie-Hellman. Estas elecciones de parámetros débiles podrían comprometer potencialmente la efectividad del secreto directo que los servidores buscaban proporcionar.

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

Interceptación de TLS

La interceptación TLS (o la interceptación HTTPS si se aplica particularmente a ese protocolo) es la práctica de interceptar un flujo de datos cifrados para descifrarlo, leerlo y posiblemente manipularlo, y luego volver a cifrarlo y enviar los datos de nuevo. Esto se hace a través de un "proxy transparente": el software de interceptación finaliza la conexión TLS entrante, inspecciona el texto sin formato HTTP y luego crea una nueva conexión TLS con el destino.

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

Un inconveniente significativo de la interceptación de TLS/HTTPS es que presenta nuevos riesgos de seguridad propios. Una limitación notable es que proporciona un punto donde el tráfico de la red está disponible sin cifrar, lo que brinda a los atacantes un incentivo para atacar este punto en particular para obtener acceso a contenido seguro. La interceptación también permite que el operador de la red, o las personas que obtengan acceso a su sistema de interceptación, realicen ataques de intermediario contra los usuarios de la red. Un estudio de 2017 encontró que "la interceptación de HTTPS se ha vuelto sorprendentemente generalizada y que los productos de interceptación como clase tienen un impacto negativo dramático en la seguridad de la conexión".

Detalles del protocolo

El protocolo TLS intercambia registros, que encapsulan los datos que se intercambiarán en un formato específico (ver más abajo). Cada registro se puede comprimir, rellenar, agregar un código de autenticación de mensajes (MAC) o cifrar, todo según el estado de la conexión. Cada registro tiene un tipo de contenido.campo que designa el tipo de datos encapsulados, un campo de longitud y un campo de versión TLS. Los datos encapsulados pueden ser mensajes de control o de procedimiento del propio TLS, o simplemente los datos de la aplicación que TLS necesita transferir. Las especificaciones (conjunto de cifrado, claves, etc.) requeridas para intercambiar datos de aplicaciones por TLS, se acuerdan en el "apretón de manos TLS" entre el cliente que solicita los datos y el servidor que responde a las solicitudes. Por lo tanto, el protocolo define tanto la estructura de las cargas útiles transferidas en TLS como el procedimiento para establecer y monitorear la transferencia.

Apretón de manos TLS

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

Protocolo de enlace TLS básico

A continuación, se muestra un ejemplo de conexión típico, que ilustra un protocolo de enlace en el que el servidor (pero no el cliente) se autentica mediante 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 cifrado sugeridos y métodos de compresión sugeridos. Si el cliente está intentando realizar un protocolo de enlace reanudado, puede enviar una ID de sesión. Si el cliente puede utilizar la negociación del protocolo de capa de aplicación, puede incluir una lista de protocolos de aplicación admitidos, como HTTP/2.
   • El servidor responde con un mensaje ServerHello, que contiene la versión del protocolo elegido, un número aleatorio, un conjunto de cifrado y un método de compresión de las opciones que ofrece el cliente. Para confirmar o permitir la reanudación de los apretones de manos, el servidor puede enviar una ID de sesión. La versión 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 (según el conjunto de cifrado seleccionado, el servidor puede omitirlo).
   • El servidor envía su mensaje ServerKeyExchange (según el conjunto de cifrado seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrado DHE, ECDHE y DH_anon.
   • El servidor envía un mensaje ServerHelloDone, indicando que ha terminado con la negociación de protocolo de enlace.
   • El cliente responde con un mensaje ClientKeyExchange, que puede contener un PreMasterSecret, una clave pública o nada. (Nuevamente, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra mediante la clave pública del certificado del servidor.
   • El cliente y el servidor luego usan 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) para esta conexión se derivan de este secreto maestro (y los valores aleatorios generados por el cliente y el servidor), que se pasan a través de una función pseudoaleatoria cuidadosamente diseñada.
2. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciéndole al servidor: "Todo lo que le diga a partir de ahora será autenticado (y encriptado si los parámetros de encriptación estaban presentes en el certificado del servidor)". ChangeCipherSpec es en sí mismo un protocolo de nivel de registro con tipo de contenido de 20.
   • El cliente envía un mensaje Finalizado autenticado y encriptado, que contiene un hash y MAC sobre los mensajes de protocolo de enlace anteriores.
   • El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y el MAC. Si falla el descifrado o la verificación, se considera que el protocolo de enlace ha fallado y la conexión debe interrumpirse.
3. Finalmente, el servidor envía un ChangeCipherSpec, diciéndole al cliente: "Todo lo que le diga a partir de ahora será autenticado (y cifrado, si se negoció el cifrado)".
   • El servidor envía su mensaje Finalizado autenticado y cifrado.
   • El cliente realiza el mismo procedimiento de descifrado y verificación que el servidor realizó en el paso anterior.
4. Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de la aplicación está habilitado, con un tipo de contenido de 23. Los mensajes de la 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á.

Apretón de manos TLS autenticado por el cliente

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

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 elegido, un número aleatorio, un conjunto de cifrado y un método de compresión de las opciones que ofrece el cliente. El servidor también puede enviar una identificación de sesión como parte del mensaje para realizar un protocolo de enlace reanudado.
   • El servidor envía su mensaje de Certificado (según el conjunto de cifrado seleccionado, el servidor puede omitirlo).
   • El servidor envía su mensaje ServerKeyExchange (según el conjunto de cifrado seleccionado, el servidor puede omitirlo). Este mensaje se envía para todos los conjuntos de cifrado DHE, ECDHE y DH_anon.
   • El servidor envía un mensaje CertificateRequest para solicitar un certificado del cliente.
   • El servidor envía un mensaje ServerHelloDone, indicando que ha terminado con la negociación de protocolo de enlace.
   • El cliente responde con un mensaje de Certificado, que contiene el certificado del cliente, pero no su clave privada.
   • El cliente envía un mensaje ClientKeyExchange, que puede contener un PreMasterSecret, una clave pública o nada. (Nuevamente, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra mediante la clave pública del certificado del servidor.
   • El cliente envía un mensaje CertificateVerify, que es una firma sobre los mensajes de protocolo de enlace anteriores utilizando la clave privada del certificado del cliente. Esta firma se puede verificar utilizando la clave pública del certificado del cliente. Esto le permite al servidor saber que el cliente tiene acceso a la clave privada del certificado y, por lo tanto, posee el certificado.
   • El cliente y el servidor luego usan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave ("claves de sesión") para esta conexión se derivan de este secreto maestro (y los valores aleatorios generados por el cliente y el servidor), que se pasan a través de una función pseudoaleatoria cuidadosamente diseñada.
2. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciéndole al servidor: "Todo lo que le diga a partir de ahora será autenticado (y encriptado si se negoció el cifrado)". El ChangeCipherSpec es en sí mismo un protocolo de nivel de registro y tiene tipo 20 y no 22.
   • Finalmente, el cliente envía un mensaje Finalizado encriptado, que contiene un hash y MAC sobre los mensajes de protocolo de enlace anteriores.
   • El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y el MAC. Si falla el descifrado o la verificación, se considera que el protocolo de enlace ha fallado y la conexión debe interrumpirse.
3. Finalmente, el servidor envía un ChangeCipherSpec, diciéndole al cliente: "Todo lo que le diga a partir de ahora será autenticado (y cifrado si se negoció el cifrado)".
   • El servidor envía su propio mensaje Finalizado cifrado.
   • El cliente realiza el mismo procedimiento de descifrado y verificación que el servidor realizó en el paso anterior.
4. Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de la aplicación está habilitado, con un tipo de contenido de 23. Los mensajes de la aplicación intercambiados entre el cliente y el servidor también se cifrarán exactamente como en su mensaje Finalizado.

Apretón de manos TLS reanudado

Las operaciones de clave pública (p. ej., RSA) son relativamente costosas en términos de potencia computacional. TLS proporciona un acceso directo seguro en el mecanismo de protocolo de enlace para evitar estas operaciones: sesiones reanudadas. Las sesiones reanudadas se implementan mediante ID de sesión o vales de sesión.

Además del beneficio de rendimiento, las sesiones reanudadas también se pueden usar 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 lo contrario sufriría un ataque de intermediario en el que un atacante podría interceptar el contenido de las conexiones de datos secundarias.

Apretón de manos TLS 1.3

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

Primero, el cliente envía un mensaje ClientHello al servidor que contiene una lista de cifrados admitidos en orden de preferencia del cliente y adivina qué algoritmo clave se utilizará para que pueda enviar una clave secreta para compartir si es necesario. Al adivinar qué algoritmo clave se utilizará, el servidor elimina un viaje de ida y vuelta. Después de recibir el ClientHello, el servidor envía un serverHello con su clave, un certificado, el conjunto de cifrado elegido y el mensaje terminado.

Después de que el cliente recibe el mensaje terminado del servidor, ahora se coordina con el servidor en qué suite de cifrado usar.

ID de sesión

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

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. En el mensaje se 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 elegido, un número aleatorio, un conjunto de cifrado y un método de compresión de las opciones que ofrece 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 usa esto para reconocer que se está realizando un apretón de manos reanudado. Si el servidor no reconoce la ID de sesión enviada por el cliente, envía un valor diferente para su ID de sesión. Esto le dice al cliente que no se realizará un apretón de manos reanudado. En este punto, tanto el cliente como el servidor tienen el "secreto maestro" y datos aleatorios para generar los datos clave que se utilizarán para esta conexión.
2. El servidor ahora envía un registro ChangeCipherSpec, esencialmente diciéndole al cliente: "Todo lo que le diga a partir de ahora estará encriptado". ChangeCipherSpec es en sí mismo un protocolo de nivel de registro y tiene el tipo 20 y no el 22.
   • Finalmente, el servidor envía un mensaje Finalizado encriptado, que contiene un hash y MAC sobre los mensajes de protocolo de enlace anteriores.
   • El cliente intentará descifrar el mensaje Finalizado del servidor y verificar el hash y el MAC. Si falla el descifrado o la verificación, se considera que el protocolo de enlace ha fallado y la conexión debe interrumpirse.
3. Finalmente, el cliente envía un ChangeCipherSpec, diciéndole al servidor: "Todo lo que le diga a partir de ahora será encriptado".
   • El cliente envía su propio mensaje Finalizado cifrado.
   • El servidor realiza el mismo procedimiento de descifrado y verificación que el cliente realizó en el paso anterior.
4. Fase de aplicación: en este punto, el "apretón de manos" está completo y el protocolo de la aplicación está habilitado, con un tipo de contenido de 23. Los mensajes de la aplicación intercambiados entre el cliente y el servidor también se cifrarán exactamente como en su mensaje Finalizado.

Boletos de sesión

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

Cuando se utilizan tickets de sesión, el servidor TLS almacena su estado específico de 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 vale de la sesión al servidor, y el servidor reanuda la sesión TLS según el estado específico de la sesión en el vale. El ticket de sesión es encriptado y autenticado por el servidor, y el servidor verifica su validez antes de usar su contenido.

Una debilidad particular de este método con OpenSSL es que siempre limita la seguridad de encriptación 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. Esto significa que la información de estado (el ticket de la sesión TLS) no está tan bien protegida como la propia sesión TLS. 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 útil de la aplicación, y no permite volver a teclear los vales de AES128-CBC-SHA256sesión de TLS sin restablecer el contexto de OpenSSL de toda la aplicación (que es poco común)., propenso a errores y, a menudo, requiere intervención administrativa manual).

Registro TLS

Este es el formato general de todos los registros TLS.

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

Versión heredadaEste campo identifica la versión principal y secundaria de TLS anterior a TLS 1.3 para el mensaje contenido. Para un mensaje ClientHello, no es necesario que sea la versión más alta admitida por el cliente. Para TLS 1.3 y versiones posteriores, debe establecerse en 0x0303 y la aplicación debe enviar versiones compatibles en un bloque de extensión de mensaje adicional.

LongitudLa longitud de los campos "mensaje(s) de protocolo", "MAC" y "relleno" combinados (es decir, q −5), que no supere los 2 bytes (16 KiB).Mensaje(s) de protocoloUno o más mensajes identificados por el campo Protocolo. Tenga en cuenta que este campo puede estar encriptado según el estado de la conexión.MAC y rellenoUn código de autenticación de mensaje calculado sobre el campo "mensaje(s) de protocolo", con material clave adicional incluido. Tenga en cuenta que este campo puede estar cifrado o no incluirse por completo, según el estado de la conexión.Ningún campo "MAC" o "relleno" puede estar presente al final de los registros TLS antes de que todos los parámetros y algoritmos de cifrado hayan sido negociados y aceptados y luego confirmados mediante el envío de un registro CipherStateChange (ver a continuación) para señalar que estos parámetros tendrán efecto en todos más registros enviados por el mismo par.

Protocolo de apretón de manos

La mayoría de los mensajes intercambiados durante la configuración de la sesión TLS se basan en este registro, a menos que ocurra un error o una advertencia y deba señalarse mediante un registro de protocolo de alerta (consulte a continuación), o el modo de cifrado de la sesión se modifique mediante otro registro (consulte el protocolo ChangeCipherSpec a continuación).

Tipo de mensajeEste campo identifica el tipo de mensaje de protocolo de enlace.

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

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

Protocolo de alerta

Este registro normalmente no debe enviarse durante intercambios normales de protocolos de enlace o aplicaciones. Sin embargo, este mensaje se puede enviar en cualquier momento durante el protocolo de enlace y hasta el cierre de la sesión. Si esto se usa para señalar un error fatal, la sesión se cerrará inmediatamente después de enviar este registro, por lo que este registro se usa para dar una razón para este cierre. Si el nivel de alerta se marca como una 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).

NivelEste 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 apretones de manos).El cierre normal de una sesión después de la finalización de la aplicación transportada debe 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 tiene una longitud o duración predeterminada que el destinatario de los datos protegidos puede esperar).

DescripciónEste campo identifica qué tipo de alerta se está enviando.

Protocolo ChangeCipherSpec

Tipo de protocolo CCSActualmente solo 1.

Protocolo de aplicación

LongitudLongitud de los datos de la aplicación (excluyendo el encabezado del protocolo e incluyendo el MAC y los tráileres de relleno)MAC32 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.RellenoLongitud variable; el último byte contiene la longitud del relleno.

Compatibilidad con servidores virtuales basados ​​en nombres

Desde el punto de vista del protocolo de aplicación, TLS pertenece a una capa inferior, aunque el modelo TCP/IP es demasiado tosco para mostrarlo. Esto significa que el protocolo de enlace TLS generalmente se realiza (excepto en el caso de STARTTLS) antes de que pueda iniciarse el protocolo de la aplicación. En la función de servidor virtual basada en nombre proporcionada por la capa de aplicación, todos los servidores virtuales cohospedados comparten el mismo certificado porque el servidor tiene que seleccionar y enviar un certificado inmediatamente después del mensaje ClientHello. Este es un gran problema en 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. Además de la selección imprecisa del nombre de host 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.
• Agregue cada nombre de host virtual en la extensión subjectAltName. El principal problema 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 a los clientes incluir una extensión de indicación de nombre de servidor (SNI) en el mensaje ClientHello extendido. Esta extensión le indica al servidor inmediatamente a qué nombre desea conectarse el cliente, para que el servidor pueda seleccionar el certificado adecuado para enviar a los clientes.

RFC 2817 también documenta un método para implementar alojamiento 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 es para implementar de forma segura HTTP sobre TLS dentro del esquema de URI "http" principal (que evita bifurcar el espacio de URI y reduce la cantidad de puertos utilizados), sin embargo, pocas implementaciones actualmente admiten esto.

Estándares

Estándares primarios

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

• RFC 8446: "Protocolo de seguridad de la capa de transporte (TLS) versión 1.3".

El estándar actual reemplaza estas versiones anteriores, que ahora se consideran obsoletas:

• RFC 2246: "El protocolo TLS versión 1.0".
• RFC 4346: "Protocolo de seguridad de la capa de transporte (TLS) versión 1.1".
• RFC 5246: "Protocolo de seguridad de la capa de transporte (TLS) versión 1.2".

Así como los nunca estandarizados SSL 2.0 y 3.0, que se consideran obsoletos:

• Borrador de Internet (1995), SSL Versión 2.0
• RFC 6101: "Protocolo de capa de sockets seguros (SSL) versión 3.0".

Extensiones

Posteriormente, otros RFC ampliaron 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 que el servidor y el cliente utilicen 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 memorándum aparecen solo con el propósito de documentar el hecho de que esos códigos de conjunto de cifrado ya han sido asignados.
• RFC 2817: "Actualización a TLS dentro de HTTP/1.1", explica cómo usar el mecanismo de actualización en HTTP/1.1 para iniciar Transport Layer Security (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 la seguridad de la capa de transporte". Especifica una extensión del servicio SMTP que permite que un servidor SMTP y un cliente utilicen la seguridad de la capa de transporte para proporcionar una comunicación privada y autenticada a través de Internet.
• RFC 3268: "Conjuntos de cifrado AES para TLS". Agrega conjuntos de cifrado 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)", agrega un mecanismo para negociar extensiones de protocolo durante la inicialización de la sesión y define algunas extensiones. Obsoleto por RFC 4366.
• RFC 3749: "Métodos de compresión del protocolo de seguridad de la capa de transporte", especifica el marco para los métodos de compresión y el método de compresión DEFLATE.
• RFC 3943: "Compresión del protocolo de seguridad de la capa de transporte (TLS) mediante Lempel-Ziv-Stac (LZS)".
• RFC 4132: "Adición de Camellia Cipher Suites a Transport Layer Security (TLS)".
• RFC 4162: "Adición de SEED Cipher Suites a Transport Layer Security (TLS)".
• RFC 4217: "Seguridad de FTP con TLS".
• RFC 4279: "Conjuntos de cifrado de claves previamente compartidas para la seguridad de la capa de transporte (TLS)", agrega tres conjuntos de nuevos conjuntos de cifrado para el protocolo TLS para admitir la autenticación basada en claves previamente compartidas.

Las extensiones de TLS 1.1 incluyen:

• RFC 4347: "Seguridad de la capa de transporte de datagramas" especifica una variante de TLS que funciona sobre protocolos de datagramas (como UDP).
• 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 cifrado 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 asignación de usuarios de TLS".
• RFC 4785: "Conjuntos de cifrado 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 cifrado TLS-SRP.
• RFC 5077: "Reanudación de la sesión de seguridad de la capa de transporte (TLS) sin estado del lado del servidor".
• RFC 5081: "Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS)", obsoleto por RFC 6091.

Las extensiones de TLS 1.2 incluyen:

• RFC 5288: "Conjuntos de cifrado AES Galois Counter Mode (GCM) para TLS".
• RFC 5289: "Suites de cifrado de curva elíptica TLS con SHA-256/384 y modo contador AES Galois (GCM)".
• 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: "Camellia Cipher Suites 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 capa de sockets seguros (SSL) versión 2.0".
• RFC 6209: "Adición de ARIA Cipher Suites a Transport Layer Security (TLS)".
• RFC 6347: "Seguridad de la capa de transporte de datagramas, versión 1.2".
• RFC 6367: "Adición de Camellia Cipher Suites a Transport Layer Security (TLS)".
• RFC 6460: "Perfil Suite B para seguridad de la capa de transporte (TLS)".
• RFC 6655: "Suites 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: "Suites de cifrado 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: "Encrypt-then-MAC para seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS)".
• RFC 7465: "Prohibición de suites de cifrado RC4".
• RFC 7507: "Valor de conjunto de cifrado de señalización de respaldo TLS (SCSV) para prevenir ataques de degradación de protocolo".
• RFC 7568: "En 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 del secreto maestro extendido".
• RFC 7685: "Una extensión de relleno ClientHello de Transport Layer Security (TLS)".

Las encapsulaciones de TLS incluyen:

• RFC 5216: "El protocolo de autenticación EAP-TLS"

RFC informativos

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