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

Re: padding and compression

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 24 Feb 2014 14:36:27 -0800
Message-ID: <CAP+FsNdWhev6-Y1g7Wu-uu7VeUGsyooSg6Ud0N8Zue74ot4F4w@mail.gmail.com>
To: Martin Nilsson <nilsson@opera.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I'd rather see user agent fingerprinting than have padding used poorly,
especially given that other behaviors (e.g. flow control) are likely to
allow for that per browser anyway, unfortunately :/

It is close to impossible to have every implementation use something like
padding the same way (even if just based upon the timing of how a browser
parses and lays out the DOM), and actively a bad idea if it is used in a
wrong fashion.

-=R
On Feb 24, 2014 1:48 PM, "Martin Nilsson" <nilsson@opera.com> wrote:

>  On Mon, 24 Feb 2014 20:53:38 +0100, Roberto Peon <grmocg@gmail.com>
> wrote:
>
> Anyway, security is a big and long discussion in and of itself. The
> guidance here should probably be to follow recommendations set by a
> different group and spec entirely :)
> -=R
>
>
> If padding strategy isn't coordinated though, it becomes a means for
> fingerprinting implementations.
>
> /Martin Nilssons
>
>
>
>
>
> On Mon, Feb 24, 2014 at 11:39 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> On 24 February 2014 00:48, Cory Benfield <cory@lukasa.co.uk> wrote:
>> > My understanding is that you pad any HEADERS or CONTINUATION frame out
>> > to some implementation-defined size, preventing an attacker from
>> > telling how large the compressed header block actually is. For
>> > instance, if I chose 100 bytes, I would take any compressed header
>> > block and split it into 100 byte chunks, and then pad the last frame
>> > out to 100 bytes.
>>
>> Almost.  Padding is a sharp tool.
>>
>> An attacker that controls part of the plaintext can still force you to
>> reveal information by counting the chunks.
>>
>> However, here's an example that might* not leak information.  Say you
>> have a secret in a header field.  That secret is fixed size
>> originally, but consequently variably compressed (e.g., Huffman).  You
>> might want to allow for compression of the remaining fields, but then
>> pad to account for the specific effect of compression on that field.
>>
>> * Never take my word for anything in this regard.  And who knows what
>> else you are leaking as a result.  For example, the conditionals you
>> execute in assembling this information result in different computation
>> times, providing an attacker with timing information that might reveal
>> something despite your best effort to avoid the leak.
>>
>>
>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
Received on Monday, 24 February 2014 22:36:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC