Protocolo TLS
- PROTOCOLO TLS PARA INTERCAMBIO DE CREDENCIALES -
El protocolo TLS (Transport Layer Security) es el estándar mundial que
implementa el establecimiento de una comunicación segura. SSL (Secure
Socket Layer) es una implementación propietaria inicial pero no es el estándar.
TLS se encuentra definido en los RFC's 2246 y 4246 en sus versiones 1.0 y
1.1 respectivamente, y se sirve de todo lo anterior para realizar un proceso de
negociación entre una máquina servidora y una cliente. Este proceso de
negociación responde a la vida misma y se puede considerar un apretón de
manos en toda regla.
Teniendo la pila de protocolos TCP/IP en mente, TLS se encuentra por encima
del nivel de transporte (TCP), por lo que securiza el nivel de aplicación sea cual
sea ésta. Sería como llevar una carga en un camión de transporte cerrado con
llave. Se puede saber de dónde vino, dónde va, e incluso se puede saber quién
es el emisor y el receptor, pero nunca se podrá saber lo que lleva dentro. Es
decir, si se interceptan comunicaciones que van sobre TLS, en general se
pueden saber IP's y puertos origen y destino (y por lo tanto qué aplicación)
pero nada más. Seguridad en el nivel de transporte. Además, es un protocolo
con estado, por lo que puede recordar sesiones anteriores con clientes por un
un cronograma de paso de mensajes en un escenario Cliente-Servidor TLS
genérico.
Como casi toda comunicación entre un cliente y un servidor será el cliente el
que la inicie. Lo normal es que al menos el servidor tenga un certificado propio, Figura 7. Intercambio de mensajes en una sesión TLS
firmado por una autoridad en la que el cliente confiará o no. Los mensajes con
asterisco son opcionales y la comunicación se inicia en claro. El proceso que
se sigue es el siguiente:
1. ClientHello. El cliente comunica al servidor la versión del protocolo que
quiere utilizar (1.0 ó 1.1), el identificador de sesión si es que tuvo una
anterior (si no, a 0), la suite criptográfica que soporta ordenada de
mayor a menor preferencia. Esto es una lista de algoritmos de cifrado
simétrico, asimétrico y funciones hash. Si no coinciden en al menos 1 de
cada tipo, la negociación se detiene. Además le envía un número
aleatorio Cnonce (Aleatorio de Cliente), generado con un alto grado de
entropía (desorden) en el reparto de sus 224 bits. Esto se hace para
proporcionar “frescura” a las claves, ya que será una por sesión.
2. ServerHello. El servidor confirma la versión del protocolo, los algoritmos
a utilizar y asigna el identificador de sesión si ésta es nueva o ya expiró.
Además le envía un Snonce o Aleatorio del servidor.
3. ServerCertificate. El servidor envía su certificado si es que lo tiene. El
cliente deberá disponer del certificado de la autoridad que firma el del
servidor y si confía en ella tratará de verificar la firma. Si no es verificada
la negociación se detiene. Si el servidor no tiene certificado significa que
harán un intercambio de claves tipo Diffie-Hellman o similar, con el
inconveniente de NO saber con certeza quién está al otro lado.
4. CertificateRequest. Si la configuración del servidor lo exige, pide al
5. ServerHelloDone. Todo bien por parte del servidor. No necesita el
envío de más mensajes para autenticarse.
6. ClientCertificate. Si el servidor envió el mensaje 4 el cliente le envía su
certificado. Si no lo tiene, o el servidor no puede verificar la firma, o no
confía en la autoridad del cliente, la negociación se detiene. Además, no
tiene por qué estar firmado por la misma autoridad que el del servidor.
Lógicamente, el servidor deberá disponer del certificado de autoridad
que firma el de cliente, al igual que el cliente necesita el certificado de
autoridad del servidor para verificarlo.
7. ClientKeyExchange. El cliente envía al servidor lo que se conoce como
Pre-Master Secret. Esto es una semilla de 368 bits generada con alto
grado de desorden por la máquina cliente y que dará lugar a un proceso
de generación de claves en paralelo que ahora se verá. Se lo envía
cifrado con la clave pública del servidor, de modo que sólo él podrá
descifrarla.
8. Cambio a modo cifrado por ambas partes. A partir de ahora la
comunicación se cifrará con las claves de cifrado SIMÉTRICO
generadas y bajo los algoritmos que se hayan negociado. Además, para
mayor seguridad, en los mensajes “FIN” se envían mutuamente un
resumen firmado de todos los mensajes enviados. Es el fin del
HANDSHAKE (apretón de manos).
El proceso de generación de claves en TLS lo realizan en paralelo cliente y
las mismas claves finales, debido al determinismo de las funciones hash. Tras
el mensaje ClientKeyExchange ambos poseen el Pre-Master Secret y
generarán el Master-Secret de esta forma:
Master-Secret = PRF(Pre-Master Secret|| “master secret” || Cnonce || Snonce)
donde “||” es concatenación y “master secret” es un literal. Tras esto, generan
el Key-Block de un modo similar:
Key-Block = PRF(Master-Secret || “key expansion” || Snonce || Cnonce)
El Key-Block es el bloque final de clave de 136 octetos de longitud, y conforma
6 claves. Dos son de cifrado simétrico, una para cada sentido de la
comunicación, dos para firmar los mensajes y dos Vectores de Inicialización
también para cada sentido.
El servidor mantendrá una tabla con dos entradas por cliente, ID de sesión y
Key-Block para poder recordar las sesiones. Si se diese el caso, los mensajes
3, 4, 5, 6, y 7 no se envían.
Se puede ver que este protocolo es irrompible a día de hoy mientras las claves
privadas no sean comprometidas. Ataques por fuerza bruta o de tipo Man-in-
the-middle no surten ningún efecto. Si el servidor no tiene certificado o no es
vulnerable a ataques Man-in-the-middle. Esto es así sencillamente porque no
hay nadie de confianza que avale la identidad del extremo opuesto. En
condiciones normales, con certificado de servidor válido, un ataque a este
protocolo es imposible probabilísticamente.
Ya se han visto las herramientas de que se disponen y ahora verá su
aplicación en redes inalámbricas. Hay que tener muy presente el
funcionamiento del protocolo TLS, el manejo de ciertos términos y siglas de
algoritmos y demás. Todo lo que se ha visto es un entorno abstracto con
utilidad en cualquier sistema, sea cual sea el nivel físico, de red y de
aplicación. Se puede utilizar TLS para intercambiar correo con Mozilla de forma
cifrada y sobre una red ATM o diseñar una red Peer-to-Peer que utilice
certificación. El protocolo TLS es un estándar que seguramente perdurará
aunque los algoritmos matemáticos queden obsoletos y hace que cualquiera
pueda realizar todo tipo de transacciones y consultas con servidores en
Internet de forma totalmente segura. Además lo normal es que navegadores
web, clientes de correo y demás abstraigan de estas cosas a los usuarios con