- From: Albert Lunde <atlunde@panix.com>
- Date: Tue, 03 Dec 2013 19:18:15 -0600
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 12/3/2013 6:22 PM, William Chan (ιζΊζ) wrote: > OK, it sounds like people are retreating back from the > autoconfiguration+interstitial part of an explicit proxy > proposal...except maybe Nicholas? I'd love to hear more thoughts on > autoconfiguration+interstitial. It sounds like the prevailing sentiment > is it's unacceptable from a security UX perspective. [...] > And now there are the UAs, of which browsers are the most prominent. For > tools like curl, I don't think they'd have a problem with "trusted" > proxies, since the user presumably knows what he's doing? Maybe? For > browsers though, I expect there will be some hesitance to sacrifice e2e > security guarantees. Pat already mentioned this earlier about his > dislike of proxy termination of https:// requests. My teammates have > similarly voiced concerns here. Would we be willing to move forward with > explicit HTTPS proxies (UA<=>proxy TLS connection) without any "trusted" > modes? Or is that a key part of the proposals? It seems like a HTTP client's local configuration of what proxies it trusts (or distrusts) is going to be a distinct problem from the wire protocol being talked to the proxy, and may be specific to the type of client or how it is being used. What's a reasonable configuration format for a browser client may not make sense for an RSS aggregation, or a web service client, or wget. A mobile client that defines "Locations" might want to associate local proxy trust policies with those locations. But there still might be security risks with policy spoofing. For example, my Android phone can recognize "Locations" based on WiFi network names. It might conclude I was at the office because of the existence of a network named "Northwestern" without looking at the details. A Microsoft domain environment might want to seed trust preferences with Group Policy. Having some kind of expectation of what a configuration might involve could be helpful. A list of recognized proxies with associated actions (trust/distrust), and a default action, seems like the simplest case. Saying, "I'll trust proxies with certificates signed by a list of CAs" "reduces" it to the certificate trust problem, which is nearly where we stated, though trusting proxies signed by a short list of CAs might be more manageable. I can't think of a way to introduce new trusted proxies that can't be subverted, say, by a person wanting to get to a suspect web site. -- Albert Lunde albert-lunde@northwestern.edu atlunde@panix.com (address for personal mail)
Received on Wednesday, 4 December 2013 01:18:38 UTC