- From: Roberto Peon <grmocg@gmail.com>
- Date: Wed, 3 Sep 2014 16:33:17 -0700
- To: "K.Morgan@iaea.org" <K.Morgan@iaea.org>
- Cc: Greg Wilkins <gregw@intalio.com>, Brian Smith <brian@briansmith.org>, Jason Greene <jason.greene@redhat.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNdFDCB7727=S_agHSsN4YC0SGyOiWV177sjUivUq=yoQg@mail.gmail.com>
That would require far more surgery that I'd expect to want to see for a reasonable proxy. While it could be done at the TLS (or DTLS) or application layer, that is not the layer with which most proxy writers are familiar. It also means that one would have to re-do padding for any other encryption mechanism/tunnel, which would be problematic sometimes. Padding is still relevant for HTTP (without TLS) if you know you might be traversing the internet via a VPN, for instance.. -=R On Wed, Sep 3, 2014 at 4:16 PM, <K.Morgan@iaea.org> wrote: > 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:33:44 UTC