Information on SP2

As you know, there has been a flurry of information on whether or not to install ISA 2004 SP2 and what happens afterwards.

Here's the situation, SP2 contains some new features which add to the security that ISA can provide to our networks. Therefore after you install SP2 you might come across a few websites that will error out. While it might look like it's SP2 causing the problem it's actually the website causing the problem by not following the rules.

There are two things that are causing headaches for those that rushed to install SP2, compression filtering and HTTP Request Smuggling. The new compression filter is "on" by default under SP2. If you access a website that attempts to place a compressed file on your box using anything other than gzip encoding, it will fail. Most, but not all websites use gzip encoding. If you need to use a website that doesn't you'll have to disable compression filtering. For an explanation of HTTP Request Smuggling protection, we turn now to our guru, Jim Harrison...

Disabling filters may not help with www.delta.com, www.sun.com or any
site that causes ISA 2004 SP2 to generate the following message:

Error Code: 502 Proxy Error. The HTTP request includes a non-supported header. Contact your ISA Server administrator. (12156)

The reason for the behavior youre seeing is that new logic that was added in ISA 2004 SP2 to mitigate HTTP request smuggling The process for this attack is a bit involved but the short story is that HRS depends on sending response headers that include both Content-length: and transfer-encoding: chunked.

A whitepaper on the subject is available here:
https://www.watchfire.com/securearea/whitepapers.aspx

RFC-2616 defines those two headers for the purpose of providing quantitative content validation for the receiver and states *very clearly* that the server MUST NOT combine them in the same response.

If the server is configured such that it does violate this edict, RFC-2616 then requires the receiving entity to ignore the content-length value and instead use the chunked-encoding technique to validate the length of the HTTP body.

This places a processing burden on the receiving entity (ISA, in this case), since a chunked-encoded transfer can't be quantitatively validated until the transfcompletedeted. In the case of a proxy, additional processing is imposed due to caching behavior that may be dependent on content-size.

The reason those sites are either failing outright (www.delta.com) or rendering poorly (www.sun.com) is because we chose to reject those responses out of hand. Since RFC-2616 clearly states don't combine those headers and doing so is a demonstrably malicious act, it seemed unlikely that ISA would cause problems for any other than malicious sites, and in fact, our testing validated this belief.

As it turns out, there are quite a few legitimate sites out there that violate this part of RFC-2616 and so we have had to rethink our answer to this problem.

PSS will have a public fix available shortly.
Jim

There's going to be a hotfix. Not because ISA did anything wrong but because there are enough sites out there causing pain for MS customers, that they are going to change things accommodate them.

I for one, am not disappointed by SP2. The security improvements are significant, I just wish we didn't have to dilute security to accommodate a few sites not playing by the rules. It's really the same thing we do for Java apps that won't authenticate or workstation apps that won't run as anything but local admin. It's a compromise and it's one we should be complaining about loudly. This time, not at Microsoft but at the legions of others not playing by the rules.

UPDATE: Click here for the hotfix.