git de Apple sigue confiando en los certificados eMudhra comprometidos

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

La forma en que Apple ha manejado los certificados TLS eMudhra comprometidos está siendo criticada porque macOS todavía incluye en `/etc/ssl/cert.pem` un paquete de CA que confía en ellos, dejando vulnerables a herramientas de línea de comandos como git, curl, Python y OpenSSL, aunque Safari y otras apps GUI fueron protegidas rápidamente mediante el propio marco de confianza de Apple. Los comentaristas critican la existencia de dos almacenes de confianza separados en macOS, la guía de corrección lenta y manual de Apple, y el hecho de que las actualizaciones del sistema operativo puedan deshacer silenciosamente las correcciones aplicadas por el usuario. El incidente también pone de relieve problemas más profundos con la gestión fragmentada de certificados en sistemas operativos, contenedores y lenguajes, y reaviva las llamadas a un mejor diseño centralizado de revocación y de almacenes de confianza.

Qué está realmente roto

  • El problema es más amplio que Git: muchas herramientas de línea de comandos de macOS (git, curl, python3, ruby, perl, openssl, etc.) usan /etc/ssl/cert.pem, que aún incluye raíces que permiten cadenas a través de intermediarios eMudhra comprometidos.
  • Las apps GUI que usan la pila Security/Keychain de Apple (Safari, las apps típicas de Mac) se actualizaron rápidamente y no confían en la cadena mala.
  • macOS tiene efectivamente dos almacenes de confianza independientes: Keychain para las API de Apple y /etc/ssl/cert.pem para herramientas al estilo Unix, lo que crea divergencia y confusión.

La respuesta de Apple y sus deficiencias

  • Apple publicó un artículo oficial de soporte explicando cómo los usuarios pueden editar manualmente /etc/ssl/cert.pem para eliminar ciertas raíces (y, opcionalmente, raíces Sectigo relacionadas).
  • Varios comentaristas consideran esto inaceptable: los usuarios deben ejecutar comandos de shell con sudo, los cambios se revierten con las actualizaciones del sistema operativo (por ejemplo, macOS 27.2 restauró los certificados malos), y no se ha publicado una solución automática rápida.
  • Algunos especulan que Apple trata las herramientas de CLI como de segunda clase y es lenta o no está dispuesta a usar sus canales de actualización de seguridad “en segundo plano/rápidos” para componentes Unix.

Soluciones alternativas y reacciones del ecosistema

  • Mitigaciones sugeridas:
    • Seguir manualmente las instrucciones de Apple para editar /etc/ssl/cert.pem.
    • Usar versiones de curl y OpenSSL de Homebrew o MacPorts, que incluyen sus propios paquetes de CA; Homebrew está actualizando git para dejar de usar el paquete del sistema.
    • Preferir SSH para los remotos de Git en lugar de HTTPS (aunque SSH tiene sus propios problemas de confianza).
  • Se comparten scripts y one-liners para automatizar las instrucciones de Apple; algunos advierten contra normalizar el copiar y pegar comandos sudo aleatorios.

Impacto en seguridad y debate sobre la gravedad

  • Muchos sostienen que se trata de un riesgo serio de MITM, especialmente en Wi‑Fi público o routers comprometidos; herramientas como mitmproxy ya admiten abusar de la cadena mala.
  • Otros minimizan el problema, diciendo que los atacantes deben controlar redes locales y que el uso malicioso generalizado sería detectable ahora que muchos dispositivos están parcheados.
  • Varios comentarios señalan problemas más amplios de PKI: almacenes de CA fragmentados (por app, por contenedor, por lenguaje), mecanismos de revocación débiles o sin uso, y la dificultad de dejar de confiar limpiamente en intermediarios cuando solo se empaquetan raíces.

Meta: Apple, Linux y modelos de confianza

  • Algunos usan esto como motivo para preferir Linux; otros responden que todas las plataformas han tenido fallos de seguridad graves.
  • Se critica que Apple se presente como priorizando la seguridad y, aun así, no haya lanzado una solución centralizada y rápida para sus propias herramientas Unix.