4 ms·

> It intercepted the not-quite standard response header "Content-Encoding: ps-bzip2" to our windows client application, stripped off the header it didn't unders

> It intercepted the not-quite standard response header "Content-Encoding: ps-bzip2" to our windows client application, stripped off the header it didn't understand but, of course, didn't decompress the payload. I think this is actually a feature in many different products from different vendors. If I recall correctly, ISA Server (since 2004!) and the like inspect HTTP and SMTP traffic and validate it for conformance to published standards. If a malformed SMTP message comes in, it discards it. This prevents your mail server from being exposed to malformed messages, which could lead to denial-of-service/remote-code-execution/maybe it will be fine who knows.

pilif 11y ago
The content encoding header is meant to be extensible. This is where chrome added sdch and now we're about to get brotli compression in Firefox and chrome. If that release of trendmicro was still in use, people wouldn't be able to visit Google with chrome nor any upcoming site with brotli support. Also, if they didn't like my ps-bzip2 encoding, they could have also stripped it off the clients accept-encoding header, causing the server to not compress the response. But they left it there and just stripped off the content-encoding response header.
- Laforet 11y ago
  Headers are meant to be flexible in theory, but in reality it seems that anything outside the most common few are going to break things. The series of blog posts linked below might interest you. http://noxxi.de/research/http-evader-explained-2-deflate.html http://noxxi.de/research/http-evader-explained-2-deflate.htm...
dspillett 11y ago
> I think this is actually a feature in many different products from different vendors. It is, but it sounds badly implemented as described here. Stripping headers and sending on the rest of the message with no care for the content is bad design, you are essentially corrupting a request or response. If there is a problem with a message discard or quarantine the whole thing and log the event (in the case of SMTP perhaps send the target a "we blocked this, check with the sender if you really need it" and/or the sender a bounce if you are reasonably sure the sources headers aren't faked) for future analysis.

pilif 11y ago

The content encoding header is meant to be extensible. This is where chrome added sdch and now we're about to get brotli compression in Firefox and chrome. If that release of trendmicro was still in use, people wouldn't be able to visit Google with chrome nor any upcoming site with brotli support. Also, if they didn't like my ps-bzip2 encoding, they could have also stripped it off the clients accept-encoding header, causing the server to not compress the response. But they left it there and just stripped off the content-encoding response header.

Laforet 11y ago
Headers are meant to be flexible in theory, but in reality it seems that anything outside the most common few are going to break things. The series of blog posts linked below might interest you. http://noxxi.de/research/http-evader-explained-2-deflate.html http://noxxi.de/research/http-evader-explained-2-deflate.htm...

dspillett 11y ago

> I think this is actually a feature in many different products from different vendors. It is, but it sounds badly implemented as described here. Stripping headers and sending on the rest of the message with no care for the content is bad design, you are essentially corrupting a request or response. If there is a problem with a message discard or quarantine the whole thing and log the event (in the case of SMTP perhaps send the target a "we blocked this, check with the sender if you really need it" and/or the sender a bounce if you are reasonably sure the sources headers aren't faked) for future analysis.