/

¿Qué es un TLS handshake y cómo funciona?

por Team Ninja
What Is a TLS Handshake & How Does It Work blog banner image
What Is a TLS Handshake & How Does It Work blog banner image

Prueba nuestro software de gestión de endpoints n.º 1 en G2

Sin necesidad de tarjeta de crédito, acceso completo a todas las funciones.

Webinar

Actualizaciones de NinjaOne 12.0: todo lo que necesitas saber

Automatiza las aspectos más complejos de la TI

TLS (transport layer security) es el protocolo de comunicación segura que utiliza buena parte de internet. Desde la conexión cifrada que usa tu navegador para acceder a los sitios web hasta las conexiones seguras de tus aplicaciones bancarias, TLS es el estándar del sector y la razón por la que puedes transferir información sensible online con confianza.

En esta guía te explicamos qué es un TLS handshake, cómo funciona y por qué es tan importante para la seguridad de la red y para garantizar que tus comunicaciones sean privadas y no puedan interceptarse ni manipularse.

¿Qué es un TLS handshake?

El cifrado TLS es el protocolo criptográfico estándar para proteger las comunicaciones de red, incluidos los datos que envías por internet.

Antes de que pueda producirse una comunicación cifrada, hay que establecer una relación de confianza entre las dos partes que se comunican (por ejemplo, el servidor web que aloja un sitio y el navegador con el que accedes a él).

De eso se encarga el TLS handshake: establece un canal seguro entre cliente y servidor comunicando qué versiones de TLS y qué conjuntos de cifrado admiten ambos, autenticando la identidad del servidor mediante su clave pública y su certificado SSL y, por último, generando las claves de sesión que cifrarán la conexión de forma única.

TLS frente a SSL

TLS es el sucesor de SSL (Secure Sockets Layer) y lo ha sustituido como protocolo de cifrado en el que se apoya HTTPS (la versión segura del protocolo HTTP, que entrega las páginas web a tu navegador y los datos a tus aplicaciones). TLS también lo utiliza otro software que necesita comunicaciones de red seguras, como las soluciones VPN.

Elementos criptográficos implicados

El cifrado TLS se basa en varios elementos y conceptos criptográficos:

  • El conjunto de cifrado: el conjunto de cifrado es el algoritmo que protege una conexión cifrada con TLS. Cada conjunto incluye un algoritmo de intercambio de claves, un algoritmo de cifrado masivo y un algoritmo MAC (código de autenticación de mensajes).
  • Cifrado simétrico: tanto el servidor como el cliente usan una única clave criptográfica para proteger la conexión. Ambas partes deben conocer esa clave y ningún tercero debería conocerla ni poder adivinarla; de lo contrario, la seguridad de la conexión queda comprometida.
  • Cifrado asimétrico: también conocido como cifrado de clave pública. En este método, servidor y cliente usan claves privadas y públicas distintas para cifrar los datos y proteger la conexión. La clave privada es necesaria para descifrar los datos cifrados con la clave pública.
  • Autenticación: para conectarte de forma segura a un servidor (y no a un impostor), este debe poder demostrar su identidad sin lugar a dudas mediante la autenticación.

Versiones de TLS y compatibilidad

TLS 1.0 se publicó en 1999, TLS 1.1 en 2006, TLS 1.2 en 2008 y la última versión, TLS 1.3, en 2018. Cada lanzamiento incorporó mejoras importantes de seguridad, con nuevos conjuntos de cifrado y protección frente a nuevos ataques.

La mayoría de los servidores admiten TLS 1.3 y TLS 1.2 para mantener la compatibilidad con clientes más antiguos.

El proceso de un TLS handshake paso a paso

TLS 1.3 simplifica enormemente el proceso de handshake y mejora su seguridad respecto a versiones anteriores. Así es, en detalle, el proceso que protege una conexión TLS 1.3:

  • Client hello: el cliente envía un mensaje «hello» al servidor para iniciar el TLS handshake y la conexión. Ese mensaje incluye las versiones de TLS, los conjuntos de cifrado, el método de intercambio de claves y las extensiones que admite. También incluye el «client random», unos datos aleatorios que se usarán para generar el secreto maestro. En muchos casos, los parámetros del secreto premaestro también pueden generarse cuando el cliente es capaz de adivinar qué método de intercambio de claves usará el servidor (algo habitual, dado el menor número de conjuntos de cifrado que admite TLS 1.3), lo que reduce el número de idas y vueltas necesarias entre cliente y servidor.
  • Secreto maestro: el servidor selecciona una versión de TLS, un conjunto de cifrado y un intercambio de claves compatibles con el cliente, y genera su «server random». Cuando cliente y servidor disponen del client random, del secreto premaestro y del server random, pueden generar de forma independiente el mismo secreto maestro.
  • Server hello y comunicación asimétrica: el servidor responde al client hello enviando la versión de TLS y el conjunto de cifrado seleccionados, junto con su certificado SSL/TLS, que contiene su clave pública y la autoridad de certificación (CA). El cliente puede verificar la identidad del servidor con la CA.
  • Generación de las claves de sesión: cliente y servidor generan claves de sesión coincidentes a partir del secreto maestro.
  • Mensajes «finished» y comunicación simétrica: cliente y servidor intercambian mensajes «finished» que contienen la clave de sesión simétrica y un hash del proceso de handshake realizado, para comprobar que nadie ha interferido en él. El TLS handshake se completa cuando ambas partes han descifrado y validado esos mensajes «finished».

Una vez completado el TLS handshake, la conexión ya puede usarse para transmitir datos de forma segura con las claves de sesión simétricas.

Cómo resolver problemas con el TLS handshake

La causa más frecuente de los problemas con el TLS handshake es una hora mal configurada en el servidor o en el cliente (algo fácil de corregir). Las CA desactualizadas en el cliente también pueden ser el origen del problema si hace tiempo que no actualizas el sistema operativo.

En el lado del servidor, las conexiones TLS fallarán si no hay versiones de TLS o conjuntos de cifrado admitidos por ambas partes, si la CA ha revocado el certificado SSL/TLS, si este ha caducado o si el nombre de host del servidor no coincide con el del certificado.

Si tienes problemas de conectividad de red o te conectas a un servidor lento, los TLS handshakes pueden fallar al agotarse el tiempo de espera por la latencia.

Protege las sesiones de tus usuarios desde el primer momento. Mira ahora qué es el TLS handshake.

Los protocolos de comunicación segura no son totalmente seguros

TLS sostiene hoy la seguridad de red de prácticamente todo lo que ocurre online. Pero el hecho de que pueda transmitir datos de forma segura (tras el imprescindible TLS handshake) no significa que lo que transmite sea inofensivo.

Tener una conexión segura con un sitio web no quiere decir que ese sitio no pueda alojar un virus, así que limita las descargas de software a webs de confianza (o mejor aún, a tiendas de aplicaciones oficiales) y, si tienes una empresa, protege tu infraestructura con una gestión de endpoints sólida.

Quizá también te interese...

¿Listo para simplificar los aspectos más complejos de las TI?

Términos y condiciones de NinjaOne

Al hacer clic en el botón «Acepto» que aparece a continuación, estás aceptando los siguientes términos legales, así como nuestras Condiciones de uso:

  • Derechos de propiedad: NinjaOne posee y seguirá poseyendo todos los derechos, títulos e intereses sobre el script (incluidos los derechos de autor). NinjaOne concede al usuario una licencia limitada para utilizar el script de acuerdo con estos términos legales.
  • Limitación de uso: solo podrás utilizar el script para tus legítimos fines personales o comerciales internos, y no podrás compartirlo con terceros.
  • Prohibición de republicación: bajo ninguna circunstancia está permitido volver a publicar el script en ninguna biblioteca de scripts que pertenezca o esté bajo el control de cualquier otro proveedor de software.
  • Exclusión de garantía: el script se proporciona «tal cual» y «según disponibilidad», sin garantía de ningún tipo. NinjaOne no promete ni garantiza que el script esté libre de defectos o que satisfaga las necesidades o expectativas específicas del usuario.
  • Asunción de riesgos: el uso que el usuario haga del script corre por su cuenta y riesgo. El usuario reconoce que existen ciertos riesgos inherentes al uso del script, y entiende y asume cada uno de esos riesgos.
  • Renuncia y exención: el usuario no hará responsable a NinjaOne de cualquier consecuencia adversa o no deseada que resulte del uso del script y renuncia a cualquier derecho o recurso legal o equitativo que pueda tener contra NinjaOne en relación con su uso del script.
  • CLUF: si el usuario es cliente de NinjaOne, su uso del script está sujeto al Contrato de Licencia para el Usuario Final (CLUF).