Artículo
· 16 jun, 2023 Lectura de 3 min

Cómo depurar comunicaciones http (y https)

Introducción

Si alguna vez os habéis preguntado cómo depurar algunas solicitudes que se realizan hacia o desde IRIS, este es un pequeño tutorial sobre cómo se hace.

Durante un proyecto complejo, normalmente se obtienen las especificaciones y se implementa la comunicación entre IRIS y otros sistemas basándose en eso. Pero del papel al mundo real normalmente hay un gran trecho y hay que saber por qué se recibe un error en un parámetro o en una cabecera, por qué no se reciben los datos, etc.

Si la conexión es una conexión http sencilla, no hay problema, siempre se puede iniciar tcpdump y capturar el tráfico, pero ¿qué pasa con la comunicación https?

¿Qué tal tener una interfaz web limpia, algo que iniciáis y después el desarrollador puede mirar ese portal cuando quiera?

Si alguna vez habéis estado en esta situación, una solución sencilla es mitm proxy ( https://mitmproxy.org/ ).

Este programa tiene la capacidad de actuar como un proxy (se puede configurar en el Business Operation, por ejemplo), un proxy transparente (lo que me gusta), proxy upstream (proxy transparente que envía la conexión a otro proxy), etc.

Configuración

Para configurarlo:

  • solo hay que descargar el archivo de la página de descarga
  • copiarlo en el servidor con IRIS (en el mismo servidor es más fácil de configurar, pero también puede ser en otro servidor).
  • una vez copiado, extraer el archivo a un directorio (e.g. mitm)

Iniciar MITMProxy

Sugeriría tener tmux o screen instalado y hacer un script para el inicio, para que pueda ser interrumpido.

#!/bin/bash

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.conf.all.send_redirects=0


iptables -t nat -A OUTPUT -d THE_DESTINATION_IP -p tcp --dport 443 -j REDIRECT --to-port 46465

SSLKEYLOGFILE="$PWD/.mitmproxy/sslkeylogfile.txt" ./mitmweb --mode transparent --no-anticache --listen-port 46465 --web-host THE_SERVER_IP --web-port 46464 --ssl-insecure --server -w /tmp/`date +%Y%m%d_%H%M_mitmproxy.dump` 

iptables -t nat -D OUTPUT -d THE_DESTINATION_IP -p tcp --dport 443 -j REDIRECT --to-port 46465

firewall-cmd --reload

sysctl -w net.ipv4.ip_forward=0
sysctl -w net.ipv6.conf.all.forwarding=0
sysctl -w net.ipv4.conf.all.send_redirects=1

Para iniciarlo:

  • abrir tmux o screen
  • iniciar el script

MITMProxy en ejecución

Ahora se puede acceder a la página web (al iniciar mitm os da el enlace) y revisar todas las solicitudes capturadas en el "sniffer".

Podéis elegir una solicitud individual, ver los encabezados y el cuerpo, la respuesta, etc.

Parar MITMProxy

  • solo hay que recuperar la sesión tmux o screen
  • interrumpir el script con ctrl+c

Para terminar

Esta es una herramienta muy muy potente, se puede utilizar de muchas formas y es muy útil para la depuración de comunicaciones.

La documentación está muy bien escrita, la podéis encontrar aquí: https://docs.mitmproxy.org/stable/

Ha ayudado mucho en muchas situaciones en los últimos 2 años, por lo que he escrito este artículo esperando ayudar a otros con las mismas necesidades.

Preguntas frecuentes

El nombre de esta herramienta es MITM, que significa "Man In The Middle". ¿Es algo malo?

No... y sí. MITM es una práctica común de ciberseguridad que puede utilizarse para cosas buenas (como la que hemos explicado aquí), pero también para cosas muy malas. Así que hay que mantenerla segura, en un entorno de desarrollo. Hemos parado en la superficie de lo que esta herramienta puede hacer, puede reescribir total o parcialmente la solicitud/respuesta y muchas otras cosas turbias.

La conexión SSL "no puede" ser interceptada pero las estamos visualizando en esta herramienta, ¿cómo es posible?

El MITMProxy realiza un "ataque" MITM (¿queeeeeé?), así que:

  • la conexión ssl se inicia desde IRIS
  • va al MITM Proxy que dice "¡eh, soy el servidor de destino!"
  • la conexión SSL termina allí y la solicitud es desencriptada y mostrada en MITMProxy
  • el proxy contacta con el servidor de destino diciendo "soy el servidor de origen"
  • el proxy envía la solicitud en https

Sí, si todo se configura con los certificados ssl correctos, los resultados son increíbles.

Comentarios (0)1
Inicie sesión o regístrese para continuar