13

I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5

I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.

...however...

When I trying to monitor an other server I got this error message in the response window:

"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"

For full Fiddler window see:

enter image description here

The client is not a in this case browser, but a custom client program, which communicates with its own server.

My question: Is this exception misleading and in reality some other error prevents the secure channel to set up? ...or... We have still chance to monitor this https communication?

Thx in advance

Improve this question

3 Answers 3

Reset to default
14

What is the client program?

This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.

However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx

The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.

You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:

  CONFIG.oAcceptedServerHTTPSProtocols = 
    System.Security.Authentication.SslProtocols.Ssl3;

Please let me know if this works.

NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.

Improve this answer
4
  • Eric, many thanks for your support. Unfortunately this gives me "Variable 'SslProtocols' has not been declared"
    – g.pickardou
    Commented Jul 12, 2013 at 7:39
  • I solved the compile error using System.Security.Authentication namespace. Now I got 0 length response and this error message: "fiddler.network.https> Failed to secure existing connection for 77.87.178.129. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. InnerException: System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)" Interestingly after commenting out this line now gives the same.
    – g.pickardou
    Commented Jul 12, 2013 at 9:21
  • 1
    Try changing the line to only Ssl3 (answer updated above). I can successfully connect to the target server from here with that configuration.
    – EricLaw
    Commented Jul 12, 2013 at 16:13
  • This worked for me. Many thanks as I was banging my head to solve this for a long time.
    – Jimi
    Commented Sep 8, 2013 at 8:26
1

Unbelievably this issue is still present some 6 years later. Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:

"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"

After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):

<client>;ssl3;tls1.1;tls1.2

Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.

Improve this answer
2
  • SSL3 has been deprecated for years and not considered secure, if security is your aim I'd remove it from the list as well. In particular it is susceptible to the POODLE and BEAST vulnerabilities. TLS 1.1 is, I believe, going to be deprecated soon as well.
    – tphuoc
    Commented Nov 22, 2019 at 14:50
  • Thanks for that info, however in my case I was just looking for a way to make it work for testing purposes only. ;)
    – BillA
    Commented Nov 24, 2019 at 2:31
0

Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.

Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails

The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.