How to determine if a client request contains a Multi-Line Header

 

This post is about an issue that I came across, while working on a case recently.

SCENARIO:

The scenario was a simple website publishing through ISA server 2006. While accessing the HTTPS website from a client, we were seeing a Failed Connection attempt in the ISA logs. More specifically, the error message was pointing to Error code 13, “the data is invalid” .  First, we made sure the rule elements were configured correctly.  Next, while reproducing the issue, we collected an ISA Data Packager with the “Web Proxy and Web Publishing” template selected…and also collected a decrypted SSL Network trace from the ISA server.

DATA ANALYSIS:

From the decrypted SSL trace, we could identify that the ISA server returned a response code of 400 (BAD REQUEST). Upon further inspection of the HTTP headers and payload (the request was a POST), we could not find any issue which was obvious. So we looked further into the ISA Tracing file, which is a component level trace collected by the ISA Data Packager.

In that trace, the request seemed to contain a Multi-Line header which is not allowed by ISA server, by default. Hence it is rejecting the request made by the client.  The ISA tracing contained the following error:

ERROR:Multi line header - unsupported

We then revisited the decrypted SSL trace and observed that there was a MultiLine header found.

This trace example contains a multi-line header

In an attempt to reproduce the issue, we also used a web debugging tool to construct a similar HTTP POST request with the same payload and same headers and that worked as expected!  When we checked the network trace from our repro, we could see that the header was not sent as a “Multi-line”.

This trace example does not contain a multi-line header

 

The following byte codes (highlighted above) can be indicative of a multi-line header:

0d – Carriage Return

0a – New line (Line Feed)

09 – Horizontal tab

More information about the byte codes and their corresponding mappings can be found in RFC2616.

RESOLUTION:

In order to resolve the issue, we opened the registry editor on the problematic server and navigated to HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\RAT\Stingray\Debug\Web Filters

and added a DWORD value APPEND_CONTINUATION_LINES and set the value to 1, and then rebooted the server.

The issue no longer occurred. The client was able to access the site successfully.

The solution to this issue has been addressed in detail in the following KB article:

http://support.microsoft.com/kb/941293

This fix appends the continuation tab, thereby enabling the ISA server to successfully read the headers and process it further.

I hope this post would be helpful in resolving issues that you may face while publishing web applications through ISA/TMG.  But always remember not to make any changes to the registry unless you have isolated the root cause of the issue. Also, as a general best practice, take a backup of the registry before making modifications.

Author:

Karthik Divakaran

Security Support Engineer – MSD Security Team

Reviewers:

Junaid Jan

Security Support Escalation Engineer - MSD Security Team

Richard Barker

Sr. Security Support Escalation Engineer - MSD Security Team