- From: Yoav Nir <ynir@checkpoint.com>
- Date: Sun, 10 Jun 2012 10:42:44 +0300
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- CC: "'mcgrew@cisco.com'" <mcgrew@cisco.com>, "'Dan Wing'" <dwing@cisco.com>
- Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A7C056C86@il-ex01.ad.checkpoint.com>
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
Received on Sunday, 10 June 2012 07:43:21 UTC