W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Trusting proxies (was Re: I revised the pro/contra document)

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 25 Nov 2013 22:33:12 -0800
Message-ID: <CAP+FsNev1BdC7CrALXr-Ec1AF_UNuh5LSz6inZUS3RVk2tDYDA@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Nov 25, 2013 at 10:05 PM, Amos Jeffries <squid3@treenet.co.nz>wrote:

> On 26/11/2013 1:55 p.m., Roberto Peon wrote:
> > Here is the GOALS section from:
> > http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00.
> > I do think breaking down the conversation in this way is interesting.
> >
> > 6.2 <
> http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00#section-6.2
> >.
> >  Goals
> >
> >    These are the goals of a solution aimed at making proxying explicit
> >    in HTTP.
> >
> >    o  In the presence of a proxy, users' communications SHOULD at least
> >       use a channel that is point-to-point encrypted.
> >
> >    o  Users MUST be able to opt-out of communicating sensitive
> >       information over a channel which is not end-to-end private.
> >

> I think this is partially wrong.
> It would be far better to give the client some guarantee of end-to-end
> confidentiality and/or non-transformation before it opts-in to sending
> private details.

That is the basic mechanism, so yea.

> Signing or encrypting the particular details using a shared secret
> arranged via mandatory out-of-band means with the origin server would be
> acceptible.

The client always decides what to send, and should always know if there is
an intermediary, assuming proxy use is explicit.
Mandatory out-of-band isn't necessary for this, in any case.

> >    o  Content-providers MAY serve certain content only in an end-to-end
> >       confidential fashion.
> This seems to be a waste of words in the spec. Content providers will
> make up their own decision about this. No need to use MAY, or even to
> state that IMHO.
>  Better to focus on the mechanisms provided by this spec for them to
> make that decision with.

Given that it is goals statement... it makes sense. I do prefer mechanism,
however, and that was my previous spec...
The base idea is that a content provider should have the ability to change
what it sends based on what is/isn't intercepting what.

> >
> >    o  Interception proxies MUST be precluded from intercepting secure
> >       communications between the user and the content-provider.
> This is a straw-man clause. Interception proxies will do what they want.
> The only way to avoid that is to provide better features through use of
> HTTP without interception.

I interpret this goal as: if you want it confidential, encrypt it and don't
provide the key to any intermediary.


> >
> >    o  User-agents and servers MUST know when a transforming proxy is
> >       interposed in the communications channel.
> >
> Via header is already mandatory. This has not gone down to well so far.
> Any similar replacement must jump the same hurdles which killed Via as a
> useful extension point for this ability.

MUST for non-required features are at best guidance, as was the case for
To make this goal a reality, you need a mechanism that requires it to be so.

> It reveals details of the path an protocol compatibility in both
> directions.
> The alternative is the Forwarded-For header. Which sadly is specified as
> a one-way Request header with a MUST NOT clause on use in responses.
> With stated grounds that it reveals details of the providers network
> which must be kept secret.
> ** Completely ignoring the privileged details revealed about the clients
> ISP being published to the origin. **
> Eliminating the client or their ISP from access to path/chain details
> necessary to form trust decisions about the origin is a terribly bad way
> to go about engendering a trust relationship.
> >    o  User-agents MUST be able to detect when content requested with an
> >       https scheme has been modified by any intermediate entity.
> >
> I don't see any reason to flag up https:// about this. For even a modest
> amount of security the requirement also goes for http:// and other
> schemes as well.

This is mentioned as a contrast to what happens when someone installs a
root cert onto your machine as a means to do proxying.

> >    o  Entities other than the server or user-agent SHOULD still be able
> >       to provide caching services.
> >
> >    o  User agents MUST be able to verify that the content is in fact
> >       served by the content provider.
> This is a vague cluause whih is either a straw-man or invalid depending
> on how you look at it.
> Firstly, does HTTP actually make that guarantee anywhere today? I dont
> think even HTTPS does that.
HTTPS does guarantee this today (up to the amount of trust we place in the
authentication trust chain) with TLS' integrity safeguards, though it is
channel-based, and not object-based.

> Secondly, what use is knowing the content is served by the content
> provider when it is not necessarily the content requested?
>  - the purpose of transforming proxies is to *generate* new or updated
> content based on the content providers content. Think ESI protocol or
> FTP->HTTP gateways.
> Thirdly, it directly violates the SHOULD on caching goal above. Content
> served out of a cache is by definition *not* served by the content
> provider.

Knowing about the transformation doesn't always imply rejection.
Some content transformations are understandable/can be verified, e.g.
truncation of a progressive jpg.

> >
> >    o  A set of signaling semantics should exist which allows the
> >       content-provider and the user to have the appropriate level of
> >       security or privacy signaled per resource.
> >
> See above comments about Via and Forwarded-For.

The signaling mechanism described a long time ago involves an end-to-end
channel over which the client signals to the server that it is connected to
an intermediary.

Received on Tuesday, 26 November 2013 06:33:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC