Fiddler Update check HTTPS fails to connect

[Nick Cullen]

I am using Fiddler Web Debugger (v4.6.1.4) = Built: 30 October 2015 (I use it more often at work but this is at home).

When it starts and check for updates the connection fails :-

[Fiddler] The connection to 'www.telerik.com' failed.
System.Security.SecurityException Failed to negotiate HTTPS connection with server.fiddler.network.https> HTTPS handshake to www.telerik.com (for #1) failed. System.IO.IOException The handshake failed due to an unexpected packet format.

Checking using Qualys SSL Scanner shows that the Telerik site has only a few supported encryption algorithms.

I have Fiddler turned on to do SSL Interception (and it worked in the past), yet now I find that the intercepted tunnels are also failing.

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

Has anyone else seen this, and can provide suggestions ?

Fiddler is handling HTTP requests OK, normal (unintercepted) use HTTPS Websites still seems to be working OK (in both IE and Firefox) but Fiddler seems unable to provide the upstream connections to HTTPS sites.

Regards,

Nick

[Eric Lawrence]

Inside Tools > Fiddler Options > HTTPS, what do you see next to the Protocols link?

When you use the "Test your browser" link on the SSLLabs.com site with Fiddler running, what's the full set of text in the Protocol Features section?

[Nick Cullen]

Under Tools > Fiddler Options > HTTPS, when I enable 'Decrypt HTTPS', I can see Protocols: <client>;ssl2 and if I click that Link I get a box allowing me to change the setting from <client>;ssl2

I had assumed that this setting meant 'Anything that the Client is offering PLUS ssl2'.

On https://www.ssllabs.com/ssltest/viewMyClient.html - without Fiddler HTTPS interception I get :-

Protocol Features

Protocols
TLS 1.2	Yes
TLS 1.1	Yes
TLS 1.0	Yes
SSL 3	No
SSL 2	No

Cipher Suites (in order of preference)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   Forward Secrecy	128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   Forward Secrecy	128
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)   Forward Secrecy	256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   Forward Secrecy	256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   Forward Secrecy	256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   Forward Secrecy	128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   Forward Secrecy	128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   Forward Secrecy	256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   Forward Secrecy	128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   Forward Secrecy	256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)	128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)	256
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)	112
(1) When a browser supports SSL 2, its SSL 2-only suites are shown only on the very first connection to this site. To see the suites, close all browser windows, then open this exact page directly. Don't refresh.

Protocol Details
Server Name Indication (SNI)	Yes
Secure Renegotiation	Yes
TLS compression	No
Session tickets	Yes
OCSP stapling	Yes
Signature algorithms	SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA
Elliptic curves	secp256r1, secp384r1, secp521r1
Next Protocol Negotiation	Yes
Application Layer Protocol Negotiation	Yes   h2 spdy/3.1 http/1.1
SSL 2 handshake compatibility	No

[Nick Cullen]

OK. I have it..... (I think)

1) The HTTPS Interception settings in Tools > Fiddler Options > HTTPS seem to affect Fiddler even when it is NOT configured for HTTPS interception. I suspect that those settings are used when Fiddler itself initiates traffic (e.g. For the Telerik Check for Updates). If that is the case, then it is NOT desireable behaviour.

2) The HTTPS Interception settings in Tools > Fiddler Options > HTTPS has a Protocols: section which is not in the documentation at http://docs.telerik.com/fiddler/configure-fiddler/tasks/decrypthttps.

3) The semantics of the Protocols: string are unexpected. I expect that <client>;ssl2 would mean 'Anything the Client offers PLUS sslv2' but that doesn't seem to be the case. Change it to <client>; or <client> and it refuses to accept the change (but doesn't say why not). Change it to <client>;tls1.1;tls1.2 and everything is back to normal.

4) With HTTPS Interception settings in Tools > Fiddler Options > HTTPS Protocols: <client>;tls1.1;tls1.2 (and interception disabled), we still get a sucessful update check (AND the transaction is decoded and visible) - I.e. Fiddler can always 'decrypt' its own traffic, even when decryption is turned off.

5) With HTTPS Interception turned off, and Tools > Fiddler Options > HTTPS Protocols: tls1.1;tls1.2, we acheive a sucessful update check.

6) With HTTPS Interception turned off, and Tools > Fiddler Options > HTTPS Protocols:  ssl2;ssl3;tls1.0 we acheive a sucessful update check.

7) With HTTPS Interception turned off, and Tools > Fiddler Options > HTTPS Protocols:  ssl2;ssl3 the update check starts to fail again. HTTPS traffic works OK provided it is not intercepted.

8) When HTTPS Interception is turned ON, and Tools > Fiddler Options > HTTPS Protocols:  ssl2;ssl3 then HTTPS access to most sites fails... and Fiddler shows the Transation response as
fiddler.network.https> HTTPS handshake to clients6.google.com (for #28) failed. System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < The client and server cannot communicate, because they do not possess a common algorithm

HTTPS handshake returned error SEC_E_ALGORITHM_MISMATCH.
Fiddler's Enabled HTTPS Protocols: [Ssl2, Ssl3] are controlled inside Tools > Fiddler Options > HTTPS.

9) I note that with the <client>;ssl2 setting I had not even been getting that much info.

Overall, I think you have three 'bugs' and a documentation inadequacy.

a) The HTTPS Interception settings should not influence the Update check, so as to cause it to fail.

b) The setting <client>;ssl2 should allow any protocol offered by the client - plus ssl2.

c) When you set an 'invalid' choice in the Protocols: change box, it should tell you rather than silently ignoring the input.

d) The existence and semantics of the Protocols: section should be included in the documentation.

P.S. Fantastically useful tool though !

Regards,

Nick

[Eric Lawrence]

Your supposition that Fiddler's Protocols list is used when issuing requests from Fiddler itself (including the update check) is correct.

You cannot use only <client> because there are cases (namely, traffic from Fiddler itself) where there is no other client to mimic.

Enabling ssl2 is problematic in general, as it forces the client to use the SSL2 handshake format.

The website documentation, alas, hasn't been updated in several years. The most current and comprehensive documentation can be found in HTTPS://fiddlerbook.com