Pandora FMS Tech blog

Una conexión TLS ilustrada: conozcamos en detalle cada paso

por | Last updated Jul 19, 2021 | Comunidad, Tecnología

TLS ilustrada

TLS ilustrada; conozcamos cómo nuestros datos privados son protegidos

Dice el sabio refrán que la soga se rompe por lo más delgado o, dicho de otra manera, “una cadena es tan fuerte como el más débil de sus eslabones”; por ello, hoy tocaremos el tema de las comunicaciones seguras con una conexión TLS ilustrada.

En un artículo anterior os hablamos acerca del Caddy Web Server; este incorpora por defecto la “Seguridad de la Capa de Transporte” (en inglés Transfer Layer Security o TLS por sus iniciales), lo cual nos brinda una seguridad muy importante para nuestras comunicaciones con nuestro servidor Pandora FMS, nuestros bancos, redes sociales, etc.

Había una vez…

Tal como dice el comienzo de los cuentos infantiles, os contamos un poco de historia: la popularización de las comunicaciones cifradas (que pueden ser interceptadas por terceros pero que tardarían mucho tiempo en descifrar su contenido y por ende nuestros datos personales) surgió a raíz de los escándalos relacionados con la revelación de información del hacker Edward Snowden. En este punto os daréis cuenta de que no solo para nosotros los geeks va este artículo, ya que el caso tuvo una gran difusión mediática a nivel mundial y seguro que habréis oído sobre ello. Gracias a ese incidente la mayoría de los navegadores de la actualidad advierten si una página no es cifrada e incluso niegan la conexión si el certificado de seguridad es autofirmado.
A fin de masificar nuestra privacidad, la Fundación Frontera Electrónica («Electronic Frontier Foundation»), mejor conocida como EFF, creó el programa Let’s Encrypt a fin de que tan solo con una pequeña donación anual podamos contar con certificados de manera automática y masiva en nuestros blogs, páginas de nuestras empresas, etcétera. ¡De hecho, Caddy Web Server trae por defecto instalado a Let’s Encrypt!
Tenemos entonces así al alcance de todos el HTTPS, sí, el ícono del famoso candado que aparece en nuestro navegador web, generalmente en color verde o azul (dependiendo de la autoridad certificadora), el cual originalmente era la fusión del HTTP más el SSL (Capa de Puertos Seguros o “Secure Sockets Layer”), tecnología hoy “obsoleta” que derivó en favor de TLS a fin de hacerlo inexpugnable.

Pandora FMS y su consola

En este punto hacemos la debida aclaratoria de que Pandora FMS (e infinidad de aplicaciones web) utiliza un servidor web para las operaciones de consola y su Interfaz de Programación de Aplicaciones (“API”) y es nuestro deber adquirir un certificado de seguridad a fin de ser instalado y garantizar nuestra privacidad al monitorizar nuestros sistemas. Pero todo esto que explicamos aquí está fuera del alcance del código fuente de Pandora FMS.
Por si ya os lo estáis preguntando: «¿De qué manera (segura) se comunica Pandora FMS con sus agentes software?». Pues la respuesta es el protocolo Tentacle y aquí tenéis una guía para vuestros propios certificados con OpenSSL. Ahora que tenemos establecido un panorama general, entramos de lleno en la TLS ilustrada.

Café

Recomendado: una buena taza de café negro os prepará vuestras neuronas en este recorrido. En serio.

TLS ilustrada

En noviembre de 2018 el señor Michael Driscoll creó la TLS ilustrada versión 1.3, bajo la licencia de software del Instituto Tecnológico de Massachusetts («MIT license»), a fin de que se pudiera conocer de una manera más fácil el funcionamiento, paso a paso, byte a byte, de esta tecnología (y lo cual logró retratar muy bien). En este enlace podréis ver en directo el funcionamiento de la versión 1.3 y también de la anterior versión 1.2; aquí describiremos la versión más nueva y de manera muy resumida el proceso de envío cifrado de la palabra “ping” (con una respuesta también cifrada: “pong”).

Términos utilizados

Breves conceptos que son necesarios:

  • “Endpoint” o punto final: uno cualquiera de los dos extremos en la comunicación, el cliente o el servidor.
  • “Client” o cliente: el punto final que inicia la comunicación.
  • “Connection” o conexión: la capa de transporte que comunica ambas puntas finales.
  • “Handshake” o apretón de manos; aquí colocaremos saludo: la negociación entre ambos puntos finales a fin de acordar cuáles protocolos utilizar.
  • Clave privada: un número muy pero muy especial que bien podemos generar nosotros mismos o puede ser proporcionado por una entidad certificadora de confianza. En ambos casos se calculará por artificios matemáticos complejos una clave pública correspondiente, que será la que daremos a todo aquel con quien vayamos a comunicarnos.
TLS ilustrada

TLS ilustrada: inicio del procedimiento

Generación de clave por parte del cliente

Previo a la conexión, el cliente escoge de manera aleatoria un número muy grande para usarlo como clave privada y con una fórmula matemática (en este ejemplo la X25519 propuesta por Daniel J. Bernstein) procede a generar una clave pública que será la que podrá entregar a cualquiera una comunicación segura (con OpenSSL podremos confirmar su relación matemática).

TLS ilustrada

Verificación por medio de OpenSSL de las claves temporales generadas

Saludo del cliente (inicio de conexión)

El cliente envía un paquete presentándose a sí mismo con la información acerca del TLS a utilizar. ¿Recordáis que os mencionamos SSL? Pues bien, el cliente envía la palabra clave “31” en hexadecimal para indicarle al servidor que es capaz de entender TLS 1.0 (SSL 3 + TLS 1 = “31”) ¿Pero no era que íbamos de TLS 1.3? Sí, pero por retrocompatibilidad es necesario indicar al servidor que nuestro cliente maneja todas estas versiones:

  • TLS 1.0: “31”.
  • TLS 1.1: “32”.
  • TLS 1.2: “33”.
  • TLS 1.3: “34”.

También por compatibilidad enviamos un identificador de sesión no vacío, aunque no es necesario en TLS1.3 ya que utiliza PSK (claves precompartidas); otro valor importante es el SNI (Server Name Indication) para los servidores web que alojan juntos a múltiples dominios web. Métodos de cifrado, lista reducida a los más seguros en TLS1.3, así como tampoco usar compresión son las novedades aquí.

Generación de clave por parte del servidor

Recibido el saludo, el servidor antes de contestar realiza el mismo trabajo hecho por el cliente.

Saludo del servidor (respuesta a la conexión)

Si el servidor soporta TLS1.3 aquí enviará de todas maneras un “32” (TLS1.2), probablemente el mismo identificador de sesión que envió el cliente (que no usaremos en realidad) acompañado de la muy importante clave pública del servidor calculada en el punto. Entre otros valores enviará el método de cifrado, para este caso AES128 Y SHA256. Nótese que aún no hemos comenzado a cifrar ninguna comunicación; todo esto puede ser interceptado y leído por un tercero sin ningún problema, pero sigamos.

Cálculo de claves en ambas partes
Vale la pena aclarar que, aunque encriptados, los paquetes serán “marcados” (primeros 5 bytes) como TLS1.2 para todos los que estén en medio, ya que como la norma es muy novedosa puede conducir a que estos intermediarios bloqueen nuestros mensajes. Esto sucede así porque Internet es una serie de ordenadores conectados unos con otros y que hacen un “camino” entre nosotros y nuestro destino.

Finalización del saludo

  • El servidor enviará su certificado de seguridad otorgado, por ejemplo, por Let’sEncrypt. ¿En qué consiste esto? Pues básicamente en la clave pública generada a partir de la clave privada generada por Let’sEncrypt, además de los identificadores para esta entidad certificadora. Lo interesante de este proceso es que estos identificadores a su vez son certificados respaldados por otras entidades certificadoras en una cadena de confianza que llegará finalmente hasta un certificado de seguridad preinstalado en el navegador web del cliente.
  • El servidor toma la clave pública del cliente y la combina con su propia clave privada; el cliente hace lo propio también (viceversa). Es a partir de aquí donde comienza toda comunicación cifrada y lo que realmente diferencia a TLS1.3; sin embargo, se intercambiarán paquetes con información superflua por retrocompatibilidad.
  • Adicionalmente, el servidor atará matemáticamente la clave pública que generó para esta conexión con su propia clave privada de su certificado de seguridad otorgado por Let’sEncrypt (ánimo que ya vamos a terminar).
  • Aunque hay otros procesos que no mencionaremos, el siguiente paso importante es que ambos, servidor y cliente, harán unas huellas digitales o hash (en inglés) hechas con un algoritmo SHA256 para todos estos mensajes en formato TLS1.3 (sin la cabecera de 5 bytes que identifica como TLS1.2 de manera pública para evitar el bloqueo) que se han intercambiado. Esto se hace a fin de verificar durante toda la conversación que TODOS los paquetes cifrados que se envían y reciben son emitidos por quienes dicen ser.
    • TLS ilustrada

    TLS ilustrada: fin del procedimiento

    Proceso simplificado: la conversación

    El proceso del saludo y cifrado es mucho más simple de lo que parece; aquí lo ilustramos en forma de conversación entre el cliente y el servidor:

    Cliente: ¡Hola! Me gustaría establecer una comunicación segura entre los dos, por aquí te paso mi código cifrado y la versión compatible de SSL/TLS.
    «Generación de clave por parte del servidor» y «Saludo del servidor (respuesta a la conexión)»
    Servidor: ¡Hola! ¿Cómo estás querido cliente? Ya he comprobado el código cifrado y la versión SSL/TLS. Están correctos, así que continuemos con la conversación. Te envío mi certificado y mi clave pública. ¡Revísalas!
    «Cálculo de llaves en ambas partes»
    Cliente: Deja que las revise… ajam… sí, parecen correctas, pero antes necesito verificar tu clave privada. Para ello, haremos lo siguiente: genero y encripto un pre-máster (una clave secreta compartida) utilizando tu clave pública. A continuación, podrás desencriptarlo utilizando tu clave privada y utilizaremos la clave máster para encriptar y desencriptar la información. ¿Te parece?
    Servidor: ¡Perfecto!
    «Finalización del saludo»
    Ahora que tanto el cliente como el servidor se han asegurado con quién están hablando realmente (después de la comprobación del certificado Let’s Encrypt), la información que intercambien se realizará de manera segura.

    Envío del “ping”

    El cliente podrá enviar la palabra “ping” de manera cifrada, el servidor contestará también de manera cifrada “pong”, pero antes, además, nos enviará dos identificadores de sesión (con medidas de seguridad adicionales) que generalmente expiran en 48 horas, para acelerar las próximas conexiones y no repetir por completo todo este proceso que acabamos de estudiar. ¿Ingenioso, no?

    Ya tenéis en vuestro navegador web los identificadores de sesión necesarios para que leáis nuestros otros artículos. ¿Aún quieres saber más sobre la monitorización de sistemas informáticos? Por suerte, estás en el lugar indicado para conocer más. En este blog existen decenas de artículos que pueden introducirte en este apasionante mundo. Aquí tienes un enlace a nuestra página de inicio: https://pandorafms.com/blog/es/

    O también puedes contactar directamente con Pandora FMS si tienes más de 100 dispositivos para monitorizar. Entra aquí: https://pandorafms.com/es/contactar/

    Si cuentas con un número reducido de máquinas para monitorizar, puedes conocer la versión de Pandora FMS OpenSource aquí:
    https://pandorafms.org/es/

Shares