Re: Explicit Proxy (draft-rpeon-httpbis-exproxy)

A caching proxy won't be able to inspect any traffic going through the TLS
tunnel because the client doesn't provide the decryption key material for
it.
The only requests the caching proxy can inspect are those which the client
chooses to do outside the TLS tunnel, and, at least in the proposal, the
client should only do such if it has a cryptographic hash of the content
from a trusted source so that it can verify integrity.

In all cases, in the draft I just submitted makes a tunnel to the eventual
endpoint so it does always get the certs and can verify that the proxy
isn't mistaken about whom to connect to...

On distinguishing between 'trusted' and caching proxies.
The client doesn't always control the network over which it must make a
connection. Perhaps the client is forced to use a trusted proxy (e.g.
within a school). In such cases, the content-provider should be notified so
that they can vary the content it provides (as in your example). If you
can't trust the client you have no trust chain to the user anyway... (they
could lie about anything in that case)

Despite the name 'trusted', it isn't true that both parties will believe
that the proxy should be trusted, and in all cases, integrity of all
resources is verified. The 'trust' part in the proposal is that they get to
inspect the traffic and advise either side to drop specific requests.
This will help to keep the incentive for trusted proxy owners in-line with
those of the client and content-providers, at least hopefully.

I'll definitely have to read your draft :)


-=R

On Sun, Jun 10, 2012 at 12:42 AM, Yoav Nir <ynir@checkpoint.com> wrote:

> **
>
> Hi
>
> I've read the draft.  I don't really understand how the caching proxy is
> prevented from inspecting non-cached data. If it's only trusted to do so,
> then OK, but both the "Bob" connection and the "Don" connection are
> point-to-point, so "Chris" always gets to see the clear traffic.
>
> One building block to consider is the now expired draft for TLS proxies:
> http://tools.ietf.org/id/draft-mcgrew-tls-proxy-server-00.html
>
> The not-yet-published newer version of this draft will have all of the
> following:
>
>    - The proxy authenticates to the client (so proxies can be explicitly
>    configured)
>    - The proxy uses a TLS extension to show the cilent the real
>    certificate chain presented by the server (so trust and EV status can be
>    determined, and the client can check revocation on its own)
>    - The proxy can send an indication to the server that it is on-path
>    (not in the -00 draft and needed for client authentication)
>
> I think it's better to indicate the presence of a proxy in the TLS layer
> then as part of the application (last paragraph in section 6). I also don't
> see value (for the server) in distinguishing between caching and trusted
> proxy, since the client has no control over the behavior of the proxy. IOW
> if I were writing a web application for an health service provider, and the
> new version of HIPAA prohibits showing test results with a MitM present, it
> would not be prudent to allow them with any proxy present. Even if the
> client swears it's only a caching proxy.
>
> Yoav
>
>