Joe wrote:
It would be really helpful if someone from the AVAST team could comment
here - it would probably save a lot of ping-pong.
I
agree totally. It is very hard to make suggestions for a protection scheme when
we don't know what we are trying to protect from. Spontaneously, I
don't see why the firewall needs to protect us from long-term http connections.
Or rather, I don't see how we could create an exception scheme that couldn't be
mimiced by attackers.
Thanks, for reply Joe.
I
have good and bad news. Bad news are, that
"Transfer-Encoding:chunked"
gives not enought information for avast team,
because it only says, that the
length of transfered data is unknown at
beginning.
I have to say, I think this is being done the wrong way
around.
Surely it would be better to assume that chunked mode meant
drip-feed, and the special case things like compression (which are easy to
detect) rather than to assume chunked mode didn't exist (which it clearly
does) and special case a growing set of services that are hard to detect.
Today it's Lightstreamer, DWR, Google, Facebook, Jetty, Perbal, etc, etc, etc
but I expect the list will grow.
I
agree with Joe here. Chunked encoding has very well defined semantics: it will
send its data in chunks each prefixed with a byte length and the connection is
considered open/active until there is a byte length of zero returned to the
client. I can't see on what grounds the firewall should intervene and
prematurely abort this scheme based on another server
header.
The
suggested fix would probably have a short lifetime anyway as it can so easily be
copied by attackers' servers. With the current information at hand I don't think
there is much use customizing DWR to implement the header
fix.
Best
regards
Mike
Wilson
