Case 1 involves TLS + client certificate authentication with both client and server using secp384 based EC certificates. In this case, when monitoring traffic via fiddler, the tunneling/handshaking as well as encrypted traffic is completely missing from fiddler (as if nothing is happening). We know there is real traffic by monitoring both client and server individually.
Case 2 involves the same client process, same server process, same server certificate but client certificate authentication is disabled. In this case all the traffic as well as the initial handshake is captured within Fiddler.
Is this a known limitation of Fiddler? If yes, how else can I capture the TLS handshake that happens in Case 1? If not, am I missing a setting inside Fiddler? I have a C:\Users\<username>\My Documents\Fiddler2\ClientCertificate.cer certificate setup too (which basically matches the same PFX in the client cert store).
Also, all three (client, server and fiddler) are running on the same machine within the same user (admin) account. The user account's certificate store has the private key of the certificate too.
PS: Originally posted at http://security.stackexchange.com/questions/72916/can-fiddler-decrypt-https-traffic-when-using-elliptic-curves-client-cert-authe/72923#72923 but it's clear it actually belongs here.
Case 2 involves the same client process, same server process, same server certificate but client certificate authentication is disabled. In this case all the traffic as well as the initial handshake is captured within Fiddler.
Is this a known limitation of Fiddler? If yes, how else can I capture the TLS handshake that happens in Case 1? If not, am I missing a setting inside Fiddler? I have a C:\Users\<username>\My Documents\Fiddler2\ClientCertificate.cer certificate setup too (which basically matches the same PFX in the client cert store).
Also, all three (client, server and fiddler) are running on the same machine within the same user (admin) account. The user account's certificate store has the private key of the certificate too.
PS: Originally posted at http://security.stackexchange.com/questions/72916/can-fiddler-decrypt-https-traffic-when-using-elliptic-curves-client-cert-authe/72923#72923 but it's clear it actually belongs here.
3 Answers, 1 is accepted
0
Hi, Sid--
The behavior you're describing in "Case 1" suggests the client application/framework is not using the configured proxy. What is the application, or what framework is it written in? Some frameworks (particularly the .NET framework) are hardcoded to bypass the proxy for requests to 127.0.0.1 and localhost and you must undertake workarounds (e.g. using the machine's hostname or a virtual hostname like localhost.fiddler) in order for the traffic to be seen.
Regards,
Eric Lawrence
Telerik
The behavior you're describing in "Case 1" suggests the client application/framework is not using the configured proxy. What is the application, or what framework is it written in? Some frameworks (particularly the .NET framework) are hardcoded to bypass the proxy for requests to 127.0.0.1 and localhost and you must undertake workarounds (e.g. using the machine's hostname or a virtual hostname like localhost.fiddler) in order for the traffic to be seen.
Regards,
Eric Lawrence
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Sid
Top achievements
Rank 1
Rank 1
answered on 17 Nov 2014, 09:10 PM
Eric, first off - great product! Thanks a lot for that!
With respect to your question, the client and server are both in .NET 4.5 and are in-house applications. We can switch them to 'debug mode' where communications can happen without SSL or SSL but without client certificate and in those cases the network traffic can be seen. So shouldn't be related to the URL itself and it's NOT 127.0.0.1 nor localhost (just to be explicit). The EC certificates and keys are generated in OpenSSL if it matters.
With respect to your question, the client and server are both in .NET 4.5 and are in-house applications. We can switch them to 'debug mode' where communications can happen without SSL or SSL but without client certificate and in those cases the network traffic can be seen. So shouldn't be related to the URL itself and it's NOT 127.0.0.1 nor localhost (just to be explicit). The EC certificates and keys are generated in OpenSSL if it matters.
0
What APIs are you using in .NET for communication? How are you assigning the proxy to the request? And just to confirm, you see neither a CONNECT in Fiddler's Web Sessions list, nor anything written to Fiddler's LOG tab?
Regards,
Eric Lawrence
Telerik
Regards,
Eric Lawrence
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.