Fiddler capturing and decrypting traffic on a different network

  • Article

Having recently worked through a number of Exchange ActiveSync support cases it was necessary to setup a Fiddler proxy on a different network than the mobile device I was testing with. In my working scenario I setup a Windows client hosted as an Azure hosted virtual machine with Fiddler installed on an internet accessible IP address. I want to be able to capture and decrypt HTTPS traffic for troubleshooting purposes from any device - iOS, Android, Windows, Mac, or Linux.

What I really wanted to achieve here is for client devices to be able to get to the 'Fiddler Echo Service' landing page to be able to download the Fiddler certificate from my Fiddler proxy server, which is used for HTTPS traffic decryption. I want devices to be able to do this easily whether or not the device is already configured to send traffic through my Fiddler proxy server or not. There is some additional configuration in Fiddler beyond what I was able to find documented, so I wanted to make note of it here. Partly so this is discoverable for anyone, partly so that when I forget the steps I have somewhere to go look it up again.

Prerequisites

  1. You need a Windows client machine with a public IP address. I want to capture from different machines on different networks.
  2. Install Fiddler.
  3. Add an inbound firewall rule for client devices to connect to port the Fidder proxy is running on. For example, in my case I added an inbound firewall rule to allow 9988.
  4. Make sure both 'Capture HTTPS CONNECTs' and 'Decrypt HTTPS traffic' are selected in Fiddler under the Tools menu, Options, HTTPS tab.
  5. Set your Fiddler listening port to match your inbound firewall rule. Go to the Connections tab, change the port Fiddler listens on to something less standard than 8080 or 8888, then check the 'Allow remote computers to connect' option.

The Fiddler secret sauce

This part had my mind running in circles for a couple of days. Eventually I spoke to my colleague Jason for some guidance. He's a big fan of Fiddler, even he does not think this method has been documented before now.

  1. Per the above you should by now have Fiddler capturing and decrypting traffic on the local computer.
  2. However to make sure Fiddler is capturing traffic, open a web browser and go to google.com on the computer you have Fiddler running on, you should see the traffic captured in the tool. You should also see 'Capturing' in the bottom left hand corner of the tool.
  3. Clear all sessions to make the next steps easier.
  4. On your Fiddler computer open a web browser and go to https://localhost:9988 or what ever port number you set in step 5 above.
  5. We are expecting to see the 'Fiddler Echo Service' web page. If you do not, check the prerequisites section or post comments below.
  6. Download the FiddlerRoot certificate, save it, it does not matter where. We are not going to use the saved file, we are in fact going to use the Fiddler certificate, captured by Fiddler to serve up to client devices.
  7. Stop capturing. Notice we do not enable this again, we do not need to capture any more local traffic.
  8. Back in fiddler select all frames on the left hand side, then CTRL click the two frames shown below in Fig 1 to deselect those frames. Everything else is just noise, including the favicon. Remove the selected sessions.
  9. We want to only see the two frames shown below in Fig 1.
  10. You now want to click on the AutoResponder tab shown below in Fig 1.
  11. Drag and drop the two frames from the left panel to the right panel.
  12. This creates two rules for the AutoResponder.
  13. Ensure you check both 'Enable rules' and 'Unmatched requests passthrough'.
  14. Look towards the bottom of the rule list and you will see rule editor.
  15. Your rules will currently say 'EXACT:https://localhost:9988/ ' for example.
  16. You need to edit these so they resemble the rules in Fig 1 below. In my example the rules are changed to ' :9988/ ' and ' :9988/FiddlerRoot.cer'. Without those quotation marks!
  17. Make sure to click Save on the bottom right as you edit each rule.
  18. Optional/Additional: On my remote client machine (actually another Windows computer) with or without proxy settings setup to direct web traffic to my Fiddler proxy, I can now load the Fiddler Echo Service page. However I found I could not download the certificate. This was fixed by 'Promoting' the FiddlerRoot.cer rule above the :9988/ rule. Right click on the Fiddler.cer rule and click Promote.
  19. Update: I reran through this whole doc on a new VM to validate the instructions and I needed to do this a second time around as well.

Fig. 1

End state notes

  1. I have a Fiddler Echo Service page which loads for any client on the internet, regardless of whether the machine / device is sending web traffic to the Fiddler proxy already or not.
  2. Clients need to download the certificate from this service page, install it and trust it, so the Fiddler proxy can decrypt the traffic without web services throwing certificate warnings.
  3. I can have mobile devices (iOS/Android), Windows or any other device for that matter route traffic through this proxy, so the requests/responses can be captured and reviewed for troubleshooting.
  4. Typically this setup is going to be used for in-house repro's of customer issues. This is not a web proxy for any kind of production use.
  5. Why did we remove the EXACT:https://localhost from the rules? We need to allow any host using whatever host name they like to connect to the service. The rule with localhost would only allow the computer running Fiddler to connect.
  6. A note on security: Should you leave Fiddler running on your internet connected Windows VM? No you should not. We only want this service online when we need it to troubleshoot. Simply make sure the Fiddler application is closed. Run a netstat -ano | find "9988" to validate the port is no longer listening if you like. Better still if you are running this in Azure like me, shut the VM down and save some pennies. Job done.