Re: h2 padding

Truthfully, many folks who write applications will not think about this
kind of thing, and providing something which does handle this for them
automatically is likely quite a bit better than nothing.

Sometimes (reverse) proxies are called into the picture to help out with
some of these issues.
In such cases, having a mechanism that allows a proxy to manipulate the
data on the wire (likely with simple settings/rules for that
application/product/endpoint) with a guarantee that it is not affecting an
accidental semantic change is useful.


On Wed, Sep 3, 2014 at 3:22 PM, Greg Wilkins <> wrote:

> On 4 September 2014 05:33, Brian Smith <> wrote:
>> That isn't the issue. The issue is with an implementation, such as a
>> proxy, that does something like "split the padding into its own frame
>> and put the data in another frame," and/or putting those split frames
>> in separate TLS records and/or TCP packets, which is currently allowed
>> (AFAICT) in draft 14.
> Which is precisely why telling the framing layer about security padding is
> a self defeating exercise.   TCP packet boundaries are just one potential
> artefact that an observer can use to guess payload sizes, handling time is
> another and I'm sure somebody could even observe CPU and/or power drain if
> they really wanted to get spooky about it.
> If we want security padding to be truly indistinguishable from real
> payload, then don't tell the framing layer that it is padding.
> Better to have no security than false security.
> --
> Greg Wilkins <>
> HTTP, SPDY, Websocket server and client that
> scales
>  advice and support for jetty and cometd.

Received on Wednesday, 3 September 2014 22:31:23 UTC