Firefox 43 has now officially disabled the fiddler hook addon citing it's unsigned in FF addons.

Could not be verified and has been disabled.

If someone can have a look at that I'd be immensely appreciative. because I love fiddler and use it a lot with FF :)

I need it for security testing. My purpose is to check, how the application would behave, if the adversary presents a certificate with a wrong Common Name (CN) and/or SubjectAltName, but signed by a correct CA.

I believe that the application in test uses HostnameVerifier incorrectly and need to prove it.

Hi, I'm trying to capture https traffic from instagram android app. Trusted certificate was installed, and I can see traffic from http (from instagram app) but not https (but I can see https traffic from some sites link google.com when I use android browser).

I am using windows 8x64 and Fiddler4. In Fiddler https requests appears as follows:

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.1 (TLS/1.0)
Random: 56 6D AC E8 26 31 CA CB 00 E2 AC 68 AD 8F 7E E4 80 72 25 78 26 BB EB 59 C5 16 C3 30 E0 C1 53 C9
"Time": 12/09/2093 14:18:14
SessionID: E4 3C 00 00 91 E9 3F 1E 25 FF 6B 00 87 3D 29 39 3D AB 22 6D 1A 6A B7 01 F5 83 D3 04 0B 14 0F 47
Extensions:
    server_name    i.instagram.com
    ec_point_formats    uncompressed [0x0], ansiX962_compressed_prime [0x1], ansiX962_compressed_char2  [0x2]
    elliptic_curves    sect571r1 [0xE], sect571k1 [0xD], secp521r1 [0x19], sect409k1 [0xB], sect409r1 [0xC], secp384r1 [0x18], sect283k1 [0x9], sect283r1 [0xA], secp256k1 [0x16], secp256r1 [0x17], sect239k1 [0x8], sect233k1 [0x6], sect233r1 [0x7], secp224k1 [0x14], secp224r1 [0x15], sect193r1 [0x4], sect193r2 [0x5], secp192k1 [0x12], secp192r1 [0x13], sect163k1 [0x1], sect163r1 [0x2], sect163r2 [0x3], secp160k1 [0xF], secp160r1 [0x10], secp160r2 [0x11]
    SessionTicket    empty
Ciphers:
    [0004]    SSL_RSA_WITH_RC4_128_MD5
    [0005]    SSL_RSA_WITH_RC4_128_SHA
    [002F]    TLS_RSA_AES_128_SHA
    [0035]    TLS_RSA_AES_256_SHA
    [C002]    TLS_ECDH_ECDSA_WITH_RC4_128_SHA
    [C004]    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
    [C005]    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
    [C00C]    TLS_ECDH_RSA_WITH_RC4_128_SHA
    [C00E]    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
    [C00F]    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
    [C007]    TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
    [C009]    TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    [C00A]    TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    [C011]    TLS_ECDHE_RSA_WITH_RC4_128_SHA
    [C013]    TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
    [C014]    TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
    [0033]    TLS_DHE_RSA_WITH_AES_128_SHA
    [0039]    TLS_DHE_RSA_WITH_AES_256_SHA
    [0032]    TLS_DHE_DSS_WITH_AES_128_SHA
    [0038]    TLS_DHE_DSS_WITH_AES_256_SHA
    [000A]    SSL_RSA_WITH_3DES_EDE_SHA
    [C003]    TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
    [C00D]    TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
    [C008]    TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
    [C012]    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    [0016]    SSL_DHE_RSA_WITH_3DES_EDE_SHA
    [0013]    SSL_DHE_DSS_WITH_3DES_EDE_SHA
    [0009]    SSL_RSA_WITH_DES_SHA
    [0015]    SSL_DHE_RSA_WITH_DES_SHA
    [0012]    SSL_DHE_DSS_WITH_DES_SHA
    [0003]    SSL_RSA_EXPORT_WITH_RC4_40_MD5
    [0008]    SSL_RSA_EXPORT_WITH_DES40_SHA
    [0014]    SSL_DHE_RSA_EXPORT_WITH_DES40_SHA
    [0011]    SSL_DHE_DSS_EXPORT_WITH_DES40_SHA
    [00FF]    TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Compression:
    [00]    NO_COMPRESSION

Response:

Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.

Secure Protocol: Tls12
Cipher: Aes128 128bits
Hash Algorithm: Sha1 160bits
Key Exchange: ECDHE_RSA (0xae06) 256bits

== Server Certificate ==========
[Subject]
  CN=*.instagram.com, O=Instagram LLC, L=Menlo Park, S=CA, C=US

[Issuer]
  CN=DigiCert High Assurance CA-3, OU=www.digicert.com, O=DigiCert Inc, C=US

[Serial Number]
  09D816F9BD53DA75B97D26B82B2B5359

[Not Before]
  13/04/2015 21:00:00

[Not After]
  31/12/2015 10:00:00

[Thumbprint]
  18E23BD23F1F5E10FF974BD639F0B1731527AC18

Some idea? 

Thanks
 

hello

in demo application of fiddlercore i add in beforeresponde event

   oS.utilDecodeResponse();
                     Monitor.Enter(oAllSessions);
                     using (StreamWriter writetext = File.AppendText("write.rtf"))
                     {
                         writetext.WriteLine(oS.GetResponseBodyAsString());
                     }
                     Monitor.Exit(oAllSessions);

in my file "write.rtf"  i get some javascript function and strange characters like this

 )�2�S��U �k�k

how i can read it?

is a browsergame in adobe flash

I hope to find help.

Hi Eric,

Thanks again for your helpful responses to my previous questions.  This is more of a 'pick-your-brain' type of question, and if you could offer thoughts to point me in the right direction I'd be very thankful.  And forgive me if my terminology isn't spot on, as I'm new to working with web traffic at this level.

I've enjoyed getting to learn about and use FiddlerCore for a personal home project.  I'm building a web filter for my family, and I've had great results so far. So I'm ready to begin thinking ​what it looks like to deploy the application as a Windows service on my PC.   

So my first question involves the proxy.  I see that when I use Fiddler the Windows ​proxy server settings are enabled and set to listen to the specified address and port.  So how might I go about setting up the proxy 'in the background', so to speak, and not have to worry ​my app needing to set the 'Manual Proxy Settings' in Windows?  I hope that makes sense.

My goal is make the filter as fool proof as possible, where the proxy runs as a service that cannot be tampered with, suspended, or disabled (even by an Admin account).  The only way it could be disabled is via performing an uninstall.  This is not really Fiddler-related per se, but if you had any thoughts on this as well I'd gladly hear them.  Thanks again.

-Kris

Here's an example:

I connect to Website A.  Website A makes requests to several content delivery networks. 

Here's my question:

Aside from looking at oRequest.Headers['Referer'], Is it possible to determine that Website A was the 'origin' when looking at the Fiddler request sent to the content delivery networks.

 In essence I'm asking, "Who started this chain of web requests?"  I'm not sure if that is possible, is it?

I use Fiddler4 with Proxifier on Windows10, HTTPS decrypt is turned on. Https requests from some application are not working. Applications do request but not receive any responce (i suggest). In Fiddler web log I see "Tunnel to <some ip>:443. Inspector log says: "A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.", but responce body is empty. If I switch HTTPS decryption off responces appear. But I need to decrypt some https traffic, please help.

We are troubleshooting some performance issues on a CRM Online instance.

The site has ADFS configured single sign on  and without fiddler running this works fine.

The site also has a proxy server to access the internet which users are authenticated against using their internal AD network credentials.

Once fiddler is turned on and capturing traffic the SSO to the online instance no longer works and users are presented with a series of ADFS login boxes to our internal ADFS urls - it seems like running fiddler interrupts the exchange of credentials that underpins SSO. Entering the user's domain credentials allows the user to view the CRM Online instance (they can enter domain\username and their password to proceed). Once entered the user is not prompted again for that session.

we have also seen occasional prompts for credentials from other random internet sites while fiddler is running - public websites that should not need authentication. It is unclear to me whether it is our internal proxy that is requesting the credentials but claiming that the website needs authentication - see attached screen cap. In this case, entering a user's network credentials to authenticate to the proxy allows access

 Are there any tips for :-

a) running fiddler on CRM Online instances (beyond decrypting the traffic so fiddler can see it)

b) running fiddler on applications that use federated SSO solutions

c) tuning Fiddler to not interrupt authentication traffic

Thanks

I use latest version of fiddler. but when every capturing the traffic either http or https, the WebView inspector doesn't work at all. it always displays the blank page although I have been decode the response

this is screenshoot: http://i.imgur.com/p0SgJDW.png

thanks

I am trying to use Fiddler 4.6.1.4 to determine the format of http control strings for an IP camera.

I need to be able to exercise various camera functions from its application which runs within a browser after entering its IP address.

The application will only run completely correct in IE.  When using any other browser, only part of its functionality is available and excludes functions I need to test.

The problem is, I have been able to successfully use Fiddler with Firefox or Opera for this purpose but not IE.  I am running Windows 7 and have tried IE11, IE10 and now regressed to IE9 and all have the same problem.  When the IP address is entered and the application starts to load, Fiddler captures all of the resulting traffic but when the application is done loading, the app controls will operate the camera but none are captured by Fiddler.  This does work correctly, with apparently the identical internet proxy settings, with, e.g., Opera (but with only the limited camera functions noted).  With any of these browsers, Fiddler does appear to automatically set the proxy settings as expected but only with IE does it not respond to commands sent.

I have tried everything I can find on the net and in your troubleshooting guidelines to no avail.  Please suggest how I can resolve this issue.