Note: Please see this post for an update.

Some users of Fiddler who have HTTPS Decryption enabled have found that some of their internal HTTPS sites that used to work properly with Fiddler now endlessly prompt for credentials while Fiddler is running. Even typing the correct credentials into the authentication prompt won't fix the problem. What happened?

The problem is that the servers in question have enabled the new Extended Protection / Channel Binding Tokens security feature. This feature helps to prevent reuse of credentials by binding an authentication response to the channel (e.g. the HTTPS connection) on which the authentication challenge was received. This obviously poses a problem for Fiddler, because Fiddler uses a man-in-the-middle strategy to decrypt HTTPS traffic. That means that the server's Authentication Challenge comes to Fiddler on a different connection than Fiddler uses to return that challenge to the client. By design, the client responds to the server's challenge using the information from its connection to Fiddler, and the server, noticing the mismatch, rejects those credentials.

To know if this problem applies to you, the following must be true:

  1. The site works properly when Fiddler isn't running
  2. The site is running on HTTPS
  3. The site works properly when Fiddler's HTTPS-decryption feature isn't enabled
  4. The server sends back a HTTP/401 authentication challenge even when correct credentials are supplied

Now, CBT is not currently widely deployed, but in some major organizations, it has been deployed on one or more critical servers. For instance, some organizations might have enabled CBT on their ADFS proxy server in order to protect ADFS logins to other sites. If that's the case, a user trying to debug that other site will find that they cannot log in with Fiddler running. Annoying.

Fortunately, there are workarounds for the cases where you don't actually care about the traffic to particular sites. While disabling HTTPS-Decryption globally works, it's somewhat annoying. Instead, you can disable HTTPS-decryption for specific sessions. You can do so by setting the x-no-decrypt flag on a given session, or, in Fiddler 2.3.0.6 or later, you can do so by listing the hostname inside the text box Skip Decryption for the following hosts found by clicking Tools > Fiddler Options > HTTPS.

(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.) Note: As noted in this post, this fix was made for Fiddler v2.3.6.1.

Beyond avoiding problems with servers that have CBT enabled, the ability to skip decryption for certain connections can be useful for other cases as well. For instance, Microsoft Outlook can be configured to communicate with Microsoft Exchange using RPC over HTTPS. You will find that when Fiddler decrypts such traffic, the client typically will no longer work. The problem is that Fiddler buffers all requests before sending them to the server (only streaming of responses is supported) and the RPC client never "finishes" sending a complete HTTP message. Hence, Fiddler will block communication to the server. If you disable HTTPS-decryption for servers used for RPC over HTTPS, you will still see the CONNECT tunnel through which the secure traffic flows, but Fiddler will not interrupt the traffic. Alternatively, you could disable HTTPS-decryption for traffic from an entire application (e.g. boring.exe) using a rule like this inside OnBeforeRequest:

if (
oSession.HTTPMethodIs("CONNECT")
&& oSession["X-PROCESSINFO"]
&& oSession["X-PROCESSINFO"].StartsWith("boring")
)
{
oSession["x-no-decrypt"] = "boring process";
}


thanks,

-Eric

Note: Please see this post for an update.