HTTP, HTTPS y TLS: Parte 13 — Intercepción de HTTPS para depuración: DevTools, archivos HAR y mitmproxy

curl muestra lo que enviaste tú mismo, y tcpdump y Wireshark (Resolución de problemas de red para principiantes: Parte 5 — tcpdump, sngrep y Wireshark) — paquetes, pero sin descifrado de HTTPS. Pero a menudo hace falta ver qué envía un cliente ajeno: el navegador cuando falla un formulario, una aplicación móvil que no puede alcanzar la API, un programa que se comporta de forma distinta a la documentada. Para eso se intercepta el tráfico: en el navegador — con las herramientas de desarrollador integradas; para otros programas — con un proxy que descifra HTTPS. Todo lo descrito aplica a dispositivos y programas propios o a sistemas cuyo análisis cuenta con permiso.

Pestaña Network en el navegador

Las herramientas de desarrollador se abren con F12 (en macOS — Cmd+Option+I). En la pestaña Network se ven todas las solicitudes de la página: dirección, método, código de respuesta, tipo, tamaño, tiempo.

Ajustes útiles en la parte superior de la pestaña:

• Preserve log — no borrar la lista al navegar a otra página. Sin esto no verás la solicitud del formulario después de la cual hay un redireccionamiento;
• Disable cache — cargar todo desde el servidor mientras las herramientas están abiertas;
• Throttling — emulación de red lenta (Fast 4G, Slow 3G) y funcionamiento sin red;
• filtro Fetch/XHR — sólo solicitudes JavaScript al API; la barra de búsqueda entiende condiciones como status-code:500, method:POST, domain:api.example.ru, larger-than:1M.

Al hacer clic en una solicitud se abren pestañas:

• Headers — encabezados de la solicitud y la respuesta, dirección final, dirección del servidor;
• Payload — parámetros de la cadena de consulta y cuerpo del formulario o JSON;
• Preview / Response — la respuesta en forma interpretada y en crudo;
• Timing — desglose del tiempo: espera en cola, DNS, conexión, TLS, espera de respuesta del servidor (TTFB), descarga. La misma información que -w en curl;
• Initiator — qué script o elemento de la página provocó la solicitud.

La columna Protocol (clic derecho en el encabezado de la tabla) conviene activarla siempre: ahí se ve h2, h3 o http/1.1.

La solicitud se puede copiar para repetirla: Copy → Copy as cURL (como comando curl con todos los encabezados y cookies) o Copy as fetch (como código JavaScript para la consola).

Errores CORS en la consola del navegador aparecen como fallos de red, y en Network la solicitud tiene el estado CORS error. Fíjate en la solicitud previa OPTIONS junto a ella: la mayoría de las veces recibió 401, 404 o una respuesta sin los encabezados Access-Control-Allow-*.

Certificado y TLS. La pestaña Security (en Chrome) muestra la versión de TLS, el grupo de intercambio de claves, el cifrado y el certificado de la página actual, así como recursos cargados por HTTP.

Archivos HAR

HAR (HTTP Archive) — archivo JSON con todas las solicitudes y respuestas de la sesión, incluidos encabezados, cuerpos y tiempos. El soporte técnico de servicios lo solicita cuando es necesario reproducir un problema en su entorno. Guardar: en la pestaña Network — botón con una flecha hacia abajo (Export HAR) o clic derecho → Save all as HAR.

En un HAR van contraseñas y sesiones. El archivo contiene cookies, encabezados Authorization, tokens en las direcciones y cuerpos de formularios, incluido el password introducido. Enviar tal archivo es equivalente a dar acceso a tu cuenta: en 2023 atacantes accedieron a clientes de Okta precisamente a través de HAR enviados en tickets al soporte.

Desde Chrome 130 la exportación por defecto está «sanitizada» (sanitized): sin Cookie, Set-Cookie y Authorization. La versión completa sólo se puede obtener tras habilitar la opción Allow to generate HAR with sensitive data. Pero la limpieza no elimina tokens en las direcciones, en los cuerpos de las solicitudes ni en encabezados propios (X-Api-Key). Antes de enviar abre el archivo en un editor y busca token, key, password, session. Después de depurar cierra sesión para que la sesión del archivo quede inválida.

Ver un HAR se puede hacer en la misma pestaña Network (arrastrando el archivo a la ventana) o en el visor online Google Admin Toolbox HAR Analyzer.

Proxy interceptador: cómo funciona

Para programas fuera del navegador hace falta un proxy que se sitúe entre el cliente y el servidor y descifre HTTPS. La opción libre más extendida es mitmproxy; también existen Charles, Proxyman (macOS), HTTP Toolkit, Burp Suite.

Esquema:

1. El cliente se conecta al proxy, no al servidor.
2. El proxy se conecta al servidor por TLS y comprueba su certificado real.
3. Al cliente el proxy le presenta un certificado para el mismo nombre, emitido al vuelo por su propia autoridad certificadora.
4. Si el cliente confía en esa autoridad, el proxy tiene dos conexiones descifradas y ve y puede modificar todo lo que pasa entre ellas.

La condición principal es el certificado raíz del proxy instalado en el dispositivo. Sin él el cliente verá un certificado falso y cortará la conexión — exactamente como TLS debe operar.

mitmproxy

Instalación — brew install mitmproxy, pipx install mitmproxy o la imagen Docker mitmproxy/mitmproxy. Tres interfaces:

• mitmproxy — interfaz interactiva en el terminal;
• mitmweb — interfaz web en http://127.0.0.1:8081;
• mitmdump — sin interfaz, para grabar y usar con scripts.

Por defecto el proxy escucha en el puerto 8080. Al primer arranque mitmproxy crea su autoridad certificadora en ~/.mitmproxy/.

Comprobación con curl:

mitmweb &
curl -x http://127.0.0.1:8080 --cacert ~/.mitmproxy/mitmproxy-ca-cert.pem https://example.ru/

La solicitud aparecerá en la interfaz web con todos los encabezados y el cuerpo.

Instalación del certificado. Configura en el dispositivo el proxy IP-del-ordenador:8080 y abre en el navegador http://mitm.it — página servida por mitmproxy con el certificado e instrucciones para cada sistema.

• iOS: instalar el perfil, luego activar la confianza completa en Ajustes → General → Información → Confiar en certificados.
• Android: desde la versión 7 las aplicaciones por defecto no confían en certificados instalados por el usuario, sólo en los del sistema. Chrome confía, la mayoría de apps no. Para tu propia app la confianza en certificados de usuario se habilita en network_security_config.xml de la build de depuración; para apps ajenas necesitas un emulador o un dispositivo con root donde el certificado se coloque en el almacén del sistema.
• Windows y macOS: importar al almacén de certificados raíz del sistema. Firefox usa su propio almacén — hay que añadir el certificado en sus opciones.

Modos de funcionamiento. Además del proxy habitual, mitmproxy puede:

• --mode wireguard — levanta un servidor WireGuard; el dispositivo se conecta a él como VPN mediante un QR code desde mitmweb, y todo su tráfico pasa por mitmproxy sin configurar proxy. Conveniente para teléfonos y apps que ignoran el proxy del sistema;
• --mode local — interceptar programas en el mismo equipo sin configurar proxy: mitmproxy --mode local:curl — sólo curl, --mode local:!curl — todo excepto curl;
• --mode reverse:https://api.example.ru — proxy inverso delante de un servidor concreto;
• --mode transparent — interceptación transparente junto con reglas de redirección en el firewall.

Modificar solicitudes. Un script en Python sustituye solicitudes y respuestas al vuelo — útil para comprobar cómo la aplicación soporta una caída del servidor sin tocar el servidor:

# fail.py — devolver 503 en solicitudes a /api/orders
from mitmproxy import http

def request(flow: http.HTTPFlow) -> None:
    if flow.request.pretty_url.startswith("https://api.example.ru/api/orders"):
        flow.response = http.Response.make(503, b'{"error":"maintenance"}',
                                           {"Content-Type": "application/json"})

mitmdump -s fail.py

Grabar la sesión y reproducirla después: mitmdump -w flows.mitm, luego mitmproxy -r flows.mitm. Exportar a HAR — mitmdump -n -r flows.mitm --set hardump=flows.har (-n — no arrancar el proxy, sólo procesar el archivo).

Ejemplo completo: cómo la aplicación soporta la caída de la API

Tarea: comprobar que la aplicación móvil muestra un mensaje comprensible y no se cae cuando la API de pedidos responde 503. No se puede tocar el servidor. Probado con mitmproxy 12.2.

1. Script de sustitución — archivo fail.py del apartado anterior, con la dirección cambiada por la de tu API.

2. Arranque con grabación de la sesión:

mitmweb -s fail.py -w flows.mitm --mode wireguard

mitmweb abrirá la interfaz web y mostrará un QR code con la configuración de WireGuard.

3. Teléfono. Instala la app WireGuard, escanea el QR code y activa el túnel. Abre en el teléfono http://mitm.it, instala el certificado y activa la confianza en él (para iOS — en «Confiar en certificados», para Android — sólo si es la build de depuración de tu app o un emulador).

4. Comprobación del interceptado. Abre cualquier sitio en el navegador del teléfono — la solicitud aparecerá en mitmweb. Si el sitio no carga por un error de certificado, no está activada la confianza en el certificado.

5. Escenario. Abre en la app la lista de pedidos. En mitmweb la solicitud a /api/orders tendrá la respuesta 503 del script, y la app debería mostrar un mensaje de error y proponer reintentar.

6. Revisión. Tras la comprobación detén mitmweb (Ctrl+C) y mira la grabación:

mitmproxy -r flows.mitm                                # interactivo
mitmdump -n -r flows.mitm --set hardump=flows.har      # a HAR — p. ej., adjuntar al ticket

7. Limpieza. Desactiva el túnel WireGuard, borra el perfil de certificado del teléfono. Los archivos flows.mitm y flows.har contienen tokens de la aplicación — elimínalos o guárdalos como secretos.

Probar el script sin teléfono se puede desde la línea de comandos:

mitmdump -s fail.py &
curl -x http://127.0.0.1:8080 --cacert ~/.mitmproxy/mitmproxy-ca-cert.pem https://api.example.ru/api/orders
# {"error":"maintenance"}

Cuando la interceptación no funciona

Pinning. La aplicación comprueba el certificado del servidor no sólo frente al almacén del sistema, sino también contra una lista integrada de claves. El certificado del proxy no superará esa comprobación y la app rechazará la conexión, incluso si el certificado raíz está instalado. Así actúan apps bancarias, mensajerías y apps de grandes servicios. En tu propia app el pinning se desactiva en la build de depuración. En apps ajenas se evita con herramientas de instrumentación dinámica como Frida — eso ya es análisis de una app protegida y sólo está permitido con permiso de su propietario.

Protocolos no HTTP. Apps que usan QUIC, protocolos propios sobre TCP o UDP, gRPC con configuraciones no estándar, pueden no funcionar via proxy HTTP. Para HTTP/3 los navegadores en ese caso suelen degradar a TCP; las versiones nuevas de mitmproxy son capaces de trabajar con HTTP/3, pero no en todos los modos.

La app ignora el proxy del sistema. Muchos programas no leen la configuración de proxy del sistema: apps en Go miran sólo las variables de entorno HTTPS_PROXY, apps Java — parámetros propios de la JVM. Ayuda el modo WireGuard o el modo transparente — interceptan el tráfico a nivel de red.

Huella TLS. El servidor ve la huella TLS del proxy, no de la app. Si el servidor está protegido contra bots por JA3/JA4, las solicitudes vía proxy pueden recibir captcha o 403, aunque la app funcionase directamente.

Seguridad tras la depuración

• Borra el certificado raíz del proxy del dispositivo cuando termines. La clave privada de esa autoridad está en ~/.mitmproxy/ en tu ordenador, y quien la consiga podrá descifrar el tráfico de cualquier dispositivo que le confíe ese certificado.
• No dejes mitmproxy escuchando en todas las interfaces en una red pública: un proxy sin contraseña es un proxy abierto. El parámetro --set proxyauth=user:pass establece autenticación.
• Las sesiones grabadas y los archivos HAR contienen contraseñas y tokens — trátalos como secretos y elimínalos.