Re: h2 padding

  On Wed, Sep 3, 2014 at 4:51 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Sep 3, 2014, at 3:31 PM, Brian Smith wrote:
>> In order for padding to be a useful security feature, it must provide
>> end-to-end protection. That is, when the origin server sends
>> data||padding, that data||padding needs to be preserved and processed
>> as a single unit through all hops (i.e. by any/all proxies). But,
>> draft 14 doesn't say that. Therefore, the assumption that "how that
>> data is arranged in h2 padded form" is under the applications' control
>> is violated with in draft 14.
>
> We are talking about padding added within a secure e2e connection
> (from the PoV of the client -- it might actually be a connection to
> a gateway like Roberto described).  The upper layers (hopefully) have
> no idea where the frames are because they are encapsulated by TLS
> or some other encryption.

The gateway like Roberto described may be a normal HTTPS proxy. For
example, consider a website that is directly exposed to public web
traffic. Then that site that starts getting DoSed, and the website
administrator decides to throw CloudFlare in front of the site. If the
site was using the HTTP/2 padding mechanism to mitigate BREACH, like
the draft 14 suggests, then it would be bad if adding CloudFlare to
the mix resulted in the BREACH mitigation being stripped out. So, it
is useful to specify how a proxy like CloudFlare can preserve the
BREACH mitigation properties of padding.

(Again, it doesn't seem like a good idea to rely on HTTP/2 padding to
mitigate BREACH anyway, because you still have to deal with HTTP/1.1
proxies. But, that is what draft 14 says HTTP/2 padding is for!)

> If we also have secure personal proxies in the mix that are doing
> something weird with the data after decoding the encrypted traffic
> and then reframing it and re-encrypting it to transport as an
> intermediary to some distant user agent and NOT taking care to
> transmit the data in a way that is independent of the raw content
> of that data, then all bets are off.  I have no interest, whatsoever,
> in designing to that scenario.

Proxies that speak HTTP over TLS across the open internet to an origin
service, and then relay they traffic to end users as HTTP over TLS are
becoming increasingly common. That's a major part of CloudFlare's
business, for example. Personal proxies of this form are also common
and probably becoming more so, so I don't think they should be
discounted either.

> We already have a paragraph somewhere that says padding should
> not be removed by an intermediary.  I have no problem with it also
> saying that secure intermediaries shouldn't reveal patterns within
> the content by writing them as distinct units when there is no need
> to do so,

Adding such text is necessary, if the spec is going to continue to
claim that padding is a way to mitigate BREACH. Basically, the spec
should say that intermediaries must not do any splitting of DATA
frames (at the TCP layer, TLS layer, or HTTP layer) as a function of
the data/padding boundary, because such splitting would likely leak
how much padding was used, defeating the purpose of the padding.

Again, this would be more complicated to specify if padding were a
separate frame, e.g. because frames can be reordered and/or have other
frames inserted between them, and you'd have to write additional text
to prohibit such things in the case of a separate padding frame. It
would be a lot of work, that adds real risk, for not much benefit. It
makes more sense to stick with what is already in draft 14, if HTTP/2
is going to have any padding mechanism at all.

Cheers,
Brian

Received on Thursday, 4 September 2014 17:23:41 UTC