- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Wed, 18 Jul 2012 23:49:50 +0200
- To: "Roberto Peon" <grmocg@gmail.com>
- Cc: paul.hoffman@gmail.com, "Phillip Hallam-Baker" <hallam@gmail.com>, grahame@healthintersections.com.au, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Mike Belshe" <mike@belshe.com>, "Patrick McManus" <pmcmanus@mozilla.com>
Roberto Peon <grmocg@...> writes: > As a reminder, I submitted an ID w.r.t. TLS proxies and MITM. > The key idea in it, ignoring the technical stuff, is that either party (client, server) has or should have some decisions to make about what the proxies are allowed to do, and thus their own behavior when dealing with them. > > The proxy always had the power to restrict and control things which flow through it. Always will. Thank you for this document. I freely admit I probably need to read it again a few times, but it's a good first step. Some remarks: A. the parts where you wish content would not be accepted if modified and would not be modified will be optimized away by implementers. Either the user-agent cares about modifications (and it will ask a manifest of those elements signed by a key it already trusts, and it will check this manifest) or it doesn't and no amount of spec will change that B. If the user agent has no means of verifying the data is unmodified… → being anal there only wastes network resources, adds latency and annoys the user on a non-roaming connexion. If external access is closed it's closed an no amount of continuous user agent hammering is going to change that C. I don't think URI syntax of html syntax changes is reasonable to expect. If you want the content-provider to hint something should only be fetched in archi-secure mode you need to place the hint in the transport layer (like hsts today) D. therefore, the way to go is transport-level signed manifests (or manifests of signatures). This is actually useful even without intermediaries – that permits mirroring of elements signed by someone else (the content provider with which you've established a tls tunnel is not necessarily the entity you trust to sign the content) E. I think you started from separate caching and trusted proxies and realised mid-document they were just complementary modes Indeed a real-life scenario would look more like this: * user-agent is configured with a list of explicit proxies * the first time it needs to retrieve or post something, or on network changes it checks if they are available, and establishes a secure connection with them (checking not just some proxy exists at some ip, bu that it has a trusted cert) * if no previous connexion history with this proxy is cached, the user agent asks what is the proxy operator policy (stupid to try blindly lots-of-operations without knowing beforehand how they are likely to be treated, especially if several known proxies are available) 'what can I get for *' → answer: trusted mode only, caching mode only, caching and trusted, forbidden, restricted (need to provide auth to the proxy to get access), direct (should try accessing the target directly), otherproxy (can not handle this request, ask someone else) mixed (request too broad, different rules apply to urls that match this filter) + expiration time (when the policy is likely to change next for this request) * if necessary (the typical answer for * will be mixed) it repeats with more specific request (specific domain, url set, etc). * like with hsts it caches the answers so it does not need to query policy all the time (did you say out-of-band pac-file? die die die) * once the user agent knows how a particular request can proceed on the available proxies, it provides an auth token over the secure channel (if needed), a key (if something is only available in trusted mode, and the user is ok to use trusted mode for this resource), and proceeds * even if an url is available in trusted mode the client should not switch systematically away from caching mode unless necessary (content provider hint, user preference) doing away with caching and malware scanning has its own problems * at any point the proxy can reply to a specific operation with a mode change request (that the browser can accept or not), due to unscheduled policy changes, or just policy rules that apply to specific url patterns or mime types F. user agent needs to accept proxy messages such as 'not found', 'auth renewal needed' G. protocol needs to enable the user agent to request signature manifest or manifest of signatures of some objects (even without any intermediary) H '[we] must worry about endpoint per-connection stream limits' indeed. A big proxy setup will max out typical stream limits I Good users agents should remember user wishes and in particular what they absolutely do not want to go through trusted mode And that's all for today Best regards, -- Nicolas Mailhot
Received on Wednesday, 18 July 2012 21:50:32 UTC