I manage a web server. It is an internal web server used for testing traffic, but it is a web server all the same. And since it is not a production web server, I have a fair amount of carte blanche to try things on it and learn.
One of the things I wanted to do was to watch the incoming requests and their responses using fiddler from the web server itself. Turns out it is not obvious to do (unlike outbound traffic from your web apps, which you can watch by running fiddler and running your app pool as the logged in user). Here’s what I found out.
HTTP reverse proxy
Setting up HTTP proxy is pretty simple. Let’s say you have a web server that’s serving up content on HTTP (port 80, or whatever other port you have configured). You can make Fiddler listen on another port, let’s say port 8889 and redirect it to port 80, while also watching the traffic. Now if you open your web browser and browse to http://yourserver.yourdomain.ext:8889 fiddler will reroute that traffic to port 80 + watch that traffic for you. To do this:
- Open registry editor (run > regedit), go to “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2” and add a DWORD named “ReverseProxyForPort” with decimal value = 80 (or whatever port your http server is listening to). This will cause fiddler to redirect traffic it captures onto port 80.
- Within Fiddler, tools menu > Fiddler options > connections tab, specify port number for Fiddler to listen on (we’ll use 8889), and check “Allow remote computers to connect.” This requires restarting Fiddler, plus you may see the User Access Control warning for enabling firewall rules to allow the port you are listening on (8889) to be exposed to the network.
Now, with fiddler running on the web server, browse to your site from another computer, with port 8889 specified in the url, and you should be able to watch the traffic on fiddler.
HTTPS reverse proxy
Creating an HTTPS reverse proxy is slightly different, since the “Allow remote computers to connect” option in Fiddler above does not support the SSL handshake. So instead you have to use the Fiddler QuickExec box (The black box below the left pane – you can get to it with ALT+Q) and issue the listen command to make an ssl listener. Also, since the ReverseProxyForPort registry key above does not do SSL, you have to Customize Fiddler rules and modify the OnBeforeRequest to reroute the SSL request.
- Modifying the OnBeforeRequest method: To do this, within Fiddler, go to Rules menu > Customize rules. There, find the OnBeforeRequest method. At the very top of this method, add code to catch connections to yourserver:8888 (8888 is the port we’ll use for our proxy) and route that to port 443 (or whatever port your SSL end point listens on)
if ((oSession.HostnameIs("yourserver")) && (oSession.oRequest.pipeClient.LocalPort == 8888)){
oSession.Host = "yourserver:443";
}
- Next, make fiddler listen with SSL on port 8888. To do this, go to the QuickExec box (either click in the black box below the left pane, or use ALT+Q), and enter this command:
!listen 8888 yourserver
This causes Fiddler to start listening, and you get a confirmation dialog to the same effect. Now if you open your browser and navigate to https://yourserver:8888, you can see the traffic in fiddler, and it gets rerouted with SSL onto port 443.
Advanced stuff
For both HTTP and HTTPS, you could run your web server on a different port than 80 or 443 respectively. Then you can setup the reverse proxy on 80 or 443 respectively, and now you can watch traffic without having to explicitly specify port.
Nasty stuff
The observant among you have noticed that in the OnBeforeRequest, you are setting a new host endpoint. This actually does not have to be on the same machine. For example, in the above, I could instead do oSession.Host = "www.google.com:443"; and it works. Now you can navigate to https://yourserver:8888 and you will get google.com but you will also be watching the traffic.
Let’s say you are the network manager of an enterprise network. You could override the local dns server to point google.com at another machine (middleman), and within that machine explicitly set google.com back to the right IP address in the local hosts file. Next run the proxy on port 443 on your middleman machine and route it to back to google.com:443. Since the middleman itself has google at a different IP, this won’t cause infinite recursion. So now you’re watching your entire enterprise’s google traffic.
Please don’t use this to do harm. The above is a theoretical discussion of how bad you can get; but be warned that this could get you in jail. However, you may find need to put a middleman to debug why a website/webservice is misbehaving – make sure your users are aware that this is happening.
References:
.
