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.
![]() |
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.
![]() |
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.
![]() |
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.
![]() |
|
|
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).
![]() |
|
|
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.
![]() |
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.
![]() |
Figura 7.
Server Hello |
- Change Cipher Spec -> Simplemente un mensaje que indica que se está intercambiando la especificación de cifrado.
![]() |
Figura 8. Change Cipher Spec servidor |
- Application Data -> Datos de aplicación cifrados.
![]() |
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.
![]() |
Figura 10.
Application Data servidor (2) |
El último mensaje es enviado hacia el servidor Change Cipher Spec, Application Data.
![]() |
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.
![]() |
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.
Este post está también disponible en inglés en "Decrypt HTTPS (TLS) traffic using the SSL Key Log File | Wireshark @Windows 10".
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
ResponderEliminarHola Santiago! Perdona por la tardanza.
ResponderEliminarRespecto 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!
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