Seguridad de la capa de transporte

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

Como el protocolo DTLS conserva la semántica del transporte subyacente, la aplicación no sufre las demoras asociadas con los protocolos de flujo. Sin embargo, la aplicación debe lidiar con la reordenación de paquetes , la pérdida de datagramas y datos mayores que el tamaño de un paquete de red de datagramas . Debido a que DTLS usa UDP o SCTP en lugar de TCP, evita el problema de colapso de TCP ^[9 ] ^{[ 10 ] cuando se} usa para crear un túnel VPN.

La versión original de DTLS 1.0 de 2006 no era un documento independiente. Se presentó como una serie de deltas de TLS 1.1. ^{[ 7 ] : §4} De manera similar, la versión posterior de DTLS de 2012 es un delta de TLS 1.2. Se le asignó el número de versión de DTLS 1.2 para que coincidiera con su versión de TLS. Por último, DTLS 1.3 de 2022 es un delta de TLS 1.3. Al igual que las dos versiones anteriores, DTLS 1.3 tiene como objetivo proporcionar "garantías de seguridad equivalentes [a TLS 1.3] con la excepción de la protección de orden/no repetibilidad". ^{[ 11 ]}

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

Para protegerse contra ataques de "cosecha ahora, descifrado después" por parte de futuras computadoras cuánticas , se han implementado esquemas híbridos de acuerdo de clave post-cuántica para TLS 1.3. Estos combinan un intercambio ECDHE clásico con ML-KEM , el mecanismo de encapsulación de clave basado en retículo estandarizado por NIST como FIPS 203 en agosto de 2024. ^{[ 19 ]} El grupo de trabajo TLS de IETF define los grupos híbridos X25519MLKEM768, SecP256r1MLKEM768 y SecP384r1MLKEM1024 en un borrador de Internet, ^{[ 20 ]} junto con un marco general para el intercambio de claves híbridas en TLS 1.3 ^{[ 21 ]} y una especificación para el acuerdo de clave ML-KEM independiente (no híbrido). ^{[ 22 ]}

X25519MLKEM768 (y su predecesor X25519Kyber768) ha estado habilitado de forma predeterminada en Google Chrome desde la versión 131 (noviembre de 2024) ^{[ 23 ]} y en Firefox desde la versión 132, ^{[ 24 ]} y es compatible con implementaciones del lado del servidor, incluyendo OpenSSL 3.5, ^{[ 25 ]} BoringSSL y Cloudflare . ^{[ 26 ]}

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". ^{[ 45 ] [ 46 ] [ 47 ] [ 48 ]} La versión 1.0 de SSL nunca se publicó debido a graves fallos de seguridad en el protocolo. La versión 2.0, tras su publicación en febrero de 1995, pronto se descubrió que contenía varios fallos de seguridad y usabilidad. Utilizaba las mismas claves criptográficas para la autenticación y el cifrado de mensajes. Tenía una construcción MAC débil que utilizaba la función hash MD5 con un prefijo secreto, lo que la hacía vulnerable a ataques de extensión de longitud. Tampoco proporcionaba protección ni para el handshake de apertura ni para un cierre explícito del mensaje, lo que significaba que los ataques de intermediario podían pasar desapercibidos. Además, SSL 2.0 asumía un único servicio y un certificado de dominio fijo, lo que entraba en conflicto con la función ampliamente utilizada de alojamiento virtual en los servidores web, por lo que la mayoría de los sitios web se veían efectivamente impedidos de utilizar SSL.

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

SSL 2.0 fue declarado 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 bloques en SSL; RC4 , el único cifrado que no es de bloques compatible con SSL 3.0, también es factiblemente vulnerable tal como se usa en SSL 3.0. ^{[ 50 ]} SSL 3.0 fue declarado obsoleto en junio de 2015 por RFC 7568 .  

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

El Consejo PCI sugirió que las organizaciones migraran de TLS 1.0 a TLS 1.1 o superior antes del 30 de junio de 2018. ^{[ 52 ] [ 53 ]} En octubre de 2018, Apple , Google , Microsoft y Mozilla anunciaron conjuntamente que dejarían de usar TLS 1.0 y 1.1 en marzo de 2020. ^{[ 30 ]} TLS 1.0 y 1.1 fueron formalmente declarados obsoletos en RFC 8996 en marzo de 2021. 

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

• Se ha añadido protección contra ataques de encadenamiento de bloques de cifrado (CBC).
  • El vector de inicialización (IV) implícito fue reemplazado por un IV explícito.
  • Cambio en el manejo de errores de relleno .
• Soporte para el registro de parámetros en IANA . ^{[ 55 ]}

El soporte para las versiones 1.0 y 1.1 de TLS fue ampliamente descontinuado por los sitios web alrededor de 2020, ^{[ 56 ]} deshabilitando el acceso a las versiones de Firefox anteriores a la 24 y a los navegadores basados ​​en Chromium anteriores a la 29, ^{[ 57 ]} aunque se pueden aplicar correcciones de terceros a Netscape Navigator y versiones anteriores de Firefox para agregar soporte para TLS 1.2. ^{[ 58 ]}

TLS 1.2 se definió en el RFC 5246 en agosto de 2008. ^{[ 33 ]} Se basa en la especificación anterior TLS 1.1. Las principales diferencias incluyen: 

• La combinación MD5 y SHA-1 en la función pseudoaleatoria (PRF) fue reemplazada por SHA-256 , con la opción de usar PRF especificadas por el conjunto de cifrado .
• La combinación MD5 y SHA-1 en el hash del mensaje final se reemplazó por SHA-256, con la opción de usar algoritmos hash específicos del conjunto de cifrado. Sin embargo, el tamaño del hash en el mensaje final debe seguir siendo de al menos 96 bits . ^{[ 33 ] : §7.4.9}
• La combinación MD5 y SHA-1 en el elemento firmado digitalmente fue reemplazada por un único hash negociado durante el protocolo de enlace , que por defecto es SHA-1.
• Mejora en la capacidad del cliente y del servidor para especificar qué algoritmos de hash y firma aceptan.
• Ampliación de la compatibilidad con algoritmos de cifrado autenticados , utilizados principalmente para los modos Galois/Counter (GCM) y CCM del estándar de cifrado avanzado (AES).
• Se añadieron la definición de extensiones TLS y los conjuntos de cifrado AES. ^{[ 55 ]}

Todas las versiones de TLS se perfeccionaron aún más en el RFC 6176 en marzo de 2011, eliminando su retrocompatibilidad con SSL, de modo que las sesiones TLS nunca negocian el uso de Secure Sockets Layer (SSL) versión 2.0. A abril de 2025, no hay una fecha formal para la descontinuación de TLS 1.2. Las especificaciones para TLS 1.2 también se redefinieron mediante el documento de seguimiento de estándares RFC 8446 para mantenerlo lo más seguro posible; ahora debe considerarse un protocolo de conmutación por error, destinado únicamente a negociarse con clientes que no pueden usar TLS 1.3 (la definición original de RFC 5246 para TLS 1.2 está obsoleta desde entonces).   

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

• Separación de los algoritmos de acuerdo de claves y autenticación de los conjuntos de cifrado ^{[ 55 ] [ 6 ] : §11}
• Eliminar la compatibilidad con curvas elípticas con nombre, débiles y menos utilizadas.
• Se elimina la compatibilidad con las funciones hash criptográficas MD5 y SHA-224.
• Requerir firmas digitales incluso cuando se utiliza una configuración previa.
• Integración de HKDF y la propuesta semi-efímera de DH
• Reemplazar la reanudación con PSK y tickets
• Compatibilidad con protocolos de enlace 1- RTT y soporte inicial para 0- RTT.
• Exigir el secreto perfecto hacia adelante , mediante el uso de claves efímeras durante el acuerdo de claves (EC)DH.
• Se elimina la compatibilidad con muchas características inseguras u obsoletas, incluyendo compresión , renegociación, cifrados que no son AEAD , cifrados nulos , ^{[ 60 ]} intercambio de claves que no son PFS (entre los que se encuentran los intercambios de claves RSA estático y DH estático), grupos DHE personalizados , negociación del formato de punto EC, protocolo Change Cipher Spec, tiempo UNIX del mensaje Hello y la entrada AD del campo de longitud para los cifrados AEAD.
• Prohibir la negociación SSL o RC4 para garantizar la compatibilidad con versiones anteriores.
• Integración del uso del hash de sesión
• Se desaconseja el uso del número de versión de la capa de registro y se congela el número para mejorar la compatibilidad con versiones anteriores.
• Trasladar 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
• Se añaden los algoritmos de firma digital Ed25519 y Ed448.
• Agregar los protocolos de intercambio de claves x25519 y x448
• Se añade compatibilidad para enviar múltiples respuestas OCSP.
• Encriptación de todos los mensajes de handshake después de ServerHello, incluido el certificado del servidor.

Network Security Services (NSS), la biblioteca de criptografía desarrollada por Mozilla y utilizada por su navegador web Firefox , habilitó TLS 1.3 de forma predeterminada en febrero de 2017. ^{[ 61 ]} Posteriormente se añadió compatibilidad con TLS 1.3 —pero debido a problemas de compatibilidad para un pequeño número de usuarios, no se habilitó automáticamente ^{[ 62 ]} — 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 . ^{[ 63 ]}

Google Chrome estableció TLS 1.3 como versión predeterminada durante un breve período en 2017. Luego la eliminó como predeterminada, debido a la incompatibilidad con intermediarios como los proxies web de Blue Coat . ^{[ 64 ]}

La intolerancia de la nueva versión de TLS fue la osificación del protocolo ; los dispositivos intermedios habían osificado el parámetro de versión del protocolo. Como resultado, la versión 1.3 imita la imagen de la red de la versión 1.2. Este cambio se produjo muy tarde en el proceso de diseño, y solo se descubrió durante el despliegue del navegador. ^{[ 65 ]} El descubrimiento de esta intolerancia también llevó a que se abandonara la estrategia de negociación de versiones anterior, en la que se elegía la versión más coincidente, debido a niveles de osificación inviables. ^{[ 66 ]} El método de " engrasar " un punto de extensión, en el que un participante del protocolo declara soporte para extensiones inexistentes para garantizar que se toleren las extensiones no reconocidas pero existentes y así resistir la osificación, se diseñó originalmente para TLS, pero desde entonces se ha adoptado en otros lugares. ^{[ 66 ]}

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

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

EnSeptiembre de 2018, el popular proyecto OpenSSL lanzó la versión 1.1.1 de su biblioteca, en la que el soporte para TLS 1.3 fue "la principal novedad". ^{[ 74 ]}

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

TLS normalmente se basa en un conjunto de autoridades de certificación de terceros de confianza para establecer la autenticidad de los certificados. La confianza generalmente se fundamenta en una lista de certificados distribuidos con el software del agente de usuario , ^{[ 79 ]} y puede ser modificada por la parte que confía en ellos.

Según Netcraft , que monitoriza los certificados TLS activos, la autoridad de certificación (CA) líder del mercado ha sido Symantec desde el inicio de su encuesta (o VeriSign antes de que Symantec adquiriera la unidad de negocio de servicios de autenticación). En 2015, Symantec representaba algo 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 visitados, según el recuento de Netcraft. ^{[ 80 ]} En 2017, Symantec vendió su negocio de TLS/SSL a DigiCert. ^{[ 81 ]} En un informe actualizado, se mostró que IdenTrust , DigiCert y Sectigo son las tres principales autoridades de certificación en términos de cuota de mercado desde mayo de 2019. ^{[ 82 ]}

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

El 11 de abril de 2025, el CA/Browser Forum aprobó una votación que exigirá que la duración de todos los certificados TLS públicos se reduzca gradualmente a 47 días para 2029. ^{[ 85 ]} La votación fue propuesta por Apple. ^{[ 86 ]}

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 algoritmo de cifrado para usar al cifrar los datos (véase §  Cifrado ). Entre los métodos utilizados para el intercambio/acuerdo de claves se encuentran: claves públicas y privadas generadas con RSA (denominadas TLS_RSA en el protocolo de enlace TLS), Diffie-Hellman (TLS_DH), Diffie-Hellman efímero (TLS_DHE), Diffie-Hellman de curva elíptica (TLS_ECDH), Diffie-Hellman de curva elíptica efímero (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon), ^{[ 33 ]} clave precompartida (TLS_PSK) ^{[ 87 ]} y contraseña remota segura (TLS_SRP). ^{[ 88 ]}

Los métodos de intercambio de claves TLS_DH_anon y TLS_ECDH_anon no autentican al servidor ni al usuario y, por lo tanto, rara vez se utilizan, ya que son vulnerables a ataques de intermediario (man-in-the-middle) . 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, en la robustez de la seguridad proporcionada. En julio de 2013, Google anunció que dejaría de usar claves públicas de 1024 bits y que, en su lugar, usaría claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios, ya que la robustez del cifrado está directamente relacionada con el tamaño de la clave . ^{[ 89 ] [ 90 ]}

Notas

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

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 . ^{[ 110 ]}

Notas

A marzo de 2025 Las versiones más recientes de los principales navegadores web son compatibles con TLS 1.2 y 1.3 y las tienen habilitadas de forma predeterminada, con la excepción de IE 11. TLS 1.0 y 1.1 están deshabilitados de forma predeterminada en las versiones más recientes de los principales navegadores.

Las medidas de mitigación contra los ataques conocidos aún no son suficientes:

• Medidas de mitigación contra el ataque POODLE : algunos navegadores ya impiden el uso de SSL 3.0 como mecanismo de reserva; sin embargo, esta mitigación debe ser compatible no solo con los clientes, sino también con los servidores. Es necesario deshabilitar SSL 3.0, implementar la técnica de "división de registros anti-POODLE" o rechazar los cifrados CBC en SSL 3.0.
  • Google Chrome: completo (TLS_FALLBACK_SCSV está implementado desde la versión 33, la opción de recurrir a SSL 3.0 está deshabilitada desde la versión 39, SSL 3.0 está deshabilitado por defecto desde la versión 40. La compatibilidad con SSL 3.0 se eliminó desde la versión 44).
  • Mozilla Firefox: completo (la compatibilidad con SSL 3.0 se eliminó desde la versión 39. SSL 3.0 está deshabilitado por defecto y la opción de recurrir a SSL 3.0 está deshabilitada desde la versión 34 ; TLS_FALLBACK_SCSV se implementó desde la versión 35. En ESR, SSL 3.0 está deshabilitado por defecto y TLS_FALLBACK_SCSV se implementó desde ESR 31.3.0).
  • Internet Explorer: vulnerabilidad parcial (solo en la versión 11; SSL 3.0 está deshabilitado por defecto desde abril de 2015. Las versiones 10 y anteriores siguen siendo vulnerables a POODLE).
  • Opera : completa (TLS_FALLBACK_SCSV está implementado desde la versión 20, la "división de registros anti-POODLE", que solo es efectiva con la implementación del lado del cliente, está implementada desde la versión 25, SSL 3.0 está deshabilitado por defecto desde la versión 27. El soporte para SSL 3.0 se eliminará a partir de la versión 31).
  • Safari: completo (solo en OS X 10.8 y versiones posteriores e iOS 8, se deniega el cifrado CBC durante la conmutación a SSL 3.0, lo que implica el uso de RC4, que tampoco se recomienda. La compatibilidad con SSL 3.0 se elimina en OS X 10.11 y versiones posteriores e iOS 9).
• Medidas de 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 por defecto.
  • 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 tiene la prioridad de RC4 establecida en el nivel más bajo y también puede deshabilitarse RC4, excepto como alternativa, mediante la configuración del registro. Internet Explorer 11 Mobile 11 para Windows Phone 8.1 deshabilita RC4, excepto como alternativa si ningún otro algoritmo habilitado funciona. Edge [Legacy] e IE 11 deshabilitaron RC4 por completo en agosto de 2016.
• Medidas de mitigación contra el ataque FREAK :
  • El navegador de Android incluido en Android 4.0 y versiones anteriores sigue siendo vulnerable al ataque FREAK.
  • Internet Explorer 11 Mobile sigue siendo vulnerable al ataque FREAK.
  • Google Chrome, Internet Explorer (escritorio), Safari (escritorio y móvil) y Opera (móvil) cuentan con medidas de mitigación contra FREAK.
  • Mozilla Firefox en todas las plataformas y Google Chrome en Windows no se vieron afectados por FREAK.

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

• BoringSSL , una bifurcación de OpenSSL para Chrome/Chromium y Android, así como para 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 que utiliza un módulo criptográfico validado por FIPS.
• BSAFE SSL-J: una biblioteca TLS que proporciona tanto una API propietaria como 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 bien ICS, que ahora es compatible con TLS 1.3.
• GnuTLS : una implementación gratuita ( con licencia LGPL )
• Extensión de sockets seguros de Java (JSSE): la API de Java y la implementación del proveedor (denominada SunJSSE) ^{[ 114 ]}
• LibreSSL : una bifurcación de OpenSSL del proyecto OpenBSD.
• MatrixSSL : una implementación con doble licencia
• Mbed TLS (anteriormente PolarSSL): Una pequeña implementación de biblioteca SSL para dispositivos integrados diseñada para facilitar su uso.
• Servicios de seguridad de red : biblioteca de código abierto validada según FIPS 140.
• OpenSSL : una implementación gratuita (licencia BSD con algunas extensiones)
• Rustls , una implementación de TLS 1.3 escrita en el lenguaje de programación Rust para garantizar la seguridad de la memoria.
• Schannel : una implementación de SSL y TLS de Microsoft Windows como parte de su paquete.
• Transporte seguro : una implementación de SSL y TLS utilizada en OS X e iOS como parte de sus paquetes.
• wolfSSL (anteriormente CyaSSL): Biblioteca SSL/TLS integrada con un fuerte enfoque en la velocidad y el tamaño.

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

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

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 toda una pila de red y crear una VPN , como es el caso de OpenVPN y OpenConnect . Muchos proveedores ya han integrado las capacidades de cifrado y autenticación de TLS con la autorización. Además, desde finales de la década de 1990 se ha producido un desarrollo sustancial en la creación de tecnología cliente fuera de los navegadores web, para habilitar la compatibilidad con aplicaciones cliente/servidor. En comparación con las tecnologías VPN IPsec tradicionales , TLS presenta algunas ventajas inherentes en el paso de firewalls y NAT que facilitan la administración para grandes poblaciones de acceso remoto.

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

A continuación se enumeran los ataques más importantes contra TLS/SSL.

En febrero de 2015, la IETF publicó un RFC informativo ^{[ 117 ]} que resumía los diversos ataques conocidos contra TLS/SSL.

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

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

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. ^{[ 185 ]} Desde noviembre de 2013, Twitter ha proporcionado confidencialidad directa con TLS a los usuarios de su servicio. ^{[ 186 ]} 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 proporcionan confidencialidad directa a la mayoría de los navegadores web. ^{[ 111 ]}

La interceptación TLS (o HTTPS, si se aplica específicamente a ese protocolo) consiste en interceptar un flujo de datos cifrado para descifrarlo, leerlo y posiblemente manipularlo, para luego volver a cifrarlo y enviarlo nuevamente. Esto se realiza mediante un " proxy transparente ": el software de interceptación finaliza la conexión TLS entrante, inspecciona el texto plano HTTP y luego crea una nueva conexión TLS al destino. ^{[ 187 ]}

La interceptación TLS/HTTPS es utilizada por los operadores de red como medida de seguridad de la información para poder detectar y protegerse contra la intrusión de contenido malicioso en la red, como virus informáticos y otro malware . ^{[ 187 ]} Dicho contenido no podría detectarse de otro modo, siempre que esté protegido por cifrado, lo cual ocurre cada vez con mayor frecuencia como resultado del uso rutinario de HTTPS y otros protocolos seguros.

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

Al iniciarse la conexión, el registro encapsula un protocolo de control: el protocolo de enlace ( tipo de contenido 22). Este protocolo se utiliza para intercambiar toda la información necesaria para la transmisión de los datos de la aplicación mediante TLS. Define el formato de los mensajes y el orden de su intercambio, que pueden variar según las necesidades 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 están listas para transferir datos de la aplicación mediante TLS) o un mensaje de alerta (según se especifica más adelante).

Este es el formato general de todos los registros TLS.

Tipo de contenido : 8 bits

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

Versión anterior : 16 bits

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

Longitud : 16 bits ; Longitud < 2 ¹⁴

La longitud combinada de los campos de mensaje de protocolo , MAC y relleno . La longitud no debe exceder los ^2¹⁴ bytes (16 KiB).

Mensaje(s) de protocolo : variable

Uno o más mensajes identificados por el campo Protocolo. Tenga en cuenta que este campo puede estar cifrado dependiendo del estado de la conexión. La longitud (en bytes) de todos los mensajes se indica con la letra m .

Código de autenticación de mensajes  (MAC) : 16, 20 o 32 bytes (opcional)

Código de autenticación de mensajes calculado sobre el campo de mensajes del protocolo , con material de clave adicional incluido. 32 bytes para el HMAC basado en SHA-256 , 20 bytes para el HMAC basado en SHA-1 , 16 bytes para el HMAC basado en MD5 . Tenga en cuenta que este campo puede estar cifrado o no incluirse por completo, dependiendo del estado de la conexión. La longitud (en bytes) del MAC se indica con la letra q .

Relleno : variable (opcional)

El relleno solo se añade cuando es necesario.

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

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

• RFC 8446 – " El protocolo de seguridad de la capa de transporte (TLS) versión 1.3 " , ^{[ 6 ]} Estándar propuesto. 
• RFC 9147 – " El protocolo de seguridad de la capa de transporte de datagramas (DTLS) versión 1.3 " , ^{[ 11 ]} Estándar propuesto. 

Las normas actuales sustituyen a estas versiones anteriores:

• RFC 5246 – " El protocolo de seguridad de la capa de transporte (TLS) versión 1.2, " ^{[ 33 ]} Obsoleto. 
• RFC 6347 – " Seguridad de la capa de transporte de datagramas, versión 1.2, " ^{[ 8 ]} Obsoleto. 
• RFC 4346 – " El protocolo de seguridad de la capa de transporte (TLS) versión 1.1, " ^{[ 54 ]} Histórico. 
• RFC 2246 – " El protocolo TLS versión 1.0 " , ^{[ 197 ]} Histórico. 
• RFC 6101 – " El protocolo Secure Sockets Layer (SSL) versión 3.0 " , ^{[ 198 ]} Histórico. 
• Borrador de Internet (1995) : "El protocolo SSL"

Posteriormente, otros RFC extendieron (D)TLS.

Las extensiones de (D)TLS 1.3 incluyen:

• RFC 9367 – " Conjuntos de cifrado GOST para el protocolo de seguridad de la capa de transporte (TLS) versión 1.3, " ^{[ 95 ]} Informativo. 

Las extensiones de (D)TLS 1.2 incluyen:

• RFC 5288 – " Conjuntos de cifrado AES Galois Counter Mode (GCM) para TLS " , ^{[ 96 ]} Estándar propuesto. 
• RFC 5289 – " Conjuntos de cifrado de curva elíptica TLS con SHA-256/384 y modo de contador de Galois AES (GCM), " ^{[ 97 ]} Estándar propuesto. 
• RFC 5746 – " Extensión de la indicación de renegociación de la seguridad de la capa de transporte (TLS) " , ^{[ 119 ]} Norma propuesta. 
• RFC 5878 – " Extensiones de autorización de seguridad de la capa de transporte (TLS) " , ^{[ 199 ]} Experimental. 
• RFC 5932 – " Conjuntos de cifrado Camellia para TLS " , ^{[ 101 ]} Estándar propuesto. 
• RFC 6066 – " Extensiones de seguridad de la capa de transporte (TLS): definiciones de extensión " , ^{[ 196 ]} Norma propuesta. 
  Incluye la indicación del nombre del servidor y el etiquetado OCSP .
• RFC 6091 – " Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS) " , ^{[ 200 ]} Informativo. 
• RFC 6176 – " Prohibición de Secure Sockets Layer (SSL) versión 2.0 " , ^{[ 27 ]} Estándar propuesto. 
• RFC 6209 – " Adición de los conjuntos de cifrado ARIA a la seguridad de la capa de transporte (TLS), " ^{[ 102 ]} Informativo. 
• RFC 6347 – " Seguridad de la capa de transporte de datagramas, versión 1.2, " ^{[ 8 ]} Obsoleto. 
  Esta definición forma parte ahora de la especificación DTLS 1.3.
• RFC 6367 – " Adición de los conjuntos de cifrado Camellia a la seguridad de la capa de transporte (TLS), " ^{[ 100 ]} Informativo. 
• RFC 6460 – " Perfil Suite B para Transport Layer Security (TLS), " ^{[ 201 ]} Histórico. 
  La Agencia de Seguridad Nacional ha suspendido el soporte para la criptografía de Suite B.
• RFC 6655 – " Conjuntos de cifrado AES-CCM para seguridad de la capa de transporte (TLS), " ^{[ 98 ]} Estándar propuesto. 
• RFC 7027 – " Curvas de grupo cerebral de criptografía de curva elíptica (ECC) para seguridad de la capa de transporte (TLS), " ^{[ 202 ]} Informativo. 
• RFC 7251 – " Conjuntos de cifrado de criptografía de curva elíptica (ECC) AES-CCM para TLS " , ^{[ 99 ]} Informativo. 
• RFC 7301 – " Extensión de negociación del protocolo de capa de aplicación de seguridad de la capa de transporte (TLS) " , ^{[ 203 ]} Estándar propuesto. 
• RFC 7366 – " Encriptación y luego MAC para seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS) " , ^{[ 147 ]} Estándar propuesto. 
• RFC 7465 – " Prohibición de conjuntos de cifrado RC4 " , ^{[ 109 ]} Estándar propuesto. 
• RFC 7507 – " Valor de conjunto de cifrado de señalización de reserva TLS (SCSV) para prevenir ataques de degradación de protocolo " , ^{[ 204 ]} Obsoleto. 
• RFC 7568 – " Descontinuación de Secure Sockets Layer versión 3.0 " , ^{[ 28 ]} Estándar propuesto. 
• RFC 7627 – " Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension " , ^{[ 205 ]} Estándar propuesto. 
• RFC 7685 – " Una extensión de relleno ClientHello de Transport Layer Security (TLS) " , ^{[ 206 ]} Estándar propuesto. 
• RFC 8422 – " Conjuntos de cifrado de criptografía de curva elíptica (ECC) para versiones 1.2 y anteriores de Transport Layer Security (TLS) " , ^{[ 92 ]} Estándar propuesto. 
• RFC 9189 – " Conjuntos de cifrado GOST para el protocolo de seguridad de la capa de transporte (TLS) versión 1.2, " ^{[ 94 ]} Informativo. 

Las extensiones de (D)TLS 1.1 incluyen:

• RFC 4366 – " Extensiones de seguridad de la capa de transporte (TLS) " , ^{[ 207 ]} Obsoleto. 
  Describe tanto un conjunto de extensiones específicas como 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) " , ^{[ 208 ]} Obsoleto. 
• RFC 4680 – " Mensaje de protocolo de enlace TLS para datos suplementarios " , ^{[ 209 ]} Estándar propuesto. 
• RFC 4681 – “ Extensión de asignación de usuario TLS, “ ^{[ 210 ]} Estándar propuesto. 
• RFC 4785 – " Conjuntos de cifrado de clave precompartida (PSK) con cifrado nulo para seguridad de la capa de transporte (TLS) " , ^{[ 211 ]} Estándar propuesto. 
• RFC 5054 – " Uso del protocolo de contraseña remota segura (SRP) para la autenticación TLS " , ^{[ 212 ]} Informativo. 
  Define los conjuntos de cifrado TLS-SRP .
• RFC 5077 – " Reanudación de sesión de Transport Layer Security (TLS) sin estado del lado del servidor " , ^{[ 193 ]} Obsoleto. 
• RFC 5081 – " Uso de claves OpenPGP para la autenticación de seguridad de la capa de transporte (TLS) " , ^{[ 213 ]} Experimental. 
• RFC 5216 – " El protocolo de autenticación EAP -TLS " , ^{[ 214 ]} Estándar propuesto. 

Las extensiones a TLS 1.0 incluyen:

• RFC 2595 – " Uso de TLS con IMAP, POP3 y ACAP, " ^{[ 215 ]} Estándar propuesto. 
  Especifica una extensión de los servicios IMAP, POP3 y ACAP que permite al servidor y al cliente utilizar la seguridad de la capa de transporte para proporcionar una comunicación privada y autenticada a través de Internet.
• RFC 2712 – " Adición de conjuntos de cifrado Kerberos a la seguridad de la capa de transporte (TLS), " ^{[ 216 ]} Estándar propuesto. 
  Los conjuntos de cifrado de 40 bits definidos en este memorando aparecen únicamente con el propósito de documentar el hecho de que esos códigos de conjuntos de cifrado ya han sido asignados.
• RFC 2817 – " Actualización a TLS dentro de HTTP/1.1 " , ^{[ 2 ]} Estándar propuesto. 
  Explica cómo usar el mecanismo Upgrade en HTTP/1.1 para iniciar la seguridad de la capa de transporte (TLS) sobre 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 el puerto 80 en lugar de https: en el puerto 443).
• RFC 2818 – " HTTP sobre TLS, " ^{[ 217 ]} Obsoleto. 
  Distingue el tráfico seguro del tráfico no seguro mediante el uso de un "puerto de servidor" diferente.
• RFC 3207 – " Extensión del servicio SMTP para SMTP seguro sobre Transport Layer Security " , ^{[ 218 ]} Estándar propuesto. 
  Especifica una extensión del servicio SMTP que permite que un servidor y un cliente SMTP utilicen la seguridad de la capa de transporte para proporcionar una comunicación privada y autenticada a través de Internet.
• RFC 3268 – " Conjuntos de cifrado del Estándar de Cifrado Avanzado (AES) para la Seguridad de la Capa de Transporte (TLS) " , ^{[ 219 ]} Obsoleto. 
  Añade conjuntos de cifrado del Estándar de Cifrado Avanzado (AES) a los cifrados simétricos ya existentes.
• RFC 3546 – ​​" Extensiones de seguridad de la capa de transporte (TLS) " , ^{[ 220 ]} Obsoleto. 
  Agrega un mecanismo para negociar extensiones de protocolo durante la inicialización de la sesión y define algunas extensiones.
• RFC 3749 – " Métodos de compresión del protocolo de seguridad de la capa de transporte " , ^{[ 221 ]} Norma propuesta. 
  Especifica el marco de trabajo 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) " , ^{[ 222 ]} Informativo. 
• RFC 4132 – " Adición de conjuntos de cifrado Camellia a la seguridad de la capa de transporte (TLS), " ^{[ 223 ]} Obsoleto. 
• RFC 4162 – " Adición de conjuntos de cifrado SEED a la seguridad de la capa de transporte (TLS), " ^{[ 103 ]} Estándar propuesto. 
• RFC 4217 – " Protección de FTP con TLS " , ^{[ 224 ]} Norma propuesta. 
• RFC 4279 – " Conjuntos de cifrado de clave precompartida para la seguridad de la capa de transporte (TLS) " , ^{[ 225 ]} Estándar propuesto. 
  Agrega tres conjuntos de nuevos conjuntos de cifrado para el protocolo TLS para admitir la autenticación basada en claves precompartidas.

• RFC 7457 – " Resumen de los ataques conocidos contra Transport Layer Security (TLS) y Datagram TLS (DTLS) " , ^{[ 226 ]} Informativo. 
• RFC 9325 – " Recomendaciones para el uso seguro de Transport Layer Security (TLS) y Datagram Transport Layer Security (DTLS), " ^{[ 227 ]} Mejores prácticas actuales 195.