In addition to the HTML Forms-based and HTTP Authentication protocols, a third authentication type is used for high-security sites. HTTPS Client Certificates are a very strong form of authentication used in some high-stakes scenarios like banking and document-signing. When using Client Certificate authentication, the client supplies a client certificate to the server that cryptographically proves the identity of the user.
One of the key design goals of Client Certificate authentication is to prevent network intermediaries (like Fiddler) from abusing the client’s credentials. Even if the client application sent its certificate to Fiddler, Fiddler cannot successfully reuse that certificate to respond to the server’s demand, because the client never provides Fiddler with its private key.
To resolve this limitation, you can supply any necessary client certificates and private keys directly for Fiddler to use when handshaking with the server. By default, if a server prompts the client for a certificate, Fiddler will look inside the %USERPROFILE%\Documents\Fiddler2\ folder for a file named ClientCertificate.cer and will use that certificate when responding to the server’s certificate demand.
In some cases, you may want to use a different client certificate for each secure connection. To do so, specify the location of the certificate using the https-Client-Certificate property on the CONNECT tunnel to the secure server. For instance, you can write code like this:
static function OnBeforeRequest(oSession: Session) {
if (oSession.HTTPMethodIs("CONNECT") { if (oSession.HostnameIs("exampleA")) {
oSession["https-Client-Certificate"] = "C:\\certs\\CertA.cer";
} else
if (oSession.HostnameIs("exampleB")) {
oSession["https-Client-Certificate"] = "C:\\test\\CertB.cer";
} } //...
A .CER file does not contain the private key associated with the certificate’s public key. Instead, the .CER file merely acts as reference to Windows’ Personal certificates store (certmgr.msc). The Windows certificate store holds the private key associated with the certificate and releases it only as needed. Client certificates stored on a Smartcard will automatically appear within the Personal store when the Smartcard is inserted:
112 | Configuring Fiddler and Clients
When the Smartcard is inserted, you may export a .CER file from certmgr.msc and use it just like any other client certificate. Note that your Smartcard must remain inserted for Fiddler to use its private key.
If the desired certificate isn't yet installed Windows’ Personal certificates store (e.g. you only have a .pfx file) you must first import it into the certificate store, then export a .CER file. After your certificate is installed, simply right-click the certificate and choose All Tasks > Export…. Save the .CER file to either the default
ClientCertificate.cer location or the location you will specify via the https-Client-Certificate flag.
Inspectors
114 | Inspectors
O V E R V I E W
Fiddler’s Inspectors are used to display the request and response for the selected Session in the Web Sessions list.
Inspectors appear in two places: On the Inspectors tab in the main Fiddler window, and in the standalone Inspect Session windows. The latter are opened using the command on the Web Sessions context menu.
On the Inspectors tab, the Request Inspectors are shown in a panel at the top, and the Response Inspectors are shown at the bottom. You can switch between Inspectors by clicking on the desired Inspector’s name (e.g. HexView).
When you first double-click or press the Enter key on a session in the Web Sessions list, the Inspectors tab will become active. Each request or response inspector will be polled to ask it how applicable it is to inspecting the selected request and response. For instance, the ImageView Inspector returns a high “score” for image/* types while returning a low score for textual types. In contrast, the TextView Inspector returns a high score for textual types and a low score for binary formats.
Whichever inspectors return the highest score for the Session will become active. To force Fiddler to always activate a particular Request Inspector, set the fiddler.ui.inspectors.request.alwaysuse preference to the title of the Inspector’s tab. To force Fiddler to always activate a specific Response Inspector, set the
fiddler.ui.inspectors.response.alwaysuse preference to the title of the Inspector’s tab.
A thin blue line splits the top and bottom panels; you can use the mouse to move the line and resize the panels.
Double-clicking the line will maximize the Response Inspectors panel, as this is the panel most users use most of the time.
115 | Inspectors To get even more display area, the Inspectors tab can be extracted from the main window, either by clicking the Tearoff button in the toolbar or by typing the command tearoff in the QuickExec box. Closing the Inspectors window will return them to their default position on the main window.
Right-clicking on an individual request or response inspector’s tab will show a menu containing two options:
Inspector Properties and Hide Inspector. The first shows information provided by the Inspector about itself, while the second will remove the inspector from the Inspectors tab. To restore a hidden Inspector later, edit the
fiddler.inspectors.hidelist Preference and restart, or hold the SHIFT key while starting Fiddler.
By default, the Inspectors are ReadOnly when inspecting a session, unless the session is currently paused at a breakpoint. Additionally, the Inspectors will permit editing if the session is in an Unlocked state, which can be achieved by using the command on the Edit menu. Most Inspectors will display with a specific background color while in ReadOnly mode, and a different color (typically white) when editing is permitted. The default ReadOnly color is light-blue, and can be changed using the Tools > Fiddler Options > Appearance tab.
The remainder of this chapter will describe each of the Inspectors included with Fiddler.
116 | Inspectors
A U T H
Type Request & Response Allows Editing No
Fiddler’s Auth Inspector interprets the contents of the Authorization- and Authentication- related headers on requests and responses. Typically, these headers can be found on HTTP/401 and HTTP/407 responses that demand credentials, and the subsequent requests that provide the requested credentials.
For instance, if you enable the “Require Proxy Authentication” rule in the Rules menu, Fiddler will return a HTTP/407 response demanding that the user supply credentials for each request. This demand is made by the Proxy-Authenticate header, which the Auth Response Inspector displays:
After the user enters the name UserName and the password SecretKey in the browser’s Authentication dialog, the browser’s subsequent requests supply a Proxy-Authorization header with the user’s credentials. Since the authentication scheme in use in this scenario is HTTP Basic, the credentials are encoded using base64 encoding. The Auth Request Inspector decodes the string automatically and displays it in plaintext:
Of course, most websites will use a stronger form of authentication, either HTTP Digest or the Windows NTLM or Negotatiate schemes. The latter are especially popular on Windows networks.
Fiddler’ Auth inspector knows how to parse NTLM blobs and will show you the information contained within those blobs, like so:
-[NTLM Type3: Authentication]--- Provider: NTLMSSP
Type: 3
OS Version: 6.2:8329 Flags: 0xa2888205
Unicode supported in security buffer.
Request server's authentication realm included in Type2 reply.
NTLM authentication. Negotiate Always Sign. Negotiate NTLM2 Key.
Target Information block provided for use in calculation of the NTLMv2 response.
Supports 56-bit encryption. Supports 128-bit encryption.
117 | Inspectors lmresp_Offset: 134; lmresp_Length: 24; lmresp_Length2: 24
ntresp_Offset: 158; ntresp_Length: 396; ntresp_Length2: 396 Domain_Offset: 88; Domain_Length: 14; Domain_Length2: 14 User_Offset: 102; User_Length: 14; User_Length2: 14 Host_Offset: 116; Host_Length: 18; Host_Length2: 18 msg_len: 554
Domain: REDMOND User: ericlaw Host: ERICLAWT8
lm_resp: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nt_resp: 42 40 AE AB 3E D7 7F 02 B5 F9 76 D7 C9 5E 6B 82 01 01 00 00 00 00 00 00 05 96 B2 D4 01 23 CD C1 D3 D9 8A 33 47 87 40 3D 00 00 00 00 02 00 52 ...
The Auth Inspector cannot currently parse Kerberos authentication messages, but will show the decoded bytes of the challenge and response.
118 | Inspectors
C A C H I N G
Type Response only
Allows Editing No
The Caching Response Inspector examines the HTTP response headers to determine whether the selected response is cacheable under the rules of HTTP, and if so, for how long. It consults the response headers Cache-Control, Expires, Pragma, Vary, ETag, Age, and Last-Modified in its evaluation of the response.
Some browsers (including Internet Explorer) support the specification of caching information in HTML documents using META HTTP-EQUIV tags. The Caching Inspector scans responses that have a HTML Content-Type and will display any HTTP-EQUIV or PRAGMA directives found in the markup.
For responses which do not explicitly specify their cacheability or freshness lifetime, the Caching Inspector will compute the “heuristic freshness lifetime” using the Last-Modified header and the algorithm suggested in RFC2616.
You can learn more about how browsers utilize caches at http://fiddler2.com/r/?httpperf.
119 | Inspectors
C O O K I E S
Type Request & Response Allows Editing No
The Cookies Inspector displays the contents of any outbound Cookie and Cookie2 request headers and any inbound Set-Cookie, Set-Cookie2, and P3P response headers. Note that the Cookie2 and Set-Cookie2 headers are uncommonly used and not supported by Internet Explorer and some other browsers.
The display of the cookies is basic (you can see the same information in the Headers inspector). This Inspector’s value primarily consists of examining the P3P response header, if present, to determine whether the cookie is likely to be stored. P3P (Platform for Privacy Preferences) is a standard whereby the server can communicate to the client how it will be using the cookies that accompany the P3P header.
Set-Cookie: ASPSESSIONIDCCBTDCRD=CIFKIKJDFMJFFODAJPFMFKGN; path=/
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
The tokens in the P3P header’s CP (Compact Policy) string are interpreted by the Inspector and their meaning is listed:
The Inspector will further evaluate the string to determine whether the cookie is deemed “acceptable” by the default privacy policy used by Internet Explorer. It’s worth mentioning that some sites (Facebook and Google, as of this writing) send invalid P3P statements to circumvent the browser’s privacy features. Under the rules of P3P, unknown tokens (like those sent by such sites) are deliberately ignored.
The Cookies Request Inspector displays the size of the outbound Cookie header, helping identify over-sized cookies to eliminate or shrink to improve the network performance.
The Cookies Response Inspector flags common problems. For instance, Internet Explorer will refuse to set a cookie for any server whose hostname containing an underscore character, and the Inspector will warn you if it encounters this condition.
120 | Inspectors
H E A D E R S
Type Request & Response Allows Editing Yes
Every HTTP request begins with plaintext headers that describe what resource or operation is sought by the client.
The first line (the “Request Line”) of the request contains three values, the HTTP Method (e.g. “GET” or “POST”), the URL path which is being requested (e.g. “/index.htm”), and the HTTP version (e.g. “HTTP/1.1”). Following the Request Line are one or more lines containing name-value pairs of metadata about the request and the client, such as the User-Agent and Accept-Language.
Similarly, every HTTP response begins with plaintext headers that describe the result of the request. The first line of the response (the “Status Line”) contains the HTTP version (e.g. “HTTP/1.1”), the response status code (e.g. “200”) and the response status text (e.g. “OK”). Following the Status Line are one or more lines containing name-value pairs of metadata about the response and the server, such as the length of the response file, its Content-Type, and information about how the response may be cached.
The Headers Inspector allows you to view the HTTP headers of the request and the response, showing the name-value pairs in a treeview below the Request Line or Status Line. The name-name-value pairs of headers are grouped based on their function and then sorted alphabetically by name. Groupings are simply for your ease of reading, and are not sent on the network. For Request headers, the groups include [Cache, Client, Entity, Transport,
Cookies/Login, Miscellaneous]. For Response headers, the groups include [Entity, Transport, Cookies/Login, Security, Miscellaneous].
By default, the contents of the Headers Inspector are read-only and cannot be edited. While in ReadOnly mode, the background color of the treeview and the Raw Headers box will display using the ReadOnly appearance color (light-blue). When you select a Web Session paused at a breakpoint, or when you select the Unlock for Editing option on the Edit menu, the Headers Inspector is shown in Edit mode. While in Edit mode, the background color is the default window color (white), and the contents of the headers may be edited.
Click the Raw hyperlink at the top-right of the Inspector to display the plaintext of the headers as they are sent on the network. Click the Header Definitions link to view a help topic describing common HTTP headers and their use.
Due to limitations in the Windows treeview control, only the first 260 characters of the header’s name and value are shown. To view headers which exceed this length, select the header and press Enter or F2, or right-click the header and choose View Header. The Header Viewer window will open in read-only mode and allow you to inspect the full name and value. The length (in characters) of the value will be displayed in the title bar of the window.
While the Inspector is in ReadOnly mode, any Cookie request headers are broken out into name-value pairs for easier reading. While in Edit mode, any Cookie header is shown as a single line as it is actually sent to the server.
121 | Inspectors