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