Port80 Software's labs have confirmed a troubling issue with Symantec Norton Internet Security version 2006 software running on Web clients that are sent compressed content.
httpZip 3.5 has provided a work-around for some time to Symantec Norton Internet Security versions' (up to 2005) issues with mangling a client browser’s request for compressed content (more), but this new issue is more troubling...
The Symantec Norton Internet Security (NIS) workaround that httpZip 3.5 employs (and which enabled by default) was intended to address a different problem, once that was caused by earlier versions of NIS. In those cases, NIS was preventing compression by dashing-out (literally replacing with dashes) the "Accept-Encoding: gzip, deflate" header in the browser's HTTP request. Since the request did not ask for compressed content, the server (or rather httpZip on the server) did not know to send it. The workaround deals with this by treating the dashed-out header as semantically equivalent to the header it replaces in the request.
This new NIS 2006 issue is quite different. The Norton product is now (when Internet Security is enabled) no longer changing the outbound request from the browser but is, instead, intercepting the inbound response, uncompressing it (if it is compressed) before it has reached the browser, and then reassembling it as chunked encoded data, with the Content-Length header dashed out, a break with HTTP protocol itself. If the response is compressed, NIS 2006 additionally dashes out the "Content-Encoding: gzip" that would normally signal to the browser that it needs to decompress.
All this is, in and of itself, a far superior solution to the old one of preventing compression from happening at all. NIS 2006 now allows the client to benefit from compression for the duration of the data's "flight" from the server, and then, by decompressing it before it reaches the browser, continues to provide a high level of security.
The problem is that NIS 2006 is acting like a transparent proxy here, but it is not handling HTTP itself correctly. The whole reason that the Internet "works" is because of such protocols agreements in terms of how data should be structured and sent between clients and servers. Hey, Symantec, if you guys build software that is going to act like a transparent proxy, please start acting like a well-behaved one!
Tune in later this week to find out what happens when you combine a) compressed content from the Web server, b) ColdFusion MX application server output, and c) Norton Internet Security 2006 on the client... to quote our Spanish-speaking friends, "Es un desastre" (think browser crashes, cats and dogs living together, mass hysteria).
Symantec sells a lot of units, but they sure don’t handle protocols well... One day, maybe they will respond to our friendly e-mails (we have tried for years with no real luck, although this new feature/fix/break/issue may be an indirect response).
More to come,
Port80