Httptap - permite ver las solicitudes HTTP/HTTPS de cualquier programa de Linux

(github.com/monasticacademy)

8 puntos por GN⁺ 2025-02-04 | 2 comentarios | Compartir por WhatsApp

httptap es una herramienta que ejecuta programas de Linux con la forma httptap -- <command> y muestra en la terminal un resumen de las solicitudes y respuestas HTTP/HTTPS que genera ese programa
Funciona sin permisos de root, sin daemons, sin cambios globales del sistema, sin reglas de iptables ni modificaciones de la tabla de enrutamiento, y su ejecutable es un binario estático de Go sin dependencias
Por ahora es exclusivo de Linux, y señala que es difícil portarlo a otros sistemas operativos porque usa llamadas al sistema específicas de Linux, como network namespace
El tráfico HTTPS se descifra inyectando en el entorno del subproceso una autoridad certificadora creada al vuelo durante la ejecución, y funciona como un proxy TCP transparente que procesa paquetes IP/TCP/UDP sin procesar
En Ubuntu 23.10 o superior, o en distribuciones que desactivan por defecto los user namespace sin privilegios, puede requerir configuración de sysctl, y tiene limitaciones como no poder aceptar conexiones entrantes y requerir acceso a /dev/net/tun

Qué hace httptap

httptap ejecuta cualquier comando de Linux envolviéndolo y muestra las solicitudes HTTP/HTTPS que genera ese comando
- La forma básica de uso es httptap -- <command>
- El ejemplo con curl https://monasticacademy.org muestra la solicitud GET https://monasticacademy.org/ y la respuesta 308
En el ejemplo con Python requests.get('https://monasticacademy.org'), sigue la redirección y muestra dos solicitudes
- La primera solicitud recibe 308 para https://monasticacademy.org/
- La siguiente solicitud recibe 200 para https://www.monasticacademy.org/

Instalación y requisitos de ejecución

Los binarios precompilados se pueden instalar descargando el tarball de la versión más reciente
- Todas las versiones y arquitecturas de CPU están disponibles en releases
También ofrece instalación con Go
- go install github.com/monasticacademy/httptap@latest
Por lo general, no requiere permisos de root para ejecutarse, ni daemons ni configuración global del sistema
- No crea reglas de iptables
- No modifica la tabla de enrutamiento
- Normalmente no afecta a otros procesos del mismo sistema
En Ubuntu 23.10 o superior se necesita la siguiente configuración
- sudo sysctl -w kernel.apparmor_restrict_unprivileged_unconfined=0
- sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
Esta configuración desactiva funciones recientes del kernel que restringen los user namespace sin privilegios
- También puede ser necesaria en otras distribuciones que los desactivan por defecto
- Está investigando cómo eliminar este requisito proporcionando junto con httptap un perfil de AppArmor

Ejemplos de uso

El ejemplo con curl -s https://buddhismforai.sutra.co -o /dev/null muestra que el servidor devolvió una redirección 302
Si se sigue la redirección con curl -sL, también se muestran las solicitudes adicionales
- La primera solicitud recibe 302
- La segunda recibe 200 para la URL de destino de la redirección
En el ejemplo con gcloud compute instances list, se pueden ver los endpoints HTTP que usa internamente Google Cloud CLI
- POST https://oauth2.googleapis.com/token
- GET https://compute.googleapis.com/compute/v1/.../aggregated/instances?...
- La salida normal de gcloud aparece junto con el registro de solicitudes de httptap
En el ejemplo con kubectl get all, muestra las solicitudes al servidor API de Kubernetes
- --https 443 6443 hace que las conexiones TCP a los puertos 443 y 6443 se traten como HTTPS
- --insecure-skip-tls-verify es necesario porque kubectl no usa la autoridad certificadora generada por httptap
El ejemplo con curl --doh-url https://cloudflare-dns.com/dns-query muestra el flujo de DNS-over-HTTP
- Las dos primeras solicitudes son consultas DNS
- Las dos siguientes son solicitudes HTTP normales al sitio de destino
Si se usan juntos --head y --body, imprime los encabezados HTTP y la carga útil sin procesar

Salida HAR

Con la opción --dump-har out.har, se pueden volcar las solicitudes y respuestas HTTP a un archivo HAR
El archivo HAR generado se puede visualizar en varios visores HAR
- Como ejemplo se menciona Google HAR Analyzer
El HAR de ejemplo incluye una solicitud 308 Redirect a https://monasticacademy.org y una solicitud 200 OK a https://www.monasticacademy.org

Acceso a localhost

Para acceder a un puerto localhost del host desde dentro de httptap, se debe usar host.httptap.local o 169.254.77.65 en lugar de localhost
Como cada network namespace de Linux tiene su propio dispositivo loopback 127.0.0.1, 127.0.0.1:1234 dentro de httptap no es la misma dirección y puerto que en el host
httptap evita este problema enroutando de forma fija 169.254.77.65 hacia 127.0.0.1

Subprocesos que se convierten en daemon

En Linux es posible crear subprocesos que permanecen activos incluso después de que termina el proceso original
- Es una forma común en daemons y en aplicaciones GUI iniciadas desde la línea de comandos
Si esos procesos se ejecutan bajo httptap, los procesos daemonizados permanecen dentro del network namespace de httptap
La opción --no-exit hace que httptap siga haciendo proxy y registrando tráfico incluso después de que termine el subproceso ejecutado directamente
- En el ejemplo de Visual Studio Code se usa httptap --no-exit -- code --ignore-certificate-errors .
- Para salir, hay que cerrar VS Code y luego terminar httptap con Ctrl+C
Si httptap termina primero sin --no-exit, aunque el network namespace siga existiendo, la app pierde conectividad porque ya no hay ningún proceso leyendo los paquetes del dispositivo TUN
En los ejemplos setsid setsid curl http://httpbin.org/get y el de Python con fork, setsid, fork, sin --no-exit aparece el error Could not resolve host

Cómo funciona

httptap -- <command> ejecuta <command> en un network namespace aislado e inyecta una autoridad certificadora creada al vuelo para descifrar el tráfico HTTPS
Crea un dispositivo TUN de Linux y configura el entorno del subproceso para que todo el tráfico de red pase por ese dispositivo
- El tráfico escrito en el dispositivo TUN se entrega al descriptor de archivo que posee el proceso que creó ese dispositivo
Como modificar el network namespace root afectaría el tráfico de todo el sistema, httptap crea un network namespace separado
- Ese namespace solo tiene un dispositivo loopback y un dispositivo TUN
- El subproceso se ejecuta dentro de ese namespace
El tráfico recibido desde el dispositivo TUN son paquetes IP sin procesar
- httptap analiza los paquetes IP y los paquetes TCP/UDP internos
- Luego necesita volver a escribir paquetes IP sin procesar hacia el subproceso
- Su implementación propia de TCP/IP omite muchas partes del protocolo TCP completo, pero funciona razonablemente bien para este propósito
Cuando el subproceso hace una solicitud a www.example.com, httptap recibe un TCP SYN dirigido a la IP de destino y responde con SYN+ACK
- Por separado, establece una conexión TCP real con la IP de destino usando la API normal de sockets del kernel de Linux
- Después retransmite los datos en ambos sentidos
- Esta estructura es un proxy TCP transparente tradicional
El descifrado de HTTPS se resuelve mediante la inyección de una autoridad certificadora
- Al iniciar, genera una autoridad certificadora correspondiente a una private key y un x509 certificate
- Escribe el certificado en un sistema de archivos visible solo para el subproceso
- Configura variables de entorno visibles solo para el subproceso para agregar esa autoridad certificadora a la lista de confianza
- Como httptap posee la private key de esa autoridad certificadora, puede probar que es el servidor con el que el subproceso intenta comunicarse y leer la solicitud HTTP en texto plano

Limitaciones

Por ahora es solo para Linux y depende de llamadas al sistema exclusivas de Linux, como network namespace
El proceso no puede aceptar conexiones de red entrantes
Requiere permisos de acceso a /dev/net/tun
Todas las solicitudes ICMP echo se responden tal cual, sin enviar paquetes ICMP a la red real

2 comentarios

halfenif 2025-02-06

it was developed at the Monastic Academy in Vermont in the US. We believe that a monastic schedule, and the practice of the Buddhist spiritual path more generally, provide ideal conditions for technological development.

Al probarlo y mirar GitHub, me dio la impresión de que quizá lo hicieron personas dedicadas a la práctica monástica como parte de su desarrollo espiritual.

GN⁺ 2025-02-04

Opiniones en Hacker News

La sección “How it was made” del README me pareció tan interesante como la herramienta en sí.
Cuentan que viven y practican juntos en un terreno de poco más de 100 acres, cantan y meditan juntos por la mañana y por la noche, y cada mes organizan y participan en un retiro de meditación de aproximadamente una semana. El resto del tiempo se dedican juntos al cuidado del terreno, mantenimiento de edificios, cocina, limpieza, planificación, recaudación de fondos y, en los últimos años, también al desarrollo de software.
- Me recordó a un pasaje de “Soul of a new machine”.
  En una época en que el microcódigo y la lógica causaban problemas a escala de nanosegundos, se dice que un ingeniero agotado renunció y dejó en la terminal esta nota como carta de renuncia: “Me voy a una comuna en Vermont y no voy a lidiar con ninguna unidad de tiempo más corta que las estaciones”.
- Para ser sincero, suena como uno más de los muchos cultos de yoga/espiritualidad que ya existen por todo Occidente.
- La parte que dice: “Durante los últimos años hemos estado grabando una serie de charlas llamada Buddhism for AI. Trata sobre un esfuerzo por diseñar una religión basada en el budismo —sí, una religión— para que los sistemas de IA puedan consumirla directamente. Dada la situación del mundo, sentimos que esto es muy importante” me parece un indicador de lo extraña que es la época en la que vivimos.
  Si es una buena idea o si llevará al resultado que ellos imaginan es otra cuestión.
- Pensé que la primera foto del campo era una imagen generada, pero ahora parece que es una foto real.
  La combinación de tecnología y meditación me atrae. La idea en sí es atractiva, pero probablemente sea difícil llevarla a la práctica. Se ve como una especie de Recurse budista.
httptap es un rastreador de HTTP a nivel de proceso que puede ejecutarse sin privilegios de root.
Si ejecutas un programa de Linux como httptap <programa>, puedes ver en la salida estándar el rastreo de las solicitudes y respuestas HTTP/HTTPS.

httptap -- python -c "import requests; requests.get('https://monasticacademy.org')"
---> GET https://monasticacademy.org/
<--- 308 https://monasticacademy.org/ (15 bytes)
---> GET https://www.monasticacademy.org/
<--- 200 https://www.monasticacademy.org/ (5796 bytes)

Funciona ejecutando el programa dentro de un espacio de nombres de red aislado y usa gVisor como su propia pila TCP/IP. No es un proxy HTTP, así que no depende de la configuración de proxy. El tráfico TLS se descifra generando una CA al vuelo, y no instala reglas de iptables ni realiza cambios globales en el sistema.
- Me pregunto si se podría hacer funcionar también en macOS. Tengo entendido que Tailscale usa la biblioteca TCP/IP de gVisor como biblioteca netstack para algunas funciones en macOS.
- Me pregunto si se pueden modificar las solicitudes o las respuestas. A medida que la web actual se vuelve cada vez más hostil con los usuarios, la necesidad de herramientas así es mayor que nunca.
  Sobre todo si no requiere configuración de proxy, sería aún más útil.
- ¿Será que todos olvidaron que Wireshark también puede ejecutarse sin root?
  https://blog.wireshark.org/2010/02/running-wireshark-as-you/
La idea de ejecutar el proceso en un espacio de nombres de red aislado es genial.
La parte de HTTPS es aún más interesante. Parece que establece variables de entorno comunes[1] para que el programa use el bundle de CA en un directorio temporal, pero, igual que con las variantes de http_proxy, existe el problema de que el programa puede simplemente ignorarlas.

También veo que monta un sistema de archivos superpuesto sobre /etc/resolv.conf[2]. Me pregunto si ayudaría que httptap montara el directorio /etc/ca-certificates con el bundle de CA temporal.

[1] https://github.com/monasticacademy/httptap/blob/cb92ee3acfb2...
[2] https://github.com/monasticacademy/httptap/blob/cb92ee3acfb2...
- Coincido en que es frustrante que prácticamente no exista una forma consensuada, ni una impuesta por el sistema, de indicarle a un proceso arbitrario una CA raíz.
  httptap monta una superposición sobre /etc/resolv.conf porque, de forma parecida a las CA raíz, tampoco hay una manera segura de decirle a un proceso arbitrario qué servidor DNS debe usar. Aun así, /etc/resolv.conf es una opción bastante confiable. En cuanto pones el proceso dentro de un espacio de nombres de red, ya no puede acceder al resolver de systemd localhost:53, que es la configuración más común en Linux de escritorio, así que hay que proporcionarle resolución DNS.
  Montar /etc/ca-certificates como superposición también podría ayudar. Pero al revisar la estructura de ese directorio, me sorprendió lo poco consistente que es entre distribuciones. Aun así, es posible. Si alguien sabe cómo agregar certificados a ese directorio de una manera que al menos algunas implementaciones de TLS reconozcan, me gustaría escucharlo.
- No creo que para la parte de HTTPS exista una solución general que cubra todo tipo de programas y la larga cola de implementaciones de certificate pinning.
  Como contraejemplo, se puede imaginar malware que se comunica por TLS y cuyo código compilado está fuertemente ofuscado. Podría ser un programa que incluye en el binario un conjunto fijo de certificados de CA y no abre el sistema de archivos para nada. Aun así, podría crear conexiones TLS válidas y seguras durante unos 10 años, hasta que venza la mayoría de los certificados raíz de CA. TLS se maneja completamente en espacio de usuario, y no hay garantía de que use OpenSSL u otra biblioteca común, así que tampoco se puede contar con enganchar una función específica de OpenSSL. Si el servidor usa un certificado autofirmado y el cliente lo acepta por cualquier motivo, es aún peor.
  Aun así, con algo de trabajo, sin duda es posible cubrir de forma confiable el 99% de los casos. Es mejor que no tener nada.
Usar un dispositivo TUN aquí es una idea realmente genial. La sección “How it was made” del README también es de lo mejor que he leído en un README de GitHub.
Estoy creando algo llamado Subtrace[1], que puede interceptar automáticamente tanto las solicitudes entrantes como las salientes. Me da risa que la interfaz para iniciar un programa parece haber convergido hacia la misma forma[2]. Dicho eso, el objetivo de Subtrace es un poco distinto al de httptap y está más orientado a la observabilidad/monitoreo de servicios backend en la nube, por eso enfatiza las solicitudes en ambos sentidos. El enfoque también es distinto. Con Seccomp BPF intercepta alrededor de 10 llamadas al sistema, como socket, connect, listen, accept, etc., y proxifica todas las conexiones TCP a través de Subtrace. Luego parsea las solicitudes HTTP desde el stream TCP y reutiliza la pestaña Network de Chrome DevTools para que funcione en el navegador como una app web normal y se la muestra al usuario.

Me da curiosidad si hay alguna anécdota interesante al ejecutar programas bajo httptap. También me intriga qué programa es el que más “llama a casa”.

[1] https://github.com/subtrace/subtrace
[2] https://docs.subtrace.dev/quickstart
- Me recuerda a NetGuard, que usa el servicio VPN de Android para filtrar paquetes. Usa el servicio VPN de Android en lugar de un TUN crudo.
  https://github.com/M66B/NetGuard
- También es interesante conectar lo capturado con Chrome DevTools, y también lo es usar eBPF. Haber hecho que las herramientas de desarrollo se ejecuten como una webapp independiente también está excelente.
  Aunque cueste creerlo, en el directorio networktab del repositorio hay un intento a medio hacer de lograr lo mismo con la pestaña de red de Firefox. Es un proyecto muy bueno; me gustaría aprender más y con gusto seguiría conversando.
Otra herramienta para que un usuario sin privilegios analice tráfico de red es usar rootless Podman con Pasta.
Basta con agregar lo siguiente a las opciones de podman run:

--network=pasta:--pcap,myfile.pcap

Entonces Pasta registra el tráfico de red en un archivo PCAP, que se puede analizar después. También dejé escrito un ejemplo simple para analizar el archivo PCAP registrado con tshark.
https://github.com/eriksjolund/podman-networking-docs?tab=re...
- Es muy bueno saberlo, pero sigue quedando el problema de descifrar el tráfico TLS.
Bastante interesante. Una vez escribí una librería que hace una función similar de “tap” en aplicaciones Go: https://github.com/henvic/httpretty
https://asciinema.org/a/297429

También había pensado en hacer algo así para programas arbitrarios, pero nunca investigué a fondo cómo implementarlo. Me alegra ver que alguien lo haya creado.
Me pregunto por qué no usar eBPF. Así se podrían ver de una vez las solicitudes HTTP de todos los procesos, incluso los que ya están en ejecución. Además, parece que no habría que preocuparse por TLS si, por ejemplo, se engancha write(2).
- No veo cómo enganchar write(2) resolvería TLS. Podrías leer y modificar texto cifrado, pero como el proceso no llama a write(2) con bytes en texto claro, no podrías leer la solicitud HTTP real. Al final solo verías los bytes cifrados que van a la red, y eso también lo puede ver la NSA.
  Hace falta un truco de certificado CA como el que usa httptap. Claro que hay advertencias, como el pinning de certificados, pero en la mayoría de los escenarios prácticos se puede hacer que funcione de forma confiable.
  Al crear Subtrace[1] he pensado en este problema específico una cantidad absurda de tiempo, así que si existe un enfoque más simple o elegante, de verdad me interesa.
  [1] https://github.com/subtrace/subtrace
- Lamentablemente, TLS ocurre dentro de la aplicación y no en el kernel, así que enganchar la llamada al sistema write con eBPF no ayuda a descifrar TLS.
- Me pregunto si, poniendo un uprobe sobre la librería SSL, se podrían inspeccionar y modificar contenidos como las respuestas HTTP descifradas para filtrar contenido.
- Supongo que eBPF probablemente requiere permisos de root.
- ¿Este método no necesitaría root? El gran “argumento de venta” de httptap parece ser precisamente que no requiere permisos de root.
  En todo caso, mientras más opciones haya, mejor.
Genial. Creo que lo usaría de inmediato para depurar configuración de nginx.
Ahora uso curl -v y tengo que revisar manualmente la salida para ver qué salió mal, pero con esta herramienta cosas como un loop de redirecciones deberían quedar claras enseguida.
- Me gustaría escuchar cómo funciona en un contexto de uso real, en especial qué funciones resultan útiles.
Se ve muy bueno para echar un vistazo rápido y algo tosco al stack de llamadas HTTP/S de una app.
Personalmente prefiero eBPF para verlo todo, pero esta utilidad podría ayudar a acotar las partes importantes dentro de un rastreo con eBPF.
Se ve bien
El perfil de GitHub apunta a https://www.monasticacademy.org/about; no tengo una opinión particular sobre eso en sí, pero me dio curiosidad cómo se conectan sus retiros de formación monástica con el proyecto de GitHub.
Al ver la parte inferior del README, encontré que explican la conexión: https://github.com/monasticacademy/httptap?tab=readme-ov-fil...
- Para quienes estén leyendo este hilo, la conexión es simplemente que httptap es un proyecto de Monastic Academy.
  Eso significa que en un terreno de 123 acres en Vermont, algunas personas viven juntas siguiendo una estructura relativamente tradicional de monasterio budista. Eso sí, no son monjes con ordenación formal. Durante el día, trabajan juntos en varios proyectos técnicos y no técnicos. El enlace al README de arriba ofrece un buen panorama.
  https://github.com/monasticacademy/httptap?tab=readme-ov-fil...