Mitmproxy 11: soporte completo para HTTP/3

 (mitmproxy.org)
3 puntos por GN⁺ 2024-10-06 | 1 comentarios | Compartir por WhatsApp
  • A medida que aumenta la proporción de tráfico QUIC y HTTP/3, mitmproxy 11 activa HTTP/3 por defecto para ampliar el alcance del análisis del tráfico web moderno
  • HTTP/3 funciona no solo en proxy transparente y proxy reverso, sino también en WireGuard y local mode, por lo que puede aplicarse en distintos entornos de captura
  • Chrome no confía en una Certificate Authority agregada por el usuario en QUIC, por lo que hay que elegir entre un certificado de confianza pública, un interruptor de línea de comandos o el fallback a HTTP/2
  • La implementación de DNS cambia a una basada en Hickory DNS, y maneja consultas más allá de A/AAAA, HTTPS records, DNS-over-TCP, control del archivo hosts y eliminación de claves ECH
  • Funciones de privacidad como ECH dificultan el flujo de generación de certificados de un proxy man-in-the-middle, pero mitmproxy mantiene la posibilidad de funcionar ajustando las respuestas DNS

Alcance del soporte de HTTP/3

  • mitmproxy 11 soporta HTTP/3 en los modos de proxy transparente y proxy reverso
  • En el proxy reverso, una sola instancia de mitmproxy recibe paquetes TCP y UDP y maneja la versión de HTTP que se transfiera
  • También se puede usar HTTP/3 en WireGuard y local mode
    • Comandos de ejemplo: 
      mitmproxy --mode wireguard
mitmproxy --mode local
  • Se probó con Firefox, Chrome, varias compilaciones de cURL y otros clientes para reducir problemas de compatibilidad
  • El trabajo de soporte para HTTP/3 fue iniciado en 2022 por Manuel Meitinger y Maximilian Hils, y en mitmproxy 11 queda activado por defecto

Restricciones de certificados QUIC en Chrome

  • La principal limitación conocida actualmente es que Chrome no confía en una Certificate Authority agregada por el usuario en QUIC
  • Para manejar tráfico HTTP/3 en Chrome, se necesita una de las siguientes opciones
    • Proveer un certificado de confianza pública, como Let’s Encrypt
    • Ejecutar Chrome con el interruptor de línea de comandos correspondiente
    • Aceptar que el comportamiento haga fallback a HTTP/2
  • Firefox no presenta este comportamiento
  • Puedes consultar consejos para resolver problemas de HTTP/3 en #7025

Reimplementación basada en Hickory DNS

  • Con la aparición de funciones de privacidad como DNS HTTPS records y Encrypted Client Hello(ECH), ha aumentado la importancia del procesamiento DNS en mitmproxy
  • La implementación anterior de DNS tenía limitaciones porque usaba getaddrinfo
    • Solo soportaba consultas A/AAAA para direcciones IPv4 e IPv6
    • No podía responder a consultas como HTTPS records que anuncian soporte para HTTP/3
  • mitmproxy 11 reimplementa el soporte DNS sobre Hickory DNS, una biblioteca DNS escrita en Rust
  • A través de Hickory, obtiene los servidores de nombres predeterminados del sistema operativo en Windows, Linux y macOS, y reenvía a esos servidores las consultas que no sean A/AAAA
  • La nueva opción dns_name_servers permite especificar a qué servidores de nombres reenviar 
    mitmdump --mode dns --set dns_name_servers=8.8.8.8

Control del archivo hosts y DNS-over-TCP

  • Junto con el cambio a Hickory, se añadió una opción para ignorar el archivo hosts del sistema
  • La nueva opción dns_use_hosts_file permite controlar si se reflejan archivos hosts como /etc/hosts en Linux
  • También está previsto mover la resolución DNS interna de mitmproxy a Hickory, y después esta función será útil al redirigir de forma transparente dominios específicos en la misma máquina
    • Actualmente, como siempre se considera el archivo hosts, mitmproxy puede conectarse recursivamente a sí mismo en configuraciones de redirección sobre la misma máquina
  • Ejemplo de funcionamiento: 
    echo "192.0.2.1 mitmproxy.org" >> /etc/hosts
mitmdump --mode dns
dig @127.0.0.1 +short mitmproxy.org
192.0.2.1
mitmdump --mode dns --set dns_use_hosts_file=false
dig @127.0.0.1 +short mitmproxy.org
3.161.82.13
  • DNS usa UDP por defecto, pero puede requerirse TCP al manejar registros que no caben en un solo paquete UDP
  • Como mitmproxy 11 soporta tipos de consulta arbitrarios, aumentó la importancia del tamaño de los mensajes y del manejo por TCP, y DNS-over-TCP también funciona

Eliminación de claves ECH y generación de certificados

  • Cuando no hay un certificado personalizado, mitmproxy usa el Server Name Indication(SNI) del TLS ClientHello para construir un certificado válido
  • Si no hay SNI, puede que no sea posible generar un certificado en el que el cliente confíe
  • Encrypted Client Hello(ECH) es un método en el que el cliente obtiene una clave ECH mediante DNS HTTPS records y luego cifra con esa clave el mensaje inicial de handshake ClientHello
  • Si tanto la consulta DNS como el handshake están cifrados, un intermediario pasivo no puede conocer el dominio de destino y solo puede verificar la dirección IP de destino
    • En hosting compartido y redes de distribución de contenido, es difícil determinar el dominio objetivo solo con la dirección IP
  • Esta mejora de privacidad entra en conflicto con la forma en que mitmproxy genera certificados
  • mitmproxy 11 elimina las claves ECH de los HTTPS records para asegurar la información de dominio necesaria para la generación de certificados
    • El cliente no puede obtener la clave para cifrar el mensaje inicial de handshake
    • mitmproxy puede identificar el dominio de destino y construir un certificado coincidente
  • ECH puede hacer más difícil el uso de mitmproxy, pero también puede verse como un cambio que mejora la privacidad en toda la web

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-06
Opiniones en Hacker News

  • Me alegra que Mitmproxy todavía se siga desarrollando. Esta herramienta, de forma indirecta, construyó mi carrera.
    En 2011 estaba aprendiendo desarrollo de APIs interceptando solicitudes de apps móviles, y descubrí que la API de Airbnb estaba expuesta a una vulnerabilidad de asignación masiva de Rails (https://github.com/rails/rails/issues/5228). Después de cambiar algunas propiedades inofensivas, contacté a la empresa, eso llevó a una entrevista, y el resto es literalmente historia.

    • La cantidad de desarrolladores principales que se oponían al cambio en ese issue era realmente absurda.
    • A mí me sigue siendo enormemente útil, pero sorprende cuánta gente que uno esperaría que lo conociera no conoce bien Mitmproxy.
      A veces es más fácil conectar mitmproxy a una implementación existente que leer la documentación.

  • Me parece interesante que Chrome no confíe en autoridades certificadoras agregadas por el usuario en QUIC.
    En el issue vinculado, el equipo de Chrome dice: “No permitimos explícitamente certificados que no sean de confianza pública para evitar el despliegue de software/hardware de interceptación de QUIC. De lo contrario, a largo plazo se perjudica la capacidad de evolución del protocolo QUIC. Los usos que dependan de certificados que no sean de confianza pública pueden usar TLS+TCP en lugar de QUIC”.
    No sigo la evolución del protocolo, pero no entiendo bien cómo bloquear certificados personalizados se relaciona con la capacidad de evolución. Me pregunto si alguien sabe la razón.

    • Si tuviera que especular, creo que como Google controla tanto el cliente como grandes endpoints de servidor (Google Search, Youtube, etc.), quiere tener libertad para hacer experimentos con cambios en QUIC.
      Puede incluir en Chrome una versión ligeramente modificada de QUIC, soportarla en sitios como Youtube, y luego, con esas métricas, proponer un cambio al estándar “real” o seguir usando una versión especial solo en sus servicios.
      Si se permiten certificados personalizados, las empresas que inspeccionan el tráfico de empleados mediante un intermediario, con cosas como ZScaler ZIA, corren el riesgo de romperse cuando cambie el protocolo. Si el flujo de datos está totalmente cifrado y es opaco para los equipos intermedios, Google puede hacer casi lo que quiera.
      Concepto relacionado: https://en.wikipedia.org/wiki/Protocol_ossification
    • Los equipos intermedios (https://en.m.wikipedia.org/wiki/Middlebox) son una causa bien conocida del estancamiento de protocolos.
      En un protocolo extensible, normalmente basta con actualizar cliente y servidor, pero si hay equipos intermedios, potencialmente también hay que actualizar N dispositivos. Los usuarios y proveedores de servicios tienen incentivos para adoptar nuevas funciones, pero los dueños de los equipos intermedios quizá no. Como resultado, se vuelve difícil que el protocolo evolucione.
    • También podría estar refiriéndose al famoso caso de las instituciones financieras que se opusieron a TLS 1.3. Su motivación era no querer actualizar el software de intermediación necesario para cumplir con regulaciones: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA/
    • Una de las razones por las que se crearon HTTP/2 y HTTP/3 también fue que cambiar HTTP 1.1 era demasiado difícil.
      Había mucho middleware que dependía fuertemente de detalles de implementación, así que con cambiar un poco algo era fácil romper sin querer la experiencia del usuario. Parece que en las nuevas versiones intentan evitar una situación parecida.
    • QUIC existe para aumentar la tasa de entrega de anuncios, así que dar libertad al usuario entra en conflicto con ese objetivo.

  • Me pregunto si HTTP/2 o HTTP/3 aportan beneficios cuando solo se soportan en el proxy inverso y no en el servidor web real.
    La mayoría de los frameworks principales de JS/Python/Ruby no soportan los nuevos estándares HTTP. Entonces, ¿el servidor web no se convierte en el cuello de botella de la conexión con el proxy inverso?

    • Sí. HTTP/2 o HTTP/3 aumentan la confiabilidad de la conexión entre el cliente y el proxy inverso.
      La conexión entre el proxy inverso y el servidor web real suele ser mucho más rápida y estable, así que pasar ese tramo a HTTP/2 o HTTP/3 aporta mucho menos beneficio.
    • El transporte entre el proxy inverso y el backend tampoco siempre es HTTP. Por ejemplo, Python a veces usa uWSGI, y PHP usa FastCGI.
      Incluso cuando se usa HTTP, el proxy inverso puede establecer conexiones con el backend mucho más rápido que con un cliente remoto real. Por eso sigue siendo ventajoso usar streams HTTP/2 en el tramo lento.
    • Probablemente no importe mucho, pero mitmproxy no es un proxy inverso para entornos de producción.
      Es una herramienta que se ejecuta en una máquina local para hacer pruebas relacionadas con protocolos de bajo nivel o seguridad web.
    • Hay un punto que falta: los navegadores web limitan a 6 la cantidad de conexiones por dominio.
      Con HTTP/2 o superior, varias solicitudes simultáneas se manejan sobre una sola conexión.
    • Sí. Hay otros beneficios de rendimiento, pero HTTP/3 combina los handshakes de TCP y TLS, reduciendo un viaje de ida y vuelta al conectarse.

  • Todavía queda el problema de la huella digital. Hasta que pueda imitar el handshake TLS de un navegador común, en alrededor del 80% de la web vas a ver páginas como “Just a quick check...” o “Sorry, it looks like you're a bot”.
    https://github.com/mitmproxy/mitmproxy/issues/4575

    • Entonces parece que Firefox ya no es un navegador común.

  • Gracias por mencionar Hickory. Siempre es divertido ver qué construye la gente con eso, y es un trabajo bien hecho.

    • Gracias por el trabajo en Hickory. Gracias a la interoperabilidad Python↔Rust de PyO3, es realmente interesante que desde Python se puedan usar bibliotecas DNS de nivel operativo como Hickory y stacks sólidos de networking en espacio de usuario como smoltcp.
      Son cosas que originalmente habrían sido difíciles de conseguir solo con Python.

  • Me pregunto si Mitmproxy puede usarse como Privoxy/Proxomitron/Yarip.
    Por ejemplo, al navegar con Ungoogled Chromium, ¿podría poner Mitmproxy como proxy y eliminar las etiquetas script de ciertos sitios? ¿Qué impacto tendría en el rendimiento?

    • En teoría, sí. En la práctica, como mitmproxy está escrito en Python, y el lenguaje no es muy rápido, habrá latencia.
      Al ver páginas web, pequeños retrasos acumulados cientos de veces pueden notarse.
      Aun así, para quienes estén interesados en ese uso, puede ser una opción. Técnicamente no hay nada que lo impida.
      Al reescribir archivos JavaScript hay un pequeño riesgo de tocar verificaciones de integridad de subrecursos, pero si eso causa problemas, creo que también se podría resolver reescribiendo los hashes.

  • ¿mitmproxy puede ser una alternativa a Fiddler?

  • Mmm: https://github.com/mitmproxy/mitmproxy/issues/4170