W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: delta encoding and state management

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 22 Jan 2013 14:33:59 -0800
Message-ID: <CAP+FsNeAMmKvH6i6Vk=igLefLjtr2Q5nBZ92GEgfWuf2+jZ6Ww@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "William Chan (?????????)" <willchan@chromium.org>, James M Snell <jasnell@gmail.com>, Nico Williams <nico@cryptonector.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 :)

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
Received on Tuesday, 22 January 2013 22:34:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC