Fiddler and Channel Binding Tokens Revisited

Just under a year ago, I wrote a blog post about how the new “Extended Protection” feature (also known as Channel Binding Tokens or CBT) prevented seamless decryption of certain authenticated HTTPS traffic when Fiddler is running.

The quick recap is that CBT binds a set of NTLM or Kerberos authentication credentials to the “channel” upon which they have been sent. If the server detects that the credentials were sent on a different channel than they were received, then it assumes that a credential reuse attack is in progress and it treats the credentials as invalid.

This is a problem for Fiddler, which uses a man-in-the-middle approach for decrypting HTTPS traffic. This approach results in two HTTPS channels (connections), one from the client to Fiddler (secured by the Fiddler-generated certificate) and one from Fiddler to the server (secured by the server-supplied certificate). When the browser authenticates using the Negotiate package (NTLM or Kerberos), the credentials are bound to the connection to Fiddler. When the credentials are passed through on Fiddler’s connection to a CBT-enabled server, the mismatch of channel identity is detected and the credentials are treated as invalid. As a result, the browser prompts the user endlessly for their credentials:

…and even when correct credentials are supplied, those credentials will not work because the server will continue to reject them due to the channel mismatch.

The only workaround I could offer last year was the option to use Fiddler’s Rules engine or UI to disable decryption of requests bound for CBT-protected servers. This works fine if such servers are only incidentally part of your traffic flow—but what if they’re exactly what you need to see to debug something?

I mentioned in the middle of the article that it was theoretically possible that I could resolve this limitation in a future version of Fiddler--

(It is likely that a future version of Fiddler will be able to debug HTTPS traffic even with CBT enabled, because Fiddler runs on the client and has access to the user's credentials. Fiddler itself can provide a proper response to the server's credential challenge; I only need to update the code for the existing x-AutoAuth flag to use the channel information from the HTTPS connection.)

…but I was soon distracted by other feature requests, and CBT wasn’t broadly deployed enough for this limitation to cause many problems. However, last month, a Fiddler user hit this problem and mentioned it on Twitter, and during some downtime over the weekend I decided to take another crack at this, using the technique I outlined last year. In the “Agile” spirit, I tried “the simplest thing that could possibly work” and was utterly shocked that in just a few lines of code I indeed had addressed this problem.

The new functionality can be found in Fiddler v2.3.6.1 and later, now available in the Fiddler Beta channel.

To activate it, you must configure Fiddler to perform authentication on the client’s behalf. That ensures that the proper channel-binding information is presented to the CBT-protected server. The easiest way to configure Fiddler is to update the FiddlerScript file with a rule that will add your authentication information. Of course, precautions should be taken to ensure that only traffic from your own processes and machine is automatically authenticated-- otherwise anyone who can send traffic through your Fiddler instance will authenticate using your credentials! You also want to ensure that Fiddler only responds to authentication challenges from servers you trust (e.g. on your Intranet) lest an evil server be provided with credential hashes that it may be able to crack.

To configure Fiddler to authenticate on your behalf, click Rules > Customize Rules. Scroll to the OnPeekAtResponseHeaders function and add the following code:

You will probably want to adjust the two values marked in yellow. The first controls what servers Fiddler is willing to release credentials to—by default, I allow Fiddler to send credentials to any “plain” hostname that does not contain a dot (Intranet sites) and I also allow any site ending in Microsoft.com, because some of our CBT-protected servers have hostnames that contain dots. The second value controls what credentials Fiddler will attempt to use. If you specify explicit credentials in domain\\username:passwordformat (note the double-backslash required by JavaScript), Fiddler will attempt to use those credentials. If you instead specify (default), Fiddler will attempt to use the login credentials of whatever user-account that it is running under. Since I run Fiddler in my own account, I use “(default)”.

After you make these changes and save the file, Fiddler will begin to authenticate on your behalf to the servers' you’ve selected. The final line in the script sets the background color of automatically authenticated responses to pink so that they’re easily visible in your session list.

I hope you find this new feature helpful!

-Eric

PS: While I’m talking about Fiddler and Authentication, I’ll mention two other issues that pop up from time to time:

Office clients which use WinHTTP may not properly authenticate with Fiddler running. The reason is that WinHTTP does not authenticate in the same way that WinINET does. The X-AutoAuth trick above should work, or see http://support.microsoft.com/kb/956943 for an alternative workaround involving a registry change to the AuthForwardServerList.

When you attempt to authenticate to a website running on your local computer with Fiddler running, the credentials may be rejected. This is because Windows Vista and later contains special code to detect “loopback” credential use and block it when such use is not expected. The X-AutoAuth trick above may work. If not, please see http://support.microsoft.com/kb/926642 for two alternative workarounds involving registry changes. I’ve been told that the DisableLoopbackCheck option works, although either technique should be effective.