Fiddler and Channel-Binding-Tokens


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.

Comments (5)

  1. Eric Markham says:

    Ack! This is exactly what's killing me here 🙂 I'm trying to analyze Outlook connecting to Exchange via RPC over HTTP and I was confused why enabling Fiddler suddenly caused endless re-prompting for authentication. Of course, disabling HTTPS decryption is counter-productive to what I'm trying to do; I'm looking to read the HTTP headers. Looks like I'll have to figure out how to do this in Wireshark.

    I'm heartened that the change is relatively small, hopefully it'll show up in Fiddler soon.

  2. EricLaw says:

    Wireshark won't be able to decrypt the HTTPS traffic unless you happen to have the server's private key. If you're trusted with the server's private key, chances are that you would be able to turn off CBT if you wanted.

    While the Fiddler change "sounds" small, it turns out to be non-trivial because the channel information isn't readily available. But I'm still interested in getting this to work, I just need to find time.

    For what it's worth, decrypting RPC over HTTPS introduces another problem– the traffic isn't really well-formed HTTP traffic and thus it doesn't proxy well. You'll probably be able to catch some HTTP headers, but you will likely find it difficult to make sense of the bodies.

  3. EricLaw [MSFT] says:

    An upcoming release (Fiddler 2.3.6.1+) will have the capability of decrypting CBT-protected traffic if you set the X-AutoAuth flag on the session. 😀

  4. luke.boening@us.army.mil says:

    Boy, this seems suspiciously like the same problem I am having. I resorted to using Observer 14 to follow the traffic, though it cannot decode any HTTPS traffic.

  5. EricLaw [MSFT] says:

    @Vespine: Why didn't you actually just try the fix?  http://www.fiddler2.com/…/fiddler2betasetup.exe