viernes, 12 de marzo de 2021

Descifrar tráfico HTTPS (TLS) mediante el SSL Key Log File | Wireshark @Windows 10

Para llevar a cabo la práctica que, en lo que sigue, se desarrollará se precisarán los servicios de una herramienta de captura de tráfico de red. En lo particular decidí usar Wireshark, puede descargarla desde su web oficial https://www.wireshark.org/#download. Su instalación es sencilla y es de uso gratuito.

Descifrado de tráfico TLS con fichero de registro de claves

1. Introducción teórico-conceptual

Para facilitar la comprensión de lo que se explicará a continuación se introducirán algunos términos que serán recurrentes en esta demostración práctica. Así mismo, se deja a disposición del lector una representación esquemática del modelo TCP/IP orientada al contenido de este post.


modelo tcp ip
Figura 1. Modelo TCP/IP contextualizado

1.1. Protocolos HTTP y HTTPS

Ambos protocolos pertenecen al nivel de aplicación dentro de la jerarquía establecida en el modelo TCP/IP (véase la figura 1). La principal diferencia es que HTTPS proporciona una comunicación segura en la que el flujo de información está encriptado. Así se evita la interpretación de datos sensibles en caso de ser interceptados.

Por el contrario, HTTP deja ver en texto claro el contenido transferido, dejando expuesta cualquier tipo de información confidencial (imágenes, documentos, contraseñas...) o no. Esto también ocurre con FTP, SMTP, NNTP, POP, IMAP, TELNET y RLOGIN.

HTTPS debe su principal característica a TLS, un protocolo del nivel de transporte. Este permite establecer un intercambio de paquetes seguro

1.2. Protocolo TLS

TLS es un protocolo seguro de la capa de transporte y basa su funcionamiento en el uso de certificados digitales. Un certificado digital no es más que un documento que legitima la autenticidad de un equipo o entidad gracias a que una CA (Certificate Authority) ha firmado su clave pública.

1.2.1. Certificados digitales

Pongamos como ejemplo a blogger.com. Esta entidad tiene a su disposición una public key y una private key. Blogger se identifica con la primera ("Hola, yo soy blogger.com") pero, ¿puedo estar seguro de que es realmente quien dice ser? Aquí entran en juego las CA.

ruta certificado digital blogger
Figura 2. Directorio de certificados de blogger.com

GTS AC (Google Trust Services Certificate Authority) se ha encargado de verificar la identidad de blogger.com. Así que le entrega un certificado en el que figura su clave pública firmada por él (entre otra mucha información).

Google ha firmado la clave pública de blogger.com con su propia clave privada. Se puede decir que estas sirven para realizar "tareas privadas y delicadas" (firmar, descifrar información...). Por ello es indispensable velar por su confidencialidad.

1.2.2. TCP y TLS Handshakes

Existe un procedimiento que fija el cifrado del tráfico e intercambio de claves entre equipos conocido como TLS Handshake (apretón de manos). Este viene precedido de un TCP Handshake que se encarga realizar el establecimiento de la comunicación. 

Handshake Wireshark TCP TLS
Figura 3. Captura del handshake

En la figura 3 se muestra el flujo de paquetes TCP/TLS analizado para explicar este estrechamiento de manos. Forma parte de la captura de ejemplo que se usará en esta entrada y que se estudiará más adelante. Como se aprecia, el TLS Handshake sucede al TCP Handshake.

tls handshake grafico
Figura 4. TCP Handshake

En el estrechamiento de manos TCP (véase la figura 4) se envía un paquete inicial con el flag SYN activo. Si el destino responde con un SYN-ACK, quiere decir que se encuentra disponible, a lo que nosotros volveremos a responder con un ACK (una mera confirmación).

Para saber más sobre los flags o banderas de los paquetes TCP, puedes echar un vistazo a este post.

Después de haber establecido la conexión cliente-servidor, se abre paso al apretón de manos TLS, que se encargará de intercambiar las especificaciones necesarias para cifrar la conexión de datos y hacerla más segura.

La información visible en este procedimiento es limitada pues, hasta que no lo descifremos más adelante, no podremos visualizar ciertos datos de aplicación cifrados (Encrypted Application Data en Wireshark).

tls handshake grafico
Figura 5. TLS Handshake

En este proceso ambas máquinas acuerdan ciertos detalles que condicionarán de qué modo se cifrará la conexión. Este no siempre resulta en esta secuencia exacta pero, para este ejemplo, será así. Algunos de los datos comunes a todas estas tramas son:

  • Content Type -> tipo de contenido (Handshake/Change Cipher Spec)
  • Length -> tamaño en bytes del paquete.
  • Version -> versión de TLS más alta soportada por el cliente / servidor.

Cada uno de ellos aporta algo de información relevante. Client Hello ofrece un conjunto de suites de cifrado, ID de sesión, una clave random y un largo etc. 

client hello tls handshake
Figura 6. Client Hello

Los siguientes dos mensajes que son enviados por el servidor son, por un lado Server Hello, Change Cipher Spec, Application Data.

  • Server Hello -> Se indica la suite de cifrado seleccionada, principalmente.
server hello tls handshake
Figura 7. Server Hello
  • Change Cipher Spec -> Simplemente un mensaje que indica que se está intercambiando la especificación de cifrado.
server cipher spec
Figura 8. Change Cipher Spec servidor
  • Application Data -> Datos de aplicación cifrados.
datos cifrados tls 1
Figura 9. Application Data servidor (1)

Por otro lado tenemos Application Data, Application Data, Application Data, Application Data (Segundo mensaje enviado por el servidor -> 151.101.1.16). Como es evidente, este mensaje está cifrado y aún no podemos visualizar parte de la información que contiene.

datos cifrados tls 2
Figura 10. Application Data servidor (2)

El último mensaje es enviado hacia el servidor Change Cipher Spec, Application Data.

cipher spec 2
Figura 11. Change Cipher Spec y Application Data cliente

Para ver información más detallada sobre la razón de ser de estos campos y otros muchos, recomiendo visitéis https://blog.catchpoint.com/2017/05/12/dissecting-tls-using-wireshark/.

1.3. SSL Key Log File

El archivo SSL Key Log es un fichero de texto en el que se almacenan claves de sesión TLS que han sido utilizadas por tu navegador al acceder a un sitio web. Estas son necesarias para descifrar el tráfico interceptado. Por seguridad, solo es posible generar este fichero en un usuario al mismo tiempo.

En Windows puede hacerse desde las variables del entorno. Creamos una nueva variable para nuestro usuario que obedezca al nombre de SSLKEYLOGFILE y la ubicamos en la ruta que deseemos: ruta\deseada\nombrefichero.log.

ssl key log windows
Figura 12. Variable de usuario SSLKEYLOGFILE

Ahora deberíamos tener un fichero de texto en la ubicación señalada que irá actualizándose con las diferentes claves que nuestro navegador vaya procesando. Si no aparece, prueba a reiniciar el ordenador. Luce tal que así:

Figura 13. SSLKEYLOGFILE

2. Capturando tráfico cifrado con Wireshark

Para este ejemplo he capturado el tráfico resultante de cargar el contenido de una página web:  https://www.xataka.com/categoria/seguridad. El resultado recoge ciertas tramas cifradas que descifraremos a continuación para ver qué información adicional puede visualizarse.

2.1. Descifrando el tráfico HTTPS capturado con el SSL Key Log File

Necesitamos indicar a Wireshark donde se encuentra el sskley que generamos hace un momento. Con él será capaz de descifrar ciertos campos de algunas tramas que antes no podíamos ver.

Para ello nos dirigimos a Edición>Preferencias>Protocols>TLS y hacemos click en explorar dentro del campo Pre-Master-Secret log filename. Seleccionamos el fichero de registros y ya habremos cargado lo necesario.

2.2. Análisis y comprensión de las tramas resueltas

En primer lugar se muestra el flujo TLS (cifrado) sobre el que llevamos ejemplificando todo este tiempo.

Figura 14. Flujo TLS cifrado

Como ya comentamos antes hay mucha información oculta y cuya naturaleza no podemos conocer. Tras descifrar el tráfico veremos cambios significativos.

Figura 15. Flujo TLS descifrado

Ahora visualizamos ciertos campos de los paquetes que circulaban en el TLS Handshake que antes aparecían como Application Data.

  • Encrypted Extensions
Figura 16. Encrypted Extensions

Observad el campo de abajo a la izquierda de la imagen donde dice Decrypted TLS.

  • Certificate y Certificate Verify -> El servidor muestra su certificado digital para que el cliente pueda verificarlo.
  • Finished -> Indica que cliente y/o servidor están listos.
  • New Session Ticket -> Ticket de sesión de tiempo limitado para el uso de las claves random de cliente y servidor y la pre-master secret key.
Figura 17. Certificate, Certificate Verify, Finished y New Session Ticket

El modo en que procede este handshake variará según el algoritmo de cifrado empleado. En este caso se está usando TLS_AES_128_GCM_SHA256.

3. Aplicaciones y utilidades de su buena praxis

La principal aplicación de este tipo de prácticas es la monitorización del tráfico circulante en una red privada, por ejemplo una empresa. Así se puede controlar qué información sale y entra de dicha red de forma cifrada. Algunas de sus utilidades en el ámbito empresarial son las siguientes:

  • Detectar posibles intrusiones de software malicioso.
  • Prevenir fugas de datos confidenciales.
  • Definir políticas de monitoreo basadas en reglas para determinar qué tipo de información se descifrará (y así hacer el proceso más óptimo).

4. Referencias

Eulises Ortiz, Ángel. (2019). ¿Qué es el desencriptado SSL / TLS? (HostDime). Recuperado de: https://www.hostdime.com.pe/blog/que-es-el-desencriptado-ssl-tls en marzo de 2021.

CloudFlare. (2019). What Happens in a TLS Handshake? | SSL Handshake. (CloudFlare). Recuperado de: https://www.cloudflare.com/es-es/learning/ssl/what-happens-in-a-tls-handshake en marzo de 2021.

CloudShark. (2020). All about SSL key logging. (CloudShark). Recuperado de: https://cloudshark.io/articles/2015-05-14-all-about-ssl-key-logging en marzo de 2021.

GlobalKnowledge. (2012). What is the Difference Between Ethernet II and IEEE 802.3? (GlobalKnowledge). Recuperado de: https://www.globalknowledge.com/us-en/resources/resource-library/articles/what-is-the-difference-between-ethernet-ii-and-ieee-8023/#gref en marzo de 2021.

Vivekananda, Vidhatha. (2017). Dissecting TLS Using Wireshark. (Catchpoint). Recuperado de: https://blog.catchpoint.com/2017/05/12/dissecting-tls-using-wireshark en marzo de 2021.

3 comentarios:

  1. hola, se puede considerara como una vulnerabilidad o como una herramienta o métodos que ayudan a monitorear la seguridad. ? Particularmente considero que no es una vulnerabilidad no tiene un CVE conocido pero considero oportuno saber su criterio al respecto y por eso la consulta

    ResponderEliminar
  2. Hola Santiago! Perdona por la tardanza.

    Respecto a si podría considerarse una vulnerabilidad el hecho de ser capaz de descifrar tráfico HTTPS diría que al menos para este caso no, porque la información que estamos "extrayendo" del flujo de datos capturado es muy poco sensible (certificados empleados en el handshake, cipher suites empleados, etc). Seguramente existan muchas otras técnicas más complejas y eficaces con las que, tal vez, podría conseguirse información "valiosa" si el tráfico capturado es el adecuado para ello.

    Respecto a tu segunda pregunta por supuesto que sí, es un modo muy interesante de monitorear el tráfico en una determinada red tal y como menciono en el post.

    Un saludo!

    ResponderEliminar
    Respuestas
    1. Sí que es cierto que ciertas implementaciones de HTTPS en algunos sitios web presentan algunas vulnerabilidades a causa de una mala implementación del cifrado TLS. De ser explotadas, sí que se podrían realizar ataques MITM eficaces.

      Eliminar