Fiddler acquisisce il traffico HTTPS generando al volo un falso certificato per il server previsto, eseguendo quindi un Attacco man-in-the-middle . Ciò richiede che il client sia configurato per accettare la CA controllata da Fiddler come CA attendibile, come descritto nella documentazione .
Questo tipo di intercettazione rompe i certificati client. Quando c'è un certificato client in SSL / TLS, il cliente firma tecnicamente (durante l'handshake) ciò che equivale a un hash di tutti i messaggi di handshake ricevuti e inviati finora; la firma calcolata dal client coprirà quindi (tra le altre cose) il certificato del server come visto dal client, cioè il falso generato da Fiddler, non il certificato del vero server. Pertanto, la firma del client non corrisponderà ai messaggi di handshake che il server ha visto.
Se si crede nella documentazione , allora Fiddler può risolvilo, ma ciò richiede a Fiddler di ricalcolare la firma del client. Funziona solo se Fiddler ha accesso alla chiave privata del client. Il file ".cer" non è sufficiente; è necessaria la chiave privata . La documentazione è un po 'oscura; la mia ipotesi è che Fiddler usi il file ".cer" per sapere quale certificato client usare, quindi cercherà quel certificato e la chiave privata all'interno dell'archivio certificati dell'utente locale (il che sarebbe il motivo per cui la documentazione di Fiddler dice che devi prima importare il certificato "come file .pfx", cioè con la sua chiave privata corrispondente, e quindi esportare semplicemente il file ".cer"). In ogni caso, senza accesso alla chiave privata del client, Fiddler non sarà in grado di mascherarsi come client vero quando parla al server.
Ora Fiddler potrebbe anche avere una limitazione per quanto riguarda i certificati CE; che non lo so. Da quanto ho spiegato sopra, Fiddler deve essere eseguito come client TLS quando si parla al server originale, quindi se è presente un certificato EC client, il codice di Fiddler deve supportarlo, ovvero Fiddler deve essere in grado di generare una firma ECDSA.
Dalla documentazione vediamo che la chiave privata rimane all'interno delle viscere della macchina client (un sistema Windows). Pertanto, qualsiasi generazione di firme dovrà passare attraverso l'API crittografica offerta da Windows. Windows ha due API completamente distinte: CryptoAPI e CNG . CryptoAPI è quello vecchio; Il CNG è stato introdotto con Windows Vista e 2008. Dal punto di vista di un'applicazione (ad esempio Fiddler), una chiave privata memorizzata e gestita con CNG può essere utilizzata solo con chiamate di funzioni specifiche; un'applicazione che conosce solo CryptoAPI non può utilizzare una chiave privata memorizzata CNG.
Sfortunatamente, CryptoAPI non ha supporto per la curva ellittica. Una chiave basata su EC può essere utilizzata solo tramite CNG. Inoltre, Fiddler è scritto in .NET e l'API crittografica di .NET si basa solo su CryptoAPI (tu puoi usare CNG ma devi farlo con invocazioni esplicite della DLL nativa ncrypt.dll e %codice%). Pertanto, trovo abbastanza plausibile che Fiddler usi solo CryptoAPI e, quindi, possa supportare solo chiavi RSA e DSA per i certificati client, non le chiavi EC.