When troubleshooting website issue (such as parts of the website not loading, infinite redirect loops, and so on) the web debugger tools Fiddler2 comes in handy. This is especially so when troubleshooting HTTPS issues. Wireshark is a bit difficult to use when troubleshooting encrypted sessions because unless you are given the private keys from the server, wireshark cannot decrypt the traffic leaving you blind for the most part. During Fiddler’s installation you are given the option to put a certificate into the PC’s Trusted Certificates, effectively turning Fiddler into a man-in-the-middle proxy that can decrypt the sessions. This article makes a note of some of the features of the program and how to tackle troubleshooting using this program.
1. I’m getting swamped with all the information that’s being captured by Fiddler. How do we trim this information down to what’s really necessary.
One of the big advantages of fiddler is that it is an independent program, which means it has the capability to intercept any program you want, it’s not limited to a single browser (like HttpFox for example).
This advantage can rapidly turn into a disadvantage if too many programs are accessing the internet, leaving you with too much information to parse. Fiddler has several “levels” at which you can filter data. The first I use is the process filter. On the bottom left of the screen you will see an icon showing “capturing”
Click on this to turn capturing off. You can click on the “all process” to change the subset of process you’d like to capture. I personally prefer to use the “process filter” button on the top menu. If you click and drag this icon over the browser you are using for testing, fiddler will capture traffic coming only from this process
If you need further, more granular filtering, then you can use the filters tab on the right hand side. You can see several options to show only certain hosts, responses, sizes, and so on:
2. Can I modify the HTTP requests / responses as they pass by?
Definitely. There are various ways… the ways I use depend on my needs. The filter tab I show above has the ability to delete or set any request / response headers. This is perfect if you know exactly which header you need to experiment with.
You can also use the “request builder” tab. This is really useful if you have already captured some sample traffic and would like to change or fuzz it to see how the client/server responds. You simply need to click and drag the captured request, and you’re free to change it at will, and then just hit the “execute” button to send to the server:
As a side note, you can also easily change the user-agent that is sent to the server from the “rules > user-agent” menu
3. How can we tell which part of the page is taking so long to load?
Use the “timeline” tab. First, highlight the requests in the left hand pane that you’d like to monitor, then you should see how long each element takes to load:
4. Can we capture traffic generated by hosts where fiddler is not installed?
Yes. fiddler can be used as a fully-fledged proxy, and you can allow remote PCs to use it. So you can setup a testlab where only one machine has fiddler installed, while the other machines simply point to fiddler in their proxy settings. This is especially useful if you need to debug linux machines, since fiddler is a windows only program 😦
Tools > fiddler options > connections > “Allow remote users to connect”
You can confirm this works by running the following in a CMD:
5. Miscellaneous Tips
– You’ll spend most of your time living in the “Inspectors” tab. I usually enable the “auto decode” option so the inspectors will show the captured data in cleartext:
– When testing, it’s always a good idea to clear your cache and cookies before going into another test iteration:
you can also press CTRL while pressing the above to clear cookies