Proxyman 26.3.0 bloquea los servidores que usan los certificados comprometidos de eMudhra
4 min de lectura
Proxyman 26.3.0 para macOS ahora bloquea los servidores que usan los certificados comprometidos de eMudhra 🔒
La semana pasada se filtraron las claves privadas de 8 certificados intermedios de eMudhra. Los navegadores y los sistemas operativos dejaron de confiar en ellos en cuestión de días. Pero las apps que envían su tráfico a través de Proxyman no tenían esa protección, hasta ahora.
En este artículo veremos:
- Qué pasó con eMudhra.
- Por qué el tráfico a través de Proxyman seguía afectado.
- Cómo Proxyman 26.3.0 lo soluciona.
- Cómo probar la solución por ti mismo.
La solución está en Proxyman 26.3.0 para macOS. Proxyman para Windows y Linux recibirá la misma solución esta semana.
1. ¿Qué pasó?
eMudhra es una autoridad de certificación (CA). Una CA firma los certificados que demuestran que un sitio web es real. Tu navegador confía en un sitio web porque una CA de confianza firmó su certificado.
El 20 de octubre de 2026, un investigador de seguridad publicó que las claves privadas de 8 certificados intermedios de eMudhra se habían generado incorrectamente. Cualquiera puede recuperar estas claves a partir de los certificados públicos.
Con una de estas claves, un atacante puede crear un certificado para cualquier sitio web, como tu banco o la API de tu empresa. Cualquier app que todavía confíe en eMudhra lo aceptará como válido.
La respuesta fue rápida:
- Chrome y Firefox bloquearon los 8 certificados. Microsoft y Apple hicieron lo mismo unos días después.
- eMudhra los revocó, y Sectigo revocó las copias que había firmado.
Así que, si usas un navegador o un sistema operativo actualizado, estás protegido. Pero quedaba un hueco: los proxies.
2. Por qué el tráfico a través de Proxyman seguía afectado
Proxyman se sitúa entre tu app y el servidor. Para mostrarte el tráfico HTTPS, establece dos conexiones:
- Tu app → Proxyman: tu app ve un certificado creado por Proxyman, firmado por la CA de Proxyman que instalaste y en la que confiaste.
- Proxyman → el servidor: Proxyman recibe el certificado real del servidor.
En la segunda conexión, Proxyman aceptaba cualquier certificado. Es algo intencionado: a menudo depuras un servidor local o de staging con un certificado autofirmado, y Proxyman nunca debería interponerse en tu camino.
Pero aquí está el problema: tu app nunca ve el certificado real del servidor. Solo ve el certificado de Proxyman. Por eso, incluso después de que Apple, Google y Microsoft bloquearan los certificados de eMudhra, una solicitud a través de Proxyman a un servidor que los usara seguía pasando.
Un equipo informó de esto en issue #2797. Su empresa había implementado protecciones frente a los certificados filtrados. Si alguien activaba Proxyman y se olvidaba de desactivarlo, saltaba esas protecciones sin saberlo. Gracias por informar y por explicar el riesgo con tanta claridad 🙏
3. Cómo Proxyman 26.3.0 lo soluciona
Primero, comprobamos si la biblioteca TLS que usa Proxyman (SwiftNIO SSL) tenía una solución. No la tenía. Y, de todos modos, actualizar la biblioteca no habría servido de nada, porque Proxyman omitía la comprobación del certificado a propósito. Así que lo solucionamos por nuestra cuenta.
Proxyman 26.3.0 incluye una lista de bloqueo integrada con los 8 certificados comprometidos de eMudhra, incluidas las copias firmadas por Sectigo. Cuando Proxyman descifra tráfico HTTPS o WebSocket (WSS) con SSL Proxying, comprueba la cadena de certificados de cada servidor:
- Si un certificado de la cadena usa una de las claves filtradas, Proxyman cierra la conexión.
- Si el servidor solo envía su propio certificado, Proxyman comprueba quién lo firmó. Si lo firmó una de las claves filtradas, Proxyman también cierra la conexión.
- Para el resto de servidores, no cambia nada.
| Certificado del servidor | Antes de 26.3.0 | Proxyman 26.3.0 |
|---|---|---|
| Usa un certificado comprometido de eMudhra | Se conecta | Bloqueado |
| Un certificado normal, como github.com | Se conecta | Se conecta |
| Autofirmado, como tu servidor local | Se conecta | Se conecta |
La comprobación se ejecuta una vez, cuando Proxyman se conecta a un servidor, y es muy rápida.
Cuando Proxyman bloquea un servidor, tu app recibe un 502 Bad Gateway que indica el motivo. Lo verás en el siguiente paso.
4. Pruébalo tú mismo
El investigador ejecuta servidores de prueba que usan los certificados filtrados. Puedes usar uno para comprobar tu configuración:
- Actualiza a Proxyman 26.3.0 desde la página de descarga, o desde Proxyman → Check for Updates….
- Activa SSL Proxying para
dv-g3b-emudhra.we-have-a-problem.com. - Envía una solicitud a través de Proxyman. Proxyman usa el puerto 9090 por defecto:
curl --proxy http://localhost:9090 https://dv-g3b-emudhra.we-have-a-problem.com/
Obtendrás:
Bad Gateway: Blocked dv-g3b-emudhra.we-have-a-problem.com:443 because its certificate chain uses a compromised eMudhra CA key
Prueba el mismo comando con https://github.com/. Funciona como antes.
Si SSL Proxying está desactivado para un dominio, Proxyman no descifra el tráfico. Deja pasar la conexión cifrada, y tu app comprueba el certificado por sí misma, como si Proxyman no estuviera.
5. Lo que conviene saber
- Windows y Linux: Proxyman para Windows y Linux recibirá la misma solución esta semana.
- Los certificados autofirmados siguen funcionando. Proxyman solo bloquea los certificados de eMudhra filtrados. Tus servidores locales y de staging funcionan como antes.
- Proxyman es una herramienta de depuración. No sustituye las comprobaciones de seguridad de tu empresa. Cuando termines de depurar, cierra Proxyman o desactiva su proxy del sistema.
Más información
- eMudhra Intermediate CA Compromise: los detalles completos y la lista de certificados afectados
- Comunicado de eMudhra sobre el incidente
- Issue #2797 de GitHub
- Documentación de SSL Proxying
- Changelog de Proxyman
