Re: Intermittent E_NOINTERFACE error, possibly RPC related


"Paul Baker [MVP, Windows - Networking]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
wrote in message news:egwRUe0WHHA.3568@xxxxxxxxxxxxxxxxxxxxxxx
Michael,

Symantec's "Norton Internet Security (NIS)" is so brain-dead that it
can't
figure out HTTP content that has been gzip-compressed. The Symantec
solution, astoudingly, was to change the request header, so that if your
browser (or, in my case, the client app that I had written) sent a
request
with a "Accept-Encoding: gzip, deflate" header, Symantec changed it to
"Accept-Encoding: ----, -------" (literally, with the dashes), before it
let
the request out onto the wire, so as to suppress the server's return of
gzip'ed content. Their current version of NIS is almost worse:
"WARNING:
New Norton Internet Security Issue" at
http://www.port80software.com/200ok/archive/2006/01/04/901.aspx

I am reading about the Accept-Encoding header for the first time. However,
my understanding is that if they just changed it to Accept-Encoding
compress:q=0, gzip:q=0, they would prevent the response from being
compressed and solve their perceived problem.


http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3Accept-Encoding

However, they should not consider a compressed response to be a problem.
By
preventing it, they may be breaking an application that requires it (even
though perhaps it shouldn't). If they really want to scrutinize the data,
why not decompress it and scrutinize that on the fly?

Is it really that simple?

Paul



Obviously it would be pure speculation for me to guess on the reasons why
Symantec did what it did.

But my reaction at the time when I encountered the problem was exactly the
same as yours now: They should have left the header and the response alone,
and internally decompressed the response on the fly when they applied their
security checking.

My guess as to why they didn't do so, is that they couldn't and still meet
delivery schedules. They probably encountered the "problem" late in
development, at a point where they couldn't implement on-the-fly
decompression into the then-current architecture.

Even so, that still doesn't explain the absurd "solution" implemented now,
in their current release of NIS, as detailed at the port80software link I
gave.

Mike


.

Relevant Pages

  • Re: Intermittent E_NOINTERFACE error, possibly RPC related
    ... the Content-Length header in the response, ... I am reading about the Accept-Encoding header for the first time. ... they should not consider a compressed response to be a problem. ... why not decompress it and scrutinize that on the fly? ...
    (microsoft.public.win32.programmer.networks)
  • Re: Making a HttpHeader persist.
    ... > I'd appreciate any advice on how to generate a Request Header for testing ... That would be done by modifying the client browser configuration somehow. ... > automatically "stick around" and be appended to the Request header). ... you are adding it to the Response. ...
    (microsoft.public.dotnet.framework.aspnet)
  • [REVS] HTTP Response Smuggling
    ... Amit Klein shows that HTTP Response Splitting is still possible. ... Proxy Server 4.0, DeleGate 8.11.5) simply allow LF where CRLF is expected. ... a Content-Length header of his/her own. ...
    (Securiteam)
  • Whitepaper by Amit Klein: "HTTP Response Smuggling"
    ... several anti- HTTP Response Splitting strategies has ... the attacker injects a Content-Length header of his/her own. ...
    (Bugtraq)
  • Re: How to judge whether content type is truly "text/html"?
    ... Kevin Spencer wrote: ... the reason for the ContentType header is to tell the client what ... HTTP response header. ...
    (microsoft.public.dotnet.languages.csharp)