Seguridad de la capa de transporte

Los primeros esfuerzos de investigación hacia la seguridad de la capa de transporte incluyeron la interfaz de programación de aplicaciones (API, por su sigla en inglés) de Secure Network Programming (SNP), la que en 1993 exploró la posibilidad de tener una API de capa de transporte segura similar a los sockets Berkeley, para facilitar la retroadaptación de las aplicaciones de red preexistentes con medidas de seguridad.[7]

El protocolo SSL fue desarrollado originalmente por Netscape.[8] La versión 1.0 nunca se entregó públicamente; la versión 2.0 se presentó en febrero de 1995 pero "contenía una cantidad de fallas de seguridad que al final llevaron al diseño de la versión SSL 3.0".[9] Dicha versión, presentada en 1996, fue un rediseño completo del protocolo producido por Paul Kocher, quien trabajó con los ingenieros de Netscape Phil Karlton y Alan Freier. Las versiones más nuevas de SSL/TLS están basadas en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por la IETF como el histórico RFC 6101. En octubre de 2014, se detectó una nueva vulnerabilidad sobre el protocolo SSL en su versión 3.0, la Vulnerabilidad de Poodle.

TLS 1.0 fue definido en el RFC 2246 en enero de 1999 y es una actualización de SSL versión 3.0. Como dice el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dramáticas, pero son suficientemente significativas como para impedir la interoperabilidad entre TLS 1.0 y SSL 3.0". TLS 1.0 incluye una forma en la cual la implementación puede conectarse en SSL 3.0, debilitando la seguridad.

TLS 1.1 fue definido en el RFC 4346 en abril de 2006.[10] Es una actualización de TLS 1.0. Las diferencias más significativas incluyen:

• Agrega protección contra ataques de CBC.
  • El vector de inicialización (IV) implícito fue reemplazado por un IV explícito.
  • Cambio en el manejo de los errores de relleno.
• Soporte para el registro de parámetros de IANA.

TLS 1.2 fue definido originalmente en el RFC 5246 en agosto del 2008. Se basa en una especificación posterior de TLS 1.1. Las mayores diferencias son:

• la combinación MD5-SHA-1 en la función pseudoaleatoria (PRF) fue reemplazada por SHA-256, con la opción de usar las PRF especificadas en la cipher-suite.
• la combinación MD5-SHA-1 en el mensaje terminado fue reemplazada por SHA-256, sin la opción de usar algoritmos de hash específicos para la cipher-suite. Sin embargo, el tamaño del hash en el mensaje terminado es truncado a 96 bits.
• la combinación MD5-SHA-1 en el elemento digitalmente firmado fue reemplazada por un hash simple negociado durante el handshake, que por defecto es SHA-1.
• Mejoras en la habilidad de clientes y servidores para especificar qué algoritmos de hash y de firma van a aceptar.
• Expansión del soporte de cifras de cifrado autenticadas, usadas mayormente para modo Galois/Counter (GCM) y modo CCM del cifrado con Advanced Encryption Standard (AES).
• Se agregaron definición de Extensiones de TLS y de Ciphersuites de AES.

TLS 1.2 fue después redefinido en el RFC 6176 de marzo de 2011 redactando su retrocompatibilidad con SSL y TLS para que dichas sesiones jamás negocien el uso de SSL versión 2.0.

TLS 1.3 fue definido en el RFC 8446 en agosto de 2018. Está basado en la anterior especificación TLS 1.2. Las principales diferencias con TLS 1.2 incluyen:

• Un modo 0-RTT
• Retiro de la hora GMT.
• Fusiona soporte de ECC del RFC 4492 pero sin curvas explícitas.
• Retira el campo de longitud innecesaria de la entrada de AD a cifras AEAD.
• Cambiar el nombre de {Cliente, Servidor} KeyExchange a {Cliente, Servidor} KeyShare
• Añade un HelloRetryRequest explícita para rechazar el del cliente
• Handshake revisado a fin de proporcionar el modo 1-RTT.
• Retiro de grupos DHE personalizados.
• Eliminado el soporte para la compresión.
• Eliminado el soporte para el intercambio de claves RSA estática y DH.
• Eliminado el soporte para sistemas de cifrado no AEAD.

Antes de que un cliente y el servidor pueden empezar a intercambiar información protegida por TLS, deben intercambiar en forma segura o acordar una clave de cifrado y una clave para usar cuando se cifren los datos (ver Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves son: las claves públicas y privadas generadas con RSA (denotado TLS_RSA en el protocolo de handshake TLS), Diffie-Hellman (llamado TLS_DH), Diffie-Hellman efímero (denotado TLS_DHE), Diffie-Hellman de Curva Elíptica (denotado TLS_ECDH), Diffie-Hellman de Curva Elíptica efímero (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon),[3] y PSK (TLS_PSK).[12]

El método de acuerdo de claves TLS_DH_anon no verifica el servidor o el usuario y por lo tanto rara vez se utiliza puesto que es vulnerable a un ataque de suplantación de identidad. Solo TLS_DHE y TLS_ECDHE proporcionan secreto-perfecto-hacia-adelante.

Los certificados de clave pública que se utilizan durante el intercambio/acuerdo también varían en el tamaño de las claves de cifrado públicas/privadas utilizadas durante el intercambio y, por tanto, en la solidez de la seguridad que proveen. En julio de 2013, Google anunció que dejaría de utilizar claves públicas 1024 bits y cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios.[13]

Notas

Se utiliza código de autenticación de mensaje (MAC, por message authentication code en inglés) para asegurar la integridad de los datos. HMAC se usa para el modo CBC de cifrado de bloques y cifrado de streams. AEAD es usado para el cifrado autenticado tales como los modos GCM y CCM.

Uno de los usos más importantes es junto a HTTP para formar HTTPS. HTTPS es usado para asegurar páginas World Wide Web para aplicaciones de comercio electrónico, utilizando certificados de clave pública para verificar la identidad de los extremos.

Notas

Todos los navegadores importantes soportan TLS:

Notas

SSL y TLS han sido implementados ampliamente en varios proyectos de software abierto y libre. Los programadores pueden usar las librerías PolarSSL, CyaSSL, OpenSSL, MatrixSSL, NSS o GnuTLS para tener funcionalidad SSL/TLS.

• Microsoft Windows incluye una implementación de SSL y TLS como parte de su paquete Secure Channel.
• OS X incluye una implementación de SSL y TLS como parte de su paquete Secure Transport.
• Los programadores de Delphi pueden usar una librería llamada Indy.
• OpenSSL es una implementación libre. Tiene una licencia BSD con algunas extensiones.
• GnuTLS es una implementación libre, con licencia LGPL.
• Zodiac TLS/SSL: es una implementación para Smalltalk con licencia MIT.
• cryptlib es librería criptográfica potable de software abierto (que incluye una implementación de SSL/TLS).
• JSSE: una implementación Java incluida en el Java Runtime Environment que soporta TLS 1.1 y 1.2 desde Java 7, aunque está por defecto deshabilitada para el cliente y habilitada en el servidor.
• MatrixSSL: una implementación con licencia dual.
• Network Security Services (NSS): es una librería open source validada para FIPS 140.
• PolarSSL es una implementación SSL/TLS muy pequeña para dispositivos embebidos que está diseñada para uso fácil.
• CyaSSL es una librería SSL/TLS embebida con fuerte foco en velocidad y tamaño.

Un ensayo presentado en la conferencia ACM 2012 de seguridad de computadores y comunicaciones[42] mostró que muchas aplicaciones utilizaban estas librerías incorrectamente, llevando a vulnerabilidad. Los autores hacían notar que "la causa principal de la mayoría de estas vulnerabilidad es el terrible diseño de las APIs para las librerías subyacentes. En vez de expresar propiedades de seguridad alto nivel para túneles de red tales como confidencialidad y autenticación, estas API exponen detalles de bajo nivel del protocolo SSL a los desarrolladores de aplicaciones. Como consecuencia, los desarrolladores frecuentemente usan las API de SSL incorrectamente, malinterpretando y malentendiendo los posibles parámetros, opciones, efectos colaterales y valores de retorno".

Otra aplicación con creciente uso de TLS es SMTP. TLS es también el método estándar para proteger la señalización de aplicaciones con Session Initiation Protocol (SIP). TLS se puede utilizar para proveer autenticación y cifrado a la señalización asociada con VoIP y otras aplicaciones basadas en SIP.

Aunque un número creciente de productos clientes y servidores pueden proporcionar SSL de forma nativa, muchos aún no lo permiten. En estos casos, un usuario podría querer usar una aplicación SSL independiente como Stunnel para proporcionar cifrado. No obstante, el Internet Engineering Task Force recomendó en 1997 que los protocolos de aplicación ofrecieran una forma de actualizar a TLS a partir de una conexión sin cifrado (plaintext), en vez de usar un puerto diferente para cifrar las comunicaciones – esto evitaría el uso de envolturas (wrappers) como Stunnel.

SSL también puede ser usado para tunelizar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN.

SSL 2.0 tiene una variedad de fallas:[43]

• Claves criptográficas idénticas se utilizan para la autenticación de mensajes y el cifrado.
• SSL 2.0 tiene una construcción MAC débil que utiliza la función hash MD5 con un prefijo secreto, por lo que es vulnerable a los ataques de extensión de longitud.
• SSL 2.0 no tiene ningún tipo de protección para el handshake, es decir, un ataque man-in-the-middle que se rebaje a este protocolo puede pasar desapercibido.
• SSL 2.0 utiliza el cierre de la conexión TCP para indicar el final de los datos. Esto significa que los ataques de truncamiento son posibles: el atacante simplemente forja un TCP FIN, dejando el receptor inconsciente de un fin ilegítimo de mensaje de datos (SSL 3.0 soluciona este problema al tener una alerta de cierre explícita).
• SSL 2.0 asume un solo servicio y un certificado de dominio fijo, que choca con una función estándar de hosting virtual en los servidores Web. Esto significa que la mayoría de los sitios web están prácticamente afectados por el uso de SSL.

SSL 2.0 está desactivado por defecto, a partir de: Internet Explorer 7,[44] Mozilla Firefox 2,[45] Opera 9.5,[46] y Safari. Después de que se envía un "ClientHello" TLS, si Mozilla Firefox comprueba que el servidor no puede completar el handshake, intentará volver a caer a la utilización de SSL 3.0 con un SSL 3.0 "ClientHello" en formato SSL 2.0 para maximizar la probabilidad de éxito del handshake con los servidores más antiguos.[47] Permitir SSL 2.0 (y sistemas de cifrado débiles de 40 y 56 bits), ha sido completamente eliminado de Opera desde la versión 10[48][49]

SSL 3.0 mejoró SSL 2.0 mediante la adición de cifrado SHA-1 y soporte para autenticación de certificados.

Desde el punto de vista de seguridad, SSL 3.0 debería considerarse menos deseable que TLS 1.0. Las suites de cifrado de SSL 3.0 tienen un proceso de derivación de claves débiles, la mitad de la llave maestra que se establece es totalmente dependiente de la función hash MD5, que no es resistente a los choques y, por lo tanto, no es considerado seguro. Bajo TLS 1.0, la llave maestra que se establece depende tanto MD5 y SHA-1 por lo que su proceso de derivación no está actualmente considerado débil. Es por esta razón que las implementaciones SSL 3.0 no pueden ser validados bajo FIPS 140-2.[50]

Hay algunos ataques contra la implementación en lugar del propio protocolo:[51] En las implementaciones anteriores, algunas entidades emisoras[52] no establecieron explícitamente basicConstraintsCA=False para los nodos hoja. Como resultado, estos nodos hoja podían firmar certificados piratas. Además, algunos programas de (incluyendo IE6 y Konqueror) no comprobó este campo para nada. Esto puede ser explotado en ataques man-in-the-middle a todas las posibles conexiones SSL. Algunas implementaciones (incluyendo versiones anteriores de la API de cifrado de Microsoft, Network Security Services y GnuTLS) dejan de leer los caracteres que siguen al carácter nulo en el campo del nombre del certificado, lo que puede ser explotado para engañar al cliente en la lectura del certificado como si fuera originado en el sitio auténtico. (Por ejemplo, PayPal.com\0.badguy.com sería confundido como proveniente del sitio PayPal.com en lugar de badguy.com). Los navegadores implementaron mecanismos de degradación del protocolo a una versión anterior en SSL/TLS por razones de compatibilidad. La protección ofrecida por los protocolos SSL/TLS contra un downgrade a una versión anterior de un ataque man-in-the-middle activo puede ser inutilizados por tales mecanismos.[53]

TLS tiene una variedad de medidas de seguridad:

• Protección contra una degradación del protocolo a una versión anterior (menos segura) o un conjunto de cifrado más débil.
• Numeración de los registros de aplicación posteriores con un número de secuencia y el uso de este número de secuencia en los códigos de autenticación de mensajes (MAC).
• Usando un resumen de mensaje mejorado con una clave (por lo que sólo una llave-sostenedor puede comprobar el MAC). La construcción HMAC utilizado por la mayoría de las suites de cifrado TLS se especifica en el RFC 2104 (SSL 3.0 utiliza un MAC basado en hash diferente).
• El mensaje que finaliza el protocolo de enlace ("Finalizar") envía un hash de todos los mensajes intercambiados handshake vistos por ambas partes.
• La función pseudoaleatoria divide los datos de entrada en un medio y procesa cada uno con un algoritmo de hash diferente (MD5 y SHA-1), luego les hace OR exclusivo juntos para crear el MAC. Esto proporciona protección incluso si uno de estos algoritmos resulta ser vulnerable.

Los ataques más significativos se mencionan más abajo:

Una vulnerabilidad del procedimiento en el cual la renegociación fue descubierto en agosto de 2009, que puede conducir a ataques de inyección de texto plano contra SSL 3.0 y todas las versiones actuales de TLS. Por ejemplo, permite a un atacante que puede secuestrar una conexión https para empalmar sus propias peticiones en el inicio de la conversación que el cliente tiene con el servidor web. El atacante no puede realmente descifrar la comunicación cliente-servidor, por lo que es diferente de un típico ataque man-in-the-middle. Una solución a corto plazo es que los servidores de Internet dejen de permitir la renegociación, que normalmente no requerirá otros cambios a menos que se utilice la autenticación de certificados de cliente. Para corregir la vulnerabilidad, una extensión de la indicación de renegociación fue propuesta para TLS. Se requerirá que el cliente y el servidor incluyan y verifiquen información acerca de los handshake anteriores en cualquier renegociación de handshake.[54] Esta extensión se ha convertido en una norma propuesta y se le ha asignado el número de RFC 5746. El RFC ha sido implementado por varias bibliotecas.[55][56][57]

Hay modificaciones a los protocolos originales, como False Start[58] (aprobada y habilitada por Google Chrome[59]) o Snap Start, en las que se ha reportado que han introducido limitaciones a los ataques de reversión de versiones para TLS[60] o para permitir que las modificaciones de la lista de conjunto de cifrado enviada por el cliente al servidor (un atacante puede ser capaz de influir en la selección de la suite de cifrado en un intento de rebajar la intensidad de juego de cifrado, ya sea para usar un algoritmo de cifrado simétrico más débil o de un intercambio de clave más débil[61]). Se ha demostrado en la conferencia sobre seguridad informática y de comunicaciones de la Association for Computing Machinery (ACM) que la extensión False Start está en riesgo bajo ciertas circunstancias, lo que podría permitir a un atacante recuperar las claves de cifrado en línea y acceder a los datos cifrados.[62]

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") usando un applet Java para violar restricciones de políticas de mismo origen, por una vulnerabilidad de CBC ampliamente conocida de TLS 1.0.[51][52] Exploits prácticos de esta vulnerabilidad no se conocían, la cual fue descubierta originalmente por Phillip Rogaway[63] en 2002.

Mozilla actualizó las versiones de desarrollo de sus librerías NSS para mitigar ataques de tipo BEAST. NSS es utilizado por Mozilla Firefox y por Google Chrome para su implementación de SSL. Algunos servidores web que tienen una implementación quebrada de la especificación SSL puede que dejen de funcionar como resultado de esto.[64]

Microsoft emitió el boletín de seguridad MS12-006 el 12 de enero de 2012, que corrigió la vulnerabilidad BEAST al cambiar la forma en que el componente de Windows Secure Channel (SChannel) transmite los paquetes cifrados.[65] Por su parte, Apple habilitó por defecto la protección contra BEAST en la versión OS X 10.9 Mavericks.[66]

El ataque BEAST también se puede prevenir eliminando todos los cifrados CBC de la lista de cifrados permitidos, dejando solamente el cifrado RC4, que es ampliamente soportado por la mayoría de los sitios web.[67][68] Los usuarios de Windows 7 y de Windows Server 2008 R2 pueden permitir el uso de TLS 1.1 y 1.2, pero esta contramedida fallará si no es soportado también por el otro extremo de la conexión, y caerá a TLS 1.0.

Los autores del ataque BEAST también son los creadores del ataque CRIME, que usa compresión de datos para adivinar.[69][70] Cuando se utiliza para recuperar el contenido de la cookie de autenticación secreta, permite a un atacante realizar un secuestro de sesión en una sesión web autenticada.

Las versiones anteriores de TLS eran vulnerables frente al ataque de relleno de oráculo descubierto en 2002. Una nueva variante, llamada Ataque Trece con suerte, fue publicada en 2013. Hasta febrero de 2013, los implementadores de TLS estaban todavía trabajando en el desarrollo de soluciones para la protección contra esta forma de ataque.

Una solución definitiva fue lanzada como la extensión Encrypt-then-MAC para TLS lanzado como RFC 7366.[71]

El 14 de octubre de 2014, investigadores de Google publicaron una vulnerabilidad en el diseño de SSL 3.0, lo que hace que el modo CBC de operación con SSL 3.0 sea vulnerable al ataque de relleno (CVE-2014-3566). Ellos llamaron a este ataque POODLE (en inglés, Padding Oracle On Downgraded Legacy Encryption o Relleno de oráculo en Degradación a Cifrado Obsoleto). En promedio, los atacantes solo necesitan hacer 256 peticiones SSL 3.0 para revelar un byte de mensaje cifrado.[28][72]

Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayoría de los clientes y servidores admite TLS 1.0 y superiores, todos los principales navegadores rebajan voluntariamente a SSL 3.0 si los handshake con las nuevas versiones de TLS fallan a menos que proporcionan la opción para un usuario o administrador para deshabilitar SSL 3.0 y el usuario o el administrador lo haga. Por lo tanto, el hombre-en-el-medio primero debe llevar a cabo un ataque de rollback y luego aprovechar esta vulnerabilidad.[28][72]

En general, la degradación de la seguridad elegante por el bien de la interoperabilidad es difícil llevar a cabo de una manera que no pueda ser explotada. Este es un reto especialmente en los dominios donde la fragmentación es alta.[73]

A pesar de ataques existentes sobre RC4 que lo rompen, las suites de cifrado basadas en RC4 en SSL y TLS fueron consideradas seguros en un momento debido a la forma en que el sistema de cifrado se utilizaba en estos protocolos derrotaba a los ataques que rompían RC4, hasta que nuevos ataques divulgados en marzo de 2013 permitían que RC4 en TLS fuera quebrado completamente. En 2011 se recomendaba usar la suite RC4 como una solución alternativa para el ataque BEAST.[74] En 2013 una vulnerabilidad fue descubierta en RC4 sugiriendo que no era una buena solución para BEAST.[27] Un caso de un ataque fue propuesto por Alfardan, Bernstein, Paterson, Poettering y Schuldt que utilizaba nuevos sesgos estadísticos descubiertos en la tabla de clave RC4[75] para recuperar partes del texto en claro con un gran número de cifrados TLS.[76][77] Un ataque de sesgo de doble byte en RC4 en TLS y SSL que requiere 13 × 220 cifrados para romper RC4 se dio a conocer el 8 de julio de 2013, y fue descrito como "viable" en la presentación de acompañamiento en el 22ndo Simposio USENIX de Seguridad el 15 de agosto de 2013.[78][79]

Sin embargo, muchos navegadores modernos han sido diseñados para derrotar los ataques BEAST (excepto Safari para Mac OS X 10.7 o versiones anteriores, para iOS 6 o anterior, y para Windows; ver navegadores). Como resultado, RC4 ya no es la mejor opción para TLS 1.0. Los sistemas de cifrado CBC que se vieron afectados por el ataque BEAST en el pasado se están convirtiendo en una opción más popular para la protección.[23]

Microsoft recomienda deshabilitar RC4 cuando sea posible.[80]

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

Publicado en julio de 2013,[82] el ataque provoca servicios web como Gmail y Hotmail que muestren una página que informa al usuario de que han salido correctamente del servicio, al tiempo que garantiza que el navegador del usuario mantiene la autorización con el servicio, lo que permite a un atacante tener el acceso para tomar el control de la cuenta que ha iniciado sesión en el usuario. El ataque no se basa en la instalación de malware en el ordenador de la víctima; los atacantes solo necesitan ponerse entre la víctima y el servidor web (por ejemplo, mediante la creación de un punto de acceso inalámbrico rebelde).[81] Esta vulnerabilidad también requiere acceso a la computadora de la víctima.

El fallo Heartbleed es una grave vulnerabilidad en la popular librería de software criptográfica OpenSSL, que afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad permite el robo de la información protegida, en condiciones normales, por el cifrado SSL / TLS que se utiliza para asegurar las cargas de datos. SSL / TLS proporciona seguridad de las comunicaciones y la privacidad a través de Internet para aplicaciones como web, correo electrónico, mensajería instantánea (IM) y algunas redes privadas virtuales (VPN).[83]

El fallo Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves secretas utilizadas para identificar los proveedores de servicios y para cifrar el tráfico, los nombres y las contraseñas de los usuarios y el contenido real. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y de los usuarios y suplantar servicios y a los usuarios.[84]

A diciembre de 2014, Trustworthy Internet Movement estima que la proporción de sitios web que son vulnerable a ataques TLS.[26]

Forward secrecy 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án comprometidas si una de las claves privadas se ve comprometida en el futuro.[85] Sin forward secrecy, si la clave privada del servidor fuera conocida, no sólo se verán comprometidas todas las sesiones cifradas-TLS futuras mediante ese certificado del servidor, sino también las sesiones anteriores que lo utilizaban (siempre por supuesto que estas sesiones pasadas fueran interceptadas y almacenadas en el momento de la transmisión).[86] Una implementación de TLS puede proporcionar forward secrecy al exigir el uso de intercambio de claves Diffie-Hellman efímeras para establecer claves de sesión, y algunas implementaciones TLS notables lo hacen exclusivamente: por ejemplo, Gmail y otros servicios de Google que utilizan HTTPS OpenSSL.[87] Sin embargo, muchos clientes y servidores que soportan TLS (incluidos los navegadores y servidores web) no están configurados para aplicar esas restricciones.[88][89] En la práctica, a menos que un servicio web utilice Diffie-Hellman para implementar forward secrecy, todo el tráfico web cifrado hacia y desde ese servicio puede ser descifrado por un tercero si obtiene la clave maestra del servidor (privado); por ejemplo, por medio de una orden judicial.[90]

Incluso cuando se implementa el intercambio de claves Diffie-Hellman, los mecanismos de gestión de sesión en el servidor pueden afectar el forward secrecy. El uso de tickets de sesión TLS (una extensión TLS) hace que la sesión se deba proteger por AES128-CBC-SHA256 independientemente de cualquier otro parámetro TLS negociados, incluyendo a los conjuntos de cifrado de forward secrecy, y las llaves de los tickets de sesión de larga duración TLS estropean el intento de implementar forward secrecy.[91][92][93]

Desde finales de 2011, Google ha proporcionado forward secrecy con TLS por omisión para los usuarios de su servicio de Gmail, junto con Google Docs y búsqueda cifrada, entre otros servicios.[94] Desde noviembre de 2013, Twitter ha proporcionado forward secrecy con TLS para los usuarios de su servicio.[95] A diciembre de 2014, el 20,0% de los sitios web habilitados para TLS están configurados para utilizar conjuntos de cifrado que proporcionan forward secrecy a los navegadores web.[26]

Algunos expertos recomiendan evitar Triple-DES CBC. Debido a que RC4 y Triple-DES son los últimos cifrados soportados en las bibliotecas SSL/TLS de Windows XP, hace que sea difícil soportar SSL para programas que utilicen esta biblioteca en Windows XP. Por ejemplo en el caso de Internet Explorer para Windows XP.[23]

Una forma de detectar y bloquear muchos tipos de ataques MITM es "fijar el certificado", a veces llamado "fijación SSL".[96]

Un cliente que hace fijación de certificado agrega un paso adicional para el protocolo SSL o protocolo TLS habitual: Después de obtener el certificado del servidor en la forma estándar, el cliente comprueba el certificado del servidor con los datos de confianza para validación. Normalmente los datos de validación de confianza se incluye con la aplicación, en la forma de una copia de confianza de dicho certificado, o un hash de confianza o huella digital del certificado o la clave pública del certificado. Por ejemplo, el Chromium y Google Chrome incluyen datos de validación para el certificado *.google.com que detecta certificados fraudulentos en 2011. Desde entonces, Mozilla ha introducido fijación de certificados públicos en su navegador Firefox.[97]

En otros sistemas que el cliente espera que la primera vez que obtenga el certificado de un servidor es de confianza y la almacena; durante las sesiones posteriores con ese servidor, el cliente comprueba el certificado del servidor contra el certificado almacenado para protegerse de los ataques MITM posteriores.

El Proyecto Perspectivas[98] opera notarios de red que los clientes pueden usar para detectar si el certificado de un sitio ha cambiado. Por su naturaleza, los ataques man-in-the-middle colocan al atacante entre el destino y un solo objetivo específico. Como tal, Perspectivas advertirían al objetivo de que el certificado entregado al navegador web no coincide con el certificado visto desde otras perspectivas - las perspectivas de otros usuarios en diferentes momentos y lugares. El uso de notarios de red desde una multitud de perspectivas hace posible que un objetivo detecte un ataque incluso si un certificado parece ser completamente válido.

Cuando se inicia la conexión, el registro encapsula un protocolo de "control"- el protocolo de mensajería de handshake (contenido de tipo 22). Este protocolo se utiliza para el intercambio de toda la información requerida por las dos partes para el intercambio de los datos de las aplicaciones reales por TLS. En él se definen los mensajes de formato o que contengan esta información y el orden de su intercambio. Estos pueden variar en función de las demandas del cliente y del servidor, es decir, existen varios procedimientos posibles para establecer la conexión. Este intercambio inicial resulta en una conexión exitosa TLS (ambas partes listas para transferir datos de la aplicación con TLS) o un mensaje de alerta (como se especifica más adelante).

A continuación, un ejemplo simple de conexión, que ilustra un handshake en el que el servidor (pero no el cliente) es autenticado por su certificado:

1. Fase de negociación:
   • Un cliente envía un mensaje ClientHello especificando la versión más alta de protocolo TLS que soporta, un número al azar, una lista de conjuntos de cifrado sugeridas y métodos de compresión sugeridos. Si el cliente está intentando realizar un handshake reanudado, puede enviar un ID de sesión.
   • El servidor responde con un mensaje ServerHello, que contiene la versión del protocolo elegido, un número aleatorio, CipherSuite y método de compresión de las opciones ofrecidas por el cliente. Para confirmar o permitir handshake reanudado el servidor puede enviar un ID de sesión. La versión del protocolo elegido debe ser el más alto que tanto el soporte de cliente y servidor. Por ejemplo, si el cliente es compatible con la versión 1.1 y el servidor es compatible con la versión 1.2, la versión 1.1 se debe seleccionar; 1.0 no se debe seleccionar.
   • El servidor envía su mensaje de certificado (dependiendo de la suite de cifrado seleccionado, esto puede ser omitido por el servidor).[99]
   • El servidor envía su mensaje ServerKeyExchange (en función del conjunto de cifrado seleccionado, esto puede ser omitido por el servidor). Este mensaje se envía a todos los conjuntos de cifrado DHE y DH_anon.[3]
   • El servidor envía un mensaje ServerHelloDone, lo que indica que terminó con la negociación del handshake.
   • El cliente responde con un mensaje ClientKeyExchange, que puede contener una PreMasterSecret, la clave pública, o nada. (Una vez más, esto depende de la cifra seleccionada.) Esta PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
   • El cliente y el servidor a continuación utilizan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado el "secreto principal" (master secret). Todos los demás datos clave para esta conexión se deriva de este secreto principal (y los valores aleatorios generados tanto por cliente y por servidor), que se pasan a través de una función pseudoaleatoria cuidadosamente diseñado.
2. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciendo al servidor, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si los parámetros de cifrado estaban presentes en el certificado del servidor)." El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro con el tipo de contenido 20.
   • Por último, el cliente envía un mensaje autenticado y cifrado de Finished (terminado), que contiene un hash y MAC sobre los mensajes de handshake anteriores.
   • El servidor intentará descifrar el mensaje Finished del cliente y verificar el hash y MAC. Si el descifrado o verificación falla, el handshake se considera que ha fracasado y la conexión debe ser derribada.
3. Por último, el servidor envía un ChangeCipherSpec, diciéndole al cliente, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrado, si el cifrado se negoció)."
   • El servidor envía su mensaje Finished autenticado y cifrado.
   • El cliente realiza el mismo descifrado y verificación.
4. Fase de aplicación: en este punto, el "handshake" está completado y el protocolo de aplicación está activada, con el tipo de contenido de 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también serán autenticados y opcionalmente cifrados exactamente igual que en su mensaje final. De lo contrario, el tipo de contenido contestará 25 y el cliente no va será autenticado.

El siguiente ejemplo completo muestra un cliente siendo autenticado (además del servidor como el de más arriba) a través de TLS mediante certificados intercambiados entre ambos interlocutores.

1. Fase de Negociación:
   • Un cliente envía un mensaje ClientHello especificando la versión más alta de protocolo TLS que soporta, un número al azar, 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 elegida del protocolo, un número al azar, una suite de cifrado y el método de compresión de las opciones ofrecidas por el cliente. El servidor también puede enviar un identificador de sesión como parte del mensaje para realizar un handshake reanudado.
   • El servidor envía su mensaje de certificados (dependiendo de la suite de cifrado seleccionado, esto puede ser omitido por el servidor).[99]
   • El servidor envía su mensaje ServerKeyExchange (en función del conjunto de cifrado seleccionado, esto puede ser omitido por el servidor). Este mensaje se envía a todos los conjuntos de cifrado DHE y DH_anon.[3]
   • El servidor solicita un certificado desde el cliente, de modo que la conexión pueda ser mutuamente autenticada, utilizando un mensaje CertificateRequest.
   • El servidor envía un mensaje ServerHelloDone, lo que indica que terminó con la negociación handshake.
   • El cliente responde con un mensaje de certificado, que contiene el certificado del cliente.
   • El cliente envía un mensaje ClientKeyExchange, que puede contener un PreMasterSecret, clave pública, o nada. (Una vez más, esto depende del cifrado seleccionado.) Esta PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
   • El cliente envía un mensaje CertificateVerify, que es una firma en los mensajes de reconocimiento anteriores utilizando la clave privada del certificado del cliente. Esta firma puede ser verificada utilizando la clave pública del certificado del cliente. Esto 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 a continuación, utilizan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado el "secreto principal". Todos los demás datos clave para esta conexión se derivan de este secreto maestro (y los valores aleatorios cliente-y generados por el servidor), que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada.
2. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciendo al servidor, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)." El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro y es tipo 20 y no 22.
   • Por último, el cliente envía un mensaje cifrado de Finished, que contiene un hash y MAC sobre los mensajes de handshake anteriores.
   • El servidor intentará descifrar el mensaje final del cliente y verificar el hash y MAC. Si el descifrado o verificación falla, el handshake se considera que ha fracasado y la conexión debe ser derribada.
3. Por último, el servidor envía un ChangeCipherSpec, diciéndole al cliente, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)."
   • El servidor envía su propio mensaje cifrado de Finished.
   • El cliente realiza el mismo descifrado y verificación.
4. Fase de aplicación: en este punto, el "handshake" está completado y el protocolo de aplicación está activado, con el tipo de contenido 23. Los mensajes de la aplicación intercambiados entre el cliente y el servidor también serán cifrados exactamente igual que en su mensaje Finished.

Las operaciones de clave pública (por ejemplo, RSA) son relativamente costosas en términos de cálculo computacional. TLS proporciona un acceso directo seguro en el mecanismo de handshake para evitar estas operaciones: reanudar sesiones. Las sesiones reanudadas se implementan utilizando los identificadores (IDs) de sesión o tickets de sesión.

Aparte de la ventaja de rendimiento, reanudando las sesiones también se puede utilizar para inicio de sesión único, ya que se garantiza que tanto la sesión original, así como cualquier sesiones reanudada se originan desde el mismo cliente. Esto es de particular importancia para el FTP sobre el protocolo TLS/SSL, ya que de lo contrario podría sufrir de un ataque man-in-the-middle en el que un atacante podría interceptar el contenido de las conexiones de datos secundarias.[100]

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

1. Fase de Negociación:
   • Un cliente envía un mensaje ClientHello especificando la versión más alta de protocolo TLS que soporta, un número al azar, una lista de conjuntos de cifrado sugeridos y métodos de compresión. Incluye en el mensaje el ID de sesión de la conexión TLS previa.
   • El servidor responde con un mensaje ServerHello, que contiene la versión elegida del protocolo, un número al azar, una suite de cifrado y el método de compresión de las opciones ofrecidas por el cliente. Si el servidor reconoce el ID de sesión, responde con la misma ID de sesión. El cliente usa esto para reconocer que se está llevando a cabo una sesión reanudada. Si el servidor no reconoce el ID de sesión enviado por el cliente, responde con un valor diferente para la ID de sesión, lo cual le dice al cliente que no se llevará a cabo una reanudación de sesión. En este punto, tanto el cliente como el servidor tienen el "secreto maestro" y datos aleatorios para generar la clave usada para esta conexión.
2. El servidor envía un ChangeCipherSpec, diciéndole al cliente, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)."
   • Por último, el servidor envía un mensaje cifrado de Finished, que contiene un hash y MAC sobre los mensajes de handshake anteriores.
   • El cliente realiza el mismo descifrado y verificación.
3. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciendo al servidor, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)."
   • El cliente envía su propio mensaje cifrado de Finished.
   • El servidor intentará descifrar el mensaje final del cliente y verificar el hash y MAC.
4. Fase de aplicación: en este punto, el "handshake" está completado y el protocolo de aplicación está activado, con el tipo de contenido 23. Los mensajes de la aplicación intercambiados entre el cliente y el servidor también serán cifrados exactamente igual que en su mensaje Finished.

El RFC 5077 extiende TLS a través de la utilización de tickets de sesión, en lugar de los IDs de sesión. Define una forma de reanudar una sesión TLS sin necesidad de almacenar el estado específico de la sesión en el servidor TLS.

Al utilizar tickets de sesión, el servidor TLS almacena su estado específico de la sesión en un ticket de sesión y envía el ticket de sesión al cliente TLS para ser almacenado. El cliente se reanuda una sesión TLS mediante el envío del ticket de sesión al servidor, y el servidor reanuda la sesión TLS en el estado específico de la sesión en el ticket. El ticket de sesión está cifrado y autenticada por el servidor, y el servidor verifica su validez antes de utilizar su contenido.

Una debilidad particular de este método con OpenSSL es que siempre limita el cifrado y la autenticación de seguridad del ticket de sesión TLS transmitido a AES128-CBC-SHA256, no importa qué otros parámetros TLS sean negociados para la sesión actual TLS.[92] Esto significa que la información de estado (el ticket de sesión TLS) no está tan bien protegido como la sesión TLS misma. De particular preocupación es el almacenamiento de OpenSSL de las claves en un contexto de aplicación (SSL_CTX), es decir, que se mantiene durante la duración de la aplicación, y no permite el reingreso de información de los tickets de sesión AES128-CBC-SHA256 TLS sin reiniciar el contexto a nivel de aplicación OpenSSL (lo que es raro, propenso a errores y a menudo requiere intervención administrativa manual).[93][91]

Este es el formato general para todos los registros TLS.

Tipo de Contenido

Este campo identifica el Tipo de Capa de Registro del Protocolo contenido en este registro.

Versión

Este campo identifica la versión mayor y menor de TLS para el mensaje contenido. Para un mensaje ClientHello, esto no tiene por qué ser la versión más alta admitida por el cliente.

Longitud

La longitud del mensaje del Protocolo (s), MAC y Relleno, que no exceda de 214 bytes (16 KiB).

Protocolo del Mensaje

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

MAC y Relleno

Un código de autenticación de mensaje calculado sobre el mensaje del Protocolo, con el material clave adicional incluido. Tenga en cuenta que este campo puede ser codificado, o no incluidos en su totalidad, dependiendo del estado de la conexión.

No MAC o relleno pueden estar presentes al final de los registros TLS antes de todos los algoritmos de cifrado y parámetros han sido negociados y handshaked y luego confirmado por el envío de un registro CipherStateChange (ver más abajo) para la señalización de estos parámetros tendrán efecto en todos los registros adicionales enviados por el misma pares.

La mayoría de los mensajes intercambiados durante la configuración de la sesión TLS se basan en este registro, a menos que un error o advertencia se produzca y necesite ser señalado por un registro de protocolo de alerta (ver más abajo), o el modo de cifrado de la sesión es modificado por otro récord (véase el protocolo ChangeCipherSpec abajo).

Tipo de Mensaje

Este campo identifica el tipo de mensaje del handshake.

Longitud de datos de mensajes de handshake

Este es un campo de 3 bytes que indica la longitud de los datos de handshake, no incluyendo la cabecera.

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

Este registro no debería enviarse normalmente durante los intercambios de protocolo de enlace o de aplicación normales. Sin embargo, este mensaje puede ser enviado en cualquier momento durante el handshake y hasta el cierre de la sesión. Si esto se utiliza para señalar un error fatal, la sesión se cerrará inmediatamente después de enviar este registro, por lo que este registro se utiliza para dar la razón de este cierre. Si el nivel de alerta se marca como una advertencia, el equipo 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 remoto también puede enviar su propia señal).

Nivel

Este campo identifica el nivel de alerta. Si el nivel es fatal, el remitente debe cerrar la sesión inmediatamente. De lo contrario, el destinatario puede decidir terminar la sesión, mediante el envío de su propia alerta fatal y cierre de la sesión misma inmediatamente después de enviarlo. El uso de registros de alerta es opcional, sin embargo si no se encuentra antes del cierre de sesión, la sesión puede reanudarse automáticamente (con sus handshake).

El cierre normal de la sesión después de la terminación de la aplicación transportada debe ser alertado preferiblemente con al menos el tipo de alerta Close notify (con un nivel de aviso sencillo) para evitar que la nueva sesión pueda ser reanudada. La señalización explícita del cierre normal de una sesión segura antes de cerrar de manera efectiva su capa de transporte es útil para prevenir o detectar los ataques (como los intentos de truncar los datos transportados de forma segura, si es que intrínsecamente no tiene una longitud predeterminada o duración que el destinatario de los datos puede esperar).

Descripción

Este campo identifica cual tipo de alerta está siendo enviada.

Tipo de Protocolo CCS

Actualmente solo 1.

Largo

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

MAC

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

Relleno

Largo variable; el último byte contiene el largo del relleno.

Las extensiones a TLS 1.0 incluyen:

• RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Especifica una extensión a los servicios IMAP, POP3 y ACAP que permiten a cliente y servidor usar seguridad en la capa de transporte para entregar comunicaciones privadas y autenticadas sobre Internet.
• RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". Las familias de cifrados de 40-bit definidas en este memo aparecen sólo para propósitos de documentación del hecho de que esas familias de códigos de cifrado han sido ya asignadas.
• RFC 2817: "Upgrading to TLS Within HTTP/1.1", explica cómo usar el mecanismo Upgrade en HTTP/1.1 para iniciar TLS sobre una conexión TCP existente. Esto permite al tráfico HTTP inseguro y seguro compartir el mismo puerto conocido (en este caso, http: en el 80 en vez de https: en el 443).
• RFC 2818: "HTTP Over TLS", diferencia tráfico seguro de tráfico inseguro mediante el uso de un 'puerto de servidor' diferente.
• RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Especifca una extensión al servicio SMTP que permiten a cliente y servidor SMTP usar seguridad en la capa de transporte para entregar comunicaciones privadas y autenticadas sobre Internet.
• RFC 3268: "AES Ciphersuites for TLS". Añade la familia de cifrado AES a los cifrados simétricos previamente existentes.
• RFC 3546: "Transport Layer Security (TLS) Extensions", añade un mecanismo para negociar extensiones de protocolos durante la inicialización de sesión y define algunas extensiones.
• RFC 3749: “Transport Layer Security Protocol Compression Methods”, especifica el marco para los métodos de compresión y para el método DEFLATE.
• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.
• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4217: “Securing FTP with TLS”.
• RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", añade tres conjuntos de nuevas familias de cifrados para que el protocolo TLS permita la autenticación basada en claves previamente compartidas.

Las extensiones a TLS 1.1 incluyen:

• RFC 4347: “Datagram Transport Layer Security” especifica una variante de TLS que funciona sobre protocolos de datagramas (tales como UDP).
• RFC 4366: “Transport Layer Security (TLS) Extensions” describe tanto un set de extensiones específicas y un mecanismo de extensiones genéricas.
• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.
• RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.
• RFC 4680: “TLS Handshake Message for Supplemental Data”.
• RFC 4681: “TLS User Mapping Extension”.
• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.
• RFC 5054: “Using the Secure Remote Password (SRP) Protocol for TLS Authentication”. Define las cihpersuites TLS-SRP.
• RFC 5081: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication”, obsoleta después del RFC 6091.

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

• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.

El estándar actual reemplaza a las versiones más antiguas, las que son consideradas obsoletas:

• RFC 2246: “The TLS Protocol Version 1.0”.
• RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.

así como el nunca estandarizado SSL 3.0:

• RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”.

Otros RFC posteriores extendieron TLS.

Las extensiones a TLS 1.2 incluyen:

• RFC 5746: “Transport Layer Security (TLS) Renegotiation Indication Extension”.
• RFC 5878: “Transport Layer Security (TLS) Authorization Extensions”.
• RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“.
• RFC 6176: “Prohibiting Secure Sockets Layer (SSL) Version 2.0”.
• RFC 6209: “Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)”.

• RFC 8446,en inglés: The Transport Layer Security (TLS) Protocol Version 1.3.

Las encapsulaciones de TLS incluyen:

• RFC 5216: "The EAP-TLS Authentication Protocol"