Fiddler captura el tráfico HTTPS generando un certificado falso sobre la marcha para el servidor deseado, ejecutando así un Ataque del hombre en el medio . Esto requiere que el cliente esté configurado para aceptar la CA controlada por Fiddler como una CA de confianza, como se describe en la documentación .
Este tipo de intercepción rompe los certificados de los clientes. Cuando hay un certificado de cliente en SSL / TLS, el cliente firma (durante el protocolo de enlace) técnicamente, lo que equivale a un hash de todos los mensajes de enlace recibidos y enviados hasta el momento; la firma calculada por el cliente cubrirá (entre otras cosas) el certificado del servidor visto por el cliente, es decir, el falso generado por Fiddler, no el certificado del servidor original. Por lo tanto, la firma del cliente no coincidirá con los mensajes de intercambio que vio el servidor.
Si se debe creer en la documentación , entonces Fiddler puede arregle eso, pero esto requiere que Fiddler vuelva a calcular la firma del cliente. Esto solo funciona si Fiddler tiene acceso a la clave privada del cliente. El archivo ".cer" no es suficiente; se necesita la clave privada . La documentación es un poco confusa; Mi conjetura es que Fiddler usa el archivo ".cer" para saber qué certificado de cliente usar, luego buscará ese certificado y la clave privada en el almacén de certificados del usuario local (por lo que dice la documentación de Fiddler que primero debe importar el certificado "como archivo .pfx", es decir, con su clave privada correspondiente, y luego simplemente exportar el archivo ".cer"). En cualquier caso, sin acceso a la clave privada del cliente, Fiddler no podrá hacerse pasar por el verdadero cliente al hablar con el servidor.
Ahora Fiddler podría también tener una limitación con respecto a los certificados EC; que yo no se Por lo que explico anteriormente, Fiddler debe ejecutarse como un cliente TLS al hablar con el servidor original, por lo que si hay un certificado EC del cliente, entonces el código de Fiddler debe admitirlo, lo que significa que Fiddler debe poder generar una firma ECDSA.
De la documentación, vemos que la clave privada permanece dentro de las entrañas de la máquina cliente (un sistema Windows). Por lo tanto, cualquier generación de firmas deberá pasar por la API criptográfica que ofrece Windows. Windows tiene dos API completamente distinta: CryptoAPI y CNG . CryptoAPI es el viejo; CNG se introdujo con Windows Vista y 2008. Desde el punto de vista de una aplicación (por ejemplo, Fiddler), una clave privada almacenada y administrada con CNG solo se puede usar con llamadas a funciones específicas; una aplicación que solo conozca CryptoAPI no puede utilizar una clave privada almacenada en CNG.
Desafortunadamente, CryptoAPI no tiene soporte para la curva elíptica. Una clave basada en EC solo se puede utilizar a través de CNG. Además, se dice que Fiddler está escrito en .NET, y la API criptográfica de .NET se basa únicamente en CryptoAPI (usted puede usar CNG pero tiene que hacerlo con invocaciones explícitas del DLL nativo ncrypt.dll y %código%). Por lo tanto, me parece bastante plausible que Fiddler use solo CryptoAPI y, por lo tanto, puede admitir solo las claves RSA y DSA para certificados de cliente, no las claves EC.