Re: HTTP/2 and HTTPS BICYCLE attack

I wouldn't prepare for the apocalypse over this.  It reveals the
length of fields that are unknown in the presence of known or
predictable information.  It doesn't actually reveal the bytes, just
the length.  Then they are left with the actually hard problem of
extracting the actual value of the characters.

Note that HTTP/2 isn't strictly better than HTTP/1.x when it comes to
lengths.  The point this work is that there is a predictable component
and a non-predictable one.  HTTP/2 only makes it a little harder to
predict the predictable part.  Huffman coding might throw in some
noise, as might header compression, but I don't think that would be a
significant barrier to a serious attacker (such as a researcher
looking for more funding).

If this had come with actual password recovery, I'd be impressed, but
we've known for a long time that TLS doesn't protect lengths. TLS 1.3
will let you try to protect lengths, but it's hard enough to do that
we will likely give the same advice there: if you have a secret, then
make it long, make every bit hard to guess, and make it the same
length as all the other things like it.

On 7 January 2016 at 21:03, Smith, Kevin, (R&D) Vodafone Group
<Kevin.Smith@vodafone.com> wrote:
> Hi all,
>
> Just seen the 'HTTPS BICYCLE attack' study [1], which claims that 'the redundancy of the plaintext HTTP headers included in each and
> every request can be exploited in order to reveal the length of particular components (such as passwords) of particular requests'
>
> Although I've not seen any further analysis to verify the study, would it be correct to think that HTTP/2's support of sending only header deltas would mitigate such an attack?
>
> Many thanks,
> Kevin
>
> [1] https://guidovranken.files.wordpress.com/2015/12/https-bicycle-attack.pdf
>
>
>
>

Received on Thursday, 7 January 2016 11:34:30 UTC