mitmproxy añade la opción --emudhra

Artículo original ↗ Discusión en Hacker News ↗

Mitmproxy ha añadido una opción `--emudhra` que aprovecha claves intermedias de eMudhra recientemente expuestas y trivialmente débiles —una de las cuales era literalmente el número 4— para generar certificados HTTPS en los que todavía confían muchos dispositivos antiguos o sin parchear. Los comentaristas exploran cómo esto permite interceptar de forma transparente el tráfico de teléfonos Android antiguos, smart TVs y dispositivos IoT, al tiempo que destacan el fracaso más amplio de la revocación de certificados y las actualizaciones de los almacenes de confianza en plataformas como iOS y macOS. El incidente plantea preguntas sobre la gobernanza de las CA, posibles puertas traseras, el uso responsable de estas herramientas y si la humillación pública de una autoridad de certificación está justificada dada la gravedad del fallo.

Nueva función --emudhra en mitmproxy

  • La opción firma certificados TLS interceptados con una de las claves intermedias de eMudhra que ahora son públicas.
  • Está pensada como una forma práctica de probar qué dispositivos y aplicaciones siguen confiando en estas cadenas comprometidas.
  • Algunos sugieren integrar múltiples cadenas comprometidas (emSign y rutas AAA) para una cobertura más amplia; se enlaza una solicitud de incorporación.

Casos de uso: depuración, ingeniería inversa, jailbreak

  • Respuestas entusiastas sobre usar esto en:
    • Teléfonos Android antiguos (si las apps no hacen pinning o usan su propio almacén de confianza).
    • Smart TVs y dispositivos IoT para observar tráfico del proveedor, configuraciones o actualizaciones de firmware.
  • Flujos de mitm descritos: interceptar canales de configuración/firmware/anuncios que pueden habilitar modos de desarrollo o dar lugar a RCE.
  • Limitaciones: fijación de certificados, attestation, raíces privadas y dispositivos que ya se han actualizado o han revocado la confianza.

Detalles del compromiso de eMudhra

  • Ocho CA intermedias tenían claves privadas P-384 absurdamente débiles; se dieron ejemplos (4, 56, 66, etc.), equivalentes de hecho a 3–8 bits de entropía.
  • Algunas explicaciones indican que esto parece claves de 8 bits usadas por error donde se pretendían 384 bits.
  • Raíces implicadas: emSign ECC Root CA – G3 y una raíz AAA más antigua; se comentan cronologías sobre cuándo cada una está dentro o fuera de los principales almacenes de confianza.
  • Se señala que la búsqueda de claves de curva elíptica requiere un esfuerzo de ~2^(n/2), lo que hace que las claves EC “moderadamente débiles” sean factibles de fuerza bruta en GPU.

Comportamiento de revocación en plataformas (especialmente Apple)

  • Varios usuarios informan resultados inconsistentes en iOS, iPadOS y macOS al visitar sitios de prueba:
    • Algunos ven que todas las cadenas son bloqueadas.
    • Otros todavía ven 1–3 cadenas falsificadas aceptadas.
  • Las hipótesis incluyen despliegue gradual, fallos de búsqueda OCSP/CRL o timeouts; el comportamiento sigue sin estar claro.
  • La desconfianza manual de raíces en el Llavero de macOS bloquea de forma fiable las cadenas malas.

Ética, nomenclatura y temas de seguridad más amplios

  • Hay opiniones divididas sobre llamar a la opción --emudhra:
    • Algunos lo ven como una rendición de cuentas justa por un fallo grave de la CA.
    • Otros lo ven como echar más leña al fuego sobre personas que “nunca lo dejarán atrás”.
  • Varios comentarios presentan esto como “convertir un desastre de seguridad en una herramienta defensiva”, permitiendo a los usuarios inspeccionar y controlar dispositivos que los proveedores intentan bloquear.
  • Se mencionan propuestas para escanear sistemáticamente todas las CA en busca de claves igualmente débiles; una respuesta señala que este problema específico se encontró usando herramientas existentes y que no se observaron otras claves débiles en ese escaneo.