Re: delta encoding and state management

Yup. There might be some modicum of safety in there if the path prefix for
a group never changes once defined, and it was impossible for an attacker
to define a group and include elements from something else in it, but it is
definitely the kind of thing that tickles my funnybone and makes me run to
security folks :)
-=R


On Tue, Jan 22, 2013 at 2:29 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Jan 22, 2013 at 01:54:18PM -0800, Roberto Peon wrote:
> > The thing that isn't in delta, etc. already is the idea of 'rooting' the
> > path space with the single request (which I like, but... it is subject to
> > the CRIME exploit if path-prefix grouping is done automatically by the
> > browser (instead of being defined by the content-developer)).
>
> I think that if the path-prefix only contains complete path components (not
> just some chars), then we're fine with the CRIME attack because in order to
> make the browser merge requests, the attacker has to brute-force each path
> component's name. Also, as long as it remains a path, it doesn't unveil
> what
> is located behind, which generally contains the most interesting stuff.
>
> > IF we take your proposal for eliminating much of the common-path prefix
> and
> > ensure that it isn't subject to CRIME, that is a winner in any scheme.
>
> Let's face it, the CRIME attack is against optimizations for redundant
> elements. We probably need to spend more time analysing all the failures
> involved in the attack itself than refraining from optimizing redundancy.
> I mean, how a forged request from an attacker slips in the middle of valid
> requests and how we can prevent it from being merged, or at least have it
> in its own group.
>
> Willy
>
>