Re: h2 padding

Roberto-

Is there any reason a reverse proxy couldn't add padding at the TLS level?

-Keith


On Sep 4, 2014, at 0:35, "grmocg@gmail.com<mailto:grmocg@gmail.com>" <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:

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.

-=R


On Wed, Sep 3, 2014 at 3:22 PM, Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>> wrote:

On 4 September 2014 05:33, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>> 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 <gregw@intalio.com<mailto:gregw@intalio.com>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.


This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Wednesday, 3 September 2014 23:17:24 UTC