RE: Choosing a header compression algorithm

[RUELLAN Herve <[e-mail]>]

Roberto,

Prefix matching can be disabled by using the "delta=false" option.

There are two new strategies for prefix matching. The first one is limiting which shared prefixes are used. The last character of a shared prefix must belong to a predefined set of characters. An example of predefined set of characters is "/?=, " (with a space as the last character). For example, for the following URLs:
http://www.example.com/path/first/myfile
http://www.example.com/path/final/otherfile
With the default strategy for prefix matching, the shared prefix would be:
http://www.example.com/path/fi
With the constraints upon the end of the shared prefix, the shared prefix is:
http://www.example.com/path/
This prevents CRIME-like attacks from guessing a value character by character. Therefore we think that using this new strategy, prefix matching is not vulnerable to CRIME-like attacks. In fact, using this strategy, we are enabling some kind of fine-grained indexing of values, where well defined parts of a value can be referred to.

The second strategy is to limit the number of times a given header value can be used as a reference for prefix matching. This limitation can be very low: limiting this usage as a reference to 2 times is already sufficient to get most of the performances of prefix matching. We think that with this strategy, prefix matching is mostly protected from CRIME-like attack.

The first strategy can be selected using the "delta_type='/?= \coma'" option (possibly changing the prefix ending characters).
The second strategy can be selected using the "delta_type=2" option (or with another value).

I'm planning update the HeaderDiff codec to using the first strategy by default.

Hervé. 

From: Roberto Peon [mailto:[e-mail]] 
Sent: mardi 26 mars 2013 01:23
To: RUELLAN Herve; [e-mail]
Cc: Mark Nottingham; [e-mail] Group
Subject: Re: Choosing a header compression algorithm

Herve--

We need an option which disables prefix matching on the HeaderDiff compressor. The strategies I see in the code still allow many headers to be attacked (if they include commas).
I believe that it is still possible to probe interesting data out of various fields of the URL, for example, or even cookies, assuming they aren't B64 encoded.

-=R

On Mon, Mar 25, 2013 at 11:38 AM, Roberto Peon <[e-mail]> wrote:
There are two obvious strategies here: What we do now, and using what SPDY does today (share connections if the certs match and DNS resolution of the new hostname overlaps with those of the current connection).

-=R

On Mon, Mar 25, 2013 at 10:21 AM, RUELLAN Herve <[e-mail]> wrote:
> -----Original Message-----
> From: Mark Nottingham [mailto:[e-mail]]
> Sent: lundi 25 mars 2013 06:56
> To: RUELLAN Herve
> Cc: Roberto Peon; [e-mail] Group
> Subject: Re: Choosing a header compression algorithm
>
>
> On 23/03/2013, at 5:04 AM, RUELLAN Herve <[e-mail]>
> wrote:
>
> > I think it would be good to move this from the compressors to the
> streamifier. In addition, it would be interesting to look at a more realistic
> streamifier that could for example unshard hosts (expecting that HTTP/2.0
> will remove the sharding currently done by server developers).
>
> Right now, it combines all requests to the same TLD (according to the Public
> Suffix List) into a single "connection." Do you have a suggestion for how to do
> it better?
I think this should provide some "realistic" results as a starting point. Depending on what we want to measure, we may want to refine this a bit.

Hervé.

> I've just pushed a quick and dirty fix to use a new instance of each
> compressor for each connection; the results are pretty even between
> headerdiff and delta2, with a small increase in each:
>
> * TOTAL: 5948 req messages
>                                        size  time | ratio min   max   std
>                         http1     3,460,925  0.18 | 1.00  1.00  1.00  0.00
>   delta2 (max_byte_size=4096)       707,901 11.87 | 0.20  0.03  0.83  0.15
>      headerdiff (buffer=4096)       960,106  1.65 | 0.28  0.01  0.96  0.23
>
> * TOTAL: 5948 res messages
>                                        size  time | ratio min   max   std
>                         http1     2,186,162  0.28 | 1.00  1.00  1.00  0.00
>   delta2 (max_byte_size=4096)       622,837 12.86 | 0.28  0.02  1.22  0.13
>      headerdiff (buffer=4096)       596,290  3.65 | 0.27  0.02  0.92  0.18
>
> Cheers,
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>