Seguridad de la capa de transporte (en inglés: Transport Layer Security o TLS) y su antecesor Secure Sockets Layer (SSL; en español capa de puertos seguros) son protocolos criptográficos, que proporcionan comunicaciones seguras por una red, comúnmente Internet.
Se usan certificados X.509 y por lo tanto criptografía asimétrica para autentificar a la contraparte con quien se están comunicando, y para intercambiar una llave simétrica. Esta sesión es luego usada para cifrar el flujo de datos entre las partes. Esto permite la confidencialidad del dato/mensaje, códigos de autenticación de mensajes para integridad y como un producto lateral, autenticación del mensaje. Varias versiones del protocolo están en aplicaciones ampliamente utilizadas como navegación web, correo electrónico, fax por Internet, mensajería instantánea y voz-sobre-IP (VoIP). Una propiedad importante en este contexto es forward secrecy, para que la clave de corta vida de la sesión no pueda ser descubierta a partir de la clave asimétrica de largo plazo.
TLS es un protocolo de Internet Engineering Task Force (IETF), definido por primera vez en 1999 y actualizado en el RFC 5246 (agosto de 2008) y en RFC 6176 (marzo de 2011). Se basa en las especificaciones previas de SSL (1994, 1995, 1996) desarrolladas por Netscape Communications para agregar el protocolo HTTPS a su navegador Netscape Navigator. Su última versión, TLS 1.3, fue definida en agosto de 2018.
SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, solo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.
SSL implica una serie de fases básicas:
Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones:
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.
El protocolo SSL fue desarrollado originalmente por Netscape. 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". 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. Es una actualización de TLS 1.0. Las diferencias más significativas incluyen:
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:
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:
El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser comprimido, cifrado y empaquetado con un código de autenticación del mensaje (MAC). Cada registro tiene un campo de content_type que especifica el protocolo de nivel superior que se está usando.
Cuando se inicia la conexión, el nivel de registro encapsula otro protocolo, el protocolo handshake (o protocolo de acuerdo), que tiene el content_type 22.
El cliente envía y recibe varias estructuras handshake:
TLS/SSL poseen una variedad de medidas de seguridad:
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), y PSK (TLS_PSK).
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.
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.
SSL se ejecuta en una capa entre los protocolos de aplicación como HTTP, SMTP, NNTP y sobre el protocolo de transporte TCP, que forma parte de la familia de protocolos TCP/IP. Puede proporcionar seguridad a cualquier protocolo que use conexiones de confianza (tal como TCP).
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.
Todos los navegadores importantes soportan TLS:
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.
Un ensayo presentado en la conferencia ACM 2012 de seguridad de computadores y comunicaciones 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:
SSL 2.0 está desactivado por defecto, a partir de: Internet Explorer 7, Mozilla Firefox 2, Opera 9.5, 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. 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
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.
Hay algunos ataques contra la implementación en lugar del propio protocolo: En las implementaciones anteriores, algunas entidades emisoras 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 .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.
TLS tiene una variedad de medidas de seguridad:
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. 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.
Hay modificaciones a los protocolos originales, como False Start (aprobada y habilitada por Google Chrome) o Snap Start, en las que se ha reportado que han introducido limitaciones a los ataques de reversión de versiones para TLS 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). 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.
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. Exploits prácticos de esta vulnerabilidad no se conocían, la cual fue descubierta originalmente por Phillip Rogaway 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.
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. Por su parte, Apple habilitó por defecto la protección contra BEAST en la versión OS X 10.9 Mavericks.
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. 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. 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.
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.
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.
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.
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. En 2013 una vulnerabilidad fue descubierta en RC4 sugiriendo que no era una buena solución para BEAST. 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 para recuperar partes del texto en claro con un gran número de cifrados TLS. 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.
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.
Microsoft recomienda deshabilitar RC4 cuando sea posible.
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.
Publicado en julio de 2013, 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). 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).
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.
A diciembre de 2014, Trustworthy Internet Movement estima que la proporción de sitios web que son vulnerable a ataques TLS.
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. 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). 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. Sin embargo, muchos clientes y servidores que soportan TLS (incluidos los navegadores y servidores web) no están configurados para aplicar esas restricciones. 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.
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.
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. Desde noviembre de 2013, Twitter ha proporcionado forward secrecy con TLS para los usuarios de su servicio. 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.
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.
Una forma de detectar y bloquear muchos tipos de ataques MITM es "fijar el certificado", a veces llamado "fijación SSL".
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.
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 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.
El protocolo TLS intercambia registros- los que encapsulan los datos que se intercambian en un formato específico (ver más abajo). Cada registro puede ser comprimido, cifrado y empaquetado con un código de MAC (Código de Autenticación del Mensaje), todo dependiendo del estado de la conexión. Cada registro tiene un campo de tipo de contenido que designa el tipo de datos encapsulados, un campo de longitud y un campo de versión TLS. Los datos encapsulados pueden ser mensajes de control o de procedimiento de la propia TLS, o simplemente los datos de las aplicaciones que necesitan ser transferidos por TLS. Las especificaciones (suite de cifrado, claves, etc.) necesarios para el intercambio de datos de la aplicación por TLS, se han acordado en el "handshake TLS" entre el cliente que solicita los datos y el servidor que responde a las solicitudes. Por tanto, el protocolo define tanto la estructura de cargas útiles transferidos en TLS y el procedimiento para establecer y supervisar la transferencia.
Cuando se inicia la conexión, el registro encapsula un protocolo de "control"- el protocolo de mensajería de 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:
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.
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.
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.
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. 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).
Este es el formato general para todos los registros TLS.
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).
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).
Desde el punto de vista del protocolo de aplicaciones, TLS pertenece a una capa baja, aunque el modelo TCP/IP es muy grueso para mostrarlo. Esto significa que el handshake es usualmente (excepto en el caso STARTTLS) llevado a cabo antes de que el protocolo de aplicación pueda comenzar. La funcionalidad de servidor virtual basado en nombres es provista por la capa de aplicación, donde todos los servidores virtuales alojados en una misma máquina comparten el mismo certificado. Esto es un problema, ya que el servidor debe seleccionar y mandar el certificado inmediatamente después del mensaje de ClientHello. Este es un gran problema en los ambientes de alojamiento, ya que implica que todos los clientes en un mismo servidor deben compartir el certificado o se debe utilizar una IP distinta para cada uno de ellos. Hay dos formas conocidas de evitar esto, provistas por X.509:
En orden a proveer el nombre del servidor, la RFC 4366 Transport Layer Security (TLS) Extensions permiten al cliente incluir una extensión de Indicación de nombre de servidor (Server Name Indication o SNI) en el mensaje extendido ClientHello. Esta extensión inmediatamente le da pistas al servidor respecto de cuál nombre es al que el cliente se quiere conectar, por lo que el servidor puede seleccionar el certificado apropiado para enviar al cliente.
Las extensiones a TLS 1.0 incluyen:
Las extensiones a TLS 1.1 incluyen:
La versión actual aprobada de TLS es la 1.2, la que se especifica en:
El estándar actual reemplaza a las versiones más antiguas, las que son consideradas obsoletas:
así como el nunca estandarizado SSL 3.0:
Otros RFC posteriores extendieron TLS.
Las extensiones a TLS 1.2 incluyen:
Las encapsulaciones de TLS incluyen:
Escribe un comentario o lo que quieras sobre Seguridad de la capa de transporte (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)