How to Generate a Fiddler SAZ File

Fiddler is a free program that will log HTTP and HTTPS requests on Windows.  These instructions demonstrate how to use Fiddler to create an archive file (.SAZ) of these requests for troubleshooting purposes using the full version of Fiddler.  As an alternative, there is a simplified version of Fiddler available that only supports capturing here: http://fiddlercap.com.

Warning: Distributing a SAZ file is potentially a massive security risk, especially if HTTPS decryption was enabled during the traffic capture, because any secrets that are sent over the wire (including even passwords or session cookies) will be included in the file.  You can use Fiddler to AES-encrypt the SAZ file using a password via the save dialog, but you must still treat the exported SAZ file (and password) with extreme care!!

1. If the web site that you need to profile uses HTTPS, please consider getting a dedicated VM set up for installing Fiddler.  This will make trusting the Fiddler certificate (essentially a self-inflicted man-in-the-middle attack) less problematic.  There are instructions on how to do that here if you’re going to be testing with old IE versions.
2. Go to http://fiddler2.com and download Fiddler.  You can use either the .NET 2 or .NET 4 version depending on which version of the framework you have installed.  Install it accepting the defaults and run it.
3. Do not perform this step if the site that you need to profile is HTTP-only.  If the site that you need to profile uses HTTPS, open Tools… Fiddler Options… HTTPS tab.  Enable “Decrypt HTTPS traffic”.  When the SCARY TEXT AHEAD dialog comes up, click “Yes” to trust the Fiddler Root certificate, and then click “Yes” again to acknowledge that you want to allow man in the middle attacks on this computer (which is how Fiddler can decrypt your HTTPS traffic (good), and how malicious actors who also have a copy of the Fiddler certificate could too (bad)).  More information is available here: http://docs.telerik.com/fiddler/configure-fiddler/tasks/DecryptHTTPS
   
   
4. If you want to use a browser other than Internet Explorer to generate the SAZ file, you may need to follow additional instructions here: http://docs.telerik.com/fiddler/configure-fiddler/tasks/ConfigureBrowsers 
5. Minimize Fiddler, and now browse to the site you want to test.  Tab back to Fiddler and you should see the HTTP and HTTPS calls that were made while the capture was running.  For example, here is a visit to the www.google.com homepage.  To see the session details, select the Inspectors tab, and click the “Raw” on both the top and bottom panels – this allows you to see the exact text that was requested from the server by the browser and the browser’s exact response.
   
   
   In this screenshot, you can see the list of sessions that happened as a result of accessing www.google.com.  When I clicked on a session at random, I was able to see the details on the right-hand pane when I selected Inspectors and then Raw on the top and bottom section.
6. To export the SAZ file, select the sessions that are interesting in the left-hand pane and click File… Save… Selected Sessions… in ArchiveZip…  Select “Password Protected SAZ” in the “Save as type” field.  “Save the SAZ file in a secure location.  It’s best to exclude things like login pages or other forms with secrets if they’re not relevant to the issue you’re troubleshooting because exported SAZ file will contain any secrets that were transmitted (including HTTPS transmitted items if HTTPS Decryption is enabled).  Choose a strong password.  You will need to share this password with whomever you wish to open the file.
7. Securely provide the SAZ file and password to whomever needs it.  Again - this file contains EVERYTHING that was sent on the computer via HTTP (and potentially HTTPS) including potentially passwords, session cookies, and other secrets that can be read in clear text if you have the SAZ password.  It is critically important to care for this file and the password in a secure manner!! (Can you tell that this is important?)
8. When the other party has the SAZ file on their computer, they can open it by opening Fiddler and clicking File… Load Archive…
9. If you enabled HTTPS traffic decryption, your computer is still at risk until you perform the following two steps:
1. Disable HTTPS decryption by opening Tools… Fiddler Options… HTTPS tab, and unchecking Decrypt HTTPS traffic.
2. Also, click the “Remove Interception Certificates” button to delete the Fiddler certificates.
   
   See: http://stackoverflow.com/questions/16827901/how-do-you-remove-the-root-ca-certificate-that-fiddler-installs 

Setting up an Internal Friendly URL

Note: This solution is not necessarily the best or most efficient solution in all cases.  It is, however, very simple and works with any site - even ones you have no control over.

Problem:

Internal Web System XYZ must be accessed via an ugly URL such as http://randomservername.internalexample.com:8675309/SomeCrazyPath/SomeFile.htm

Desired End State:

Internal users should be able to type in a friendly URL (such as http://myapp.internalexample.com) and get sent directly to the "homepage" of the desired system.  Search result optimization and using deep links with the friendly URL are not required.

One Solution Using IIS 7.5 (should work with earlier versions by hunting for the same options):

• Register myapp.internalexample.com and other related host names such as dev-myapp.internalexample.com in your organization's DNS.  If the server where you will be hosting the friendly URL is more likely to change its IP address instead of its name, use a CNAME record; if the server is more likely to change its name but keep its IP address, use an A record.
• Open your IIS Manager and right-click Sites... Add Web Site.
• The site name should be "myapp.internalexample.com (redirect)".
• The physical path should be a folder in a secure location local to the web server.  (whatever is appropriate for your environment - it will only require a few KB of storage).
• Set the host name to "myapp.internalexample.com" .
• Hit OK.  This should create the site and start it automatically.
• Go to the "HTTP Redirect" option under the IIS section for the new site, and check the box for "Redirect requests to this destination".
• Set the destination to your application's "real" full URL including the protocol (http or https), port numbers, deep path, document, query string, etc.
• Check the box for "Redirect all requests to exact destination (instead of relative to destination), but do not check the box for "Only redirect requests to content in this directory (not subdirectories)".
• The default status code "Found (302)" is fine.
• Click the crazy Apply button in the far upper right. 
• Next, open the "HTTP Response Headers" option  
• Click the small "Set Common Headers..." button in the actions bar (upper right).
• You can uncheck "Enable HTTP keep-alive" and set the box to expire web content "Immediately".
• Click OK.

• Clients should now get redirected to the main site by visiting the friendly URL.  Because the HTTP header indicates that the content expires immediately, the IIS server hosting the friendly URL will be hit every time.  Since the only response is an HTTP redirect enforced by IIS (< 500 bytes), the load should be very light except in the most extreme circumstances, and this gives you the ability to easily change the redirect URL at some point and have the change take effect immediately.
• If you want to include content in the root folder for the web site to make the intention clear to a server admin browsing to this folder, you can create a default.htm file with the following content:
  
  <!DOCTYPE>
  <html>
  <!-- Note: This site is redirected via IIS Settings.  This  page should actually never be seen or used. -->
  <head><meta http-equiv="Refresh" content="0;url=http://myapp.internalexample.com" /></head>
  <body><a href="http://myapp.internalexample.com">Click here to continue to the site.</a></body>
  </html>

Please note, though, that this extra step is absolutely not required, though, since the IIS server should be ignoring all site content due to the HTTP Redirect setting.  It could also "get stale" in case the redirection URL is updated in IIS but not in the HTML file which could cause more confusion.

 

Raw Request to http://dev-mysite.mydomain.com (captured with Fiddler):

Raw Response from IIS (captured with Fiddler):