Re: Comments on Explicit/Trusted Proxy

["Adrien W. de Croy" <[e-mail]>]

proxies need to be able to modify the bytes or at least inject messages 
back to the client.

e.g.

* request denied by policy (e.g. you can't POST to that site due to DLP 
rules)
* serving from cache
* ad stripping
* malware blocking
* etc etc etc

let alone stripping hop-by-hop headers etc

So I don't think anyone will bother with a scheme that doesn't allow for 
that.  If the only option of the intermediary is to delay or drop the 
connection, the client is going to be in the dark as to why.  Already 
the user experience in this area is poor.

As for intercepting proxies.  Whilst I agree they are a PITN, they are 
strongly favoured by customers for several obvious reasons.

Until we can get a wide-spread mechanism deployed to securely FORCE 
clients to use a proxy, we're going to see interception.

As for MITM.  Whilst we continue to think of it as an attack, we will 
continue to see resistance.  It's clear some people see it only 
negatively, where others see this as an opportunity to improve things 
compared to current MITMs.

Personally I would rather know what is going on, than be in the dark and 
be forced to swallow whatever I receive simply because I was forced (by 
company policy) to install a root cert for the spoofed certs.  Sites 
using EV certs will show me what is going on if I know a site uses EV 
certs, since the EV breaks on spoofed certs.  Or I need to check the 
cert path on any site to see if I can find the forced cert at the root.  
But that's me, not everyday punters.

As for the server trusting the proxy.  Why is that any different to the 
server trusting the client.  Use a client cert.  Can always fall back to 
a tunnel if the server indicates it needs a client cert.  Currently 
there's no way around this issue in today's MITM systems except for 
installing the client cert on the proxy.

Adrien


------ Original Message ------
From: "Roberto Peon" <[e-mail]>
To: "Peter Lepeska" <[e-mail]>
Cc: "HTTP Working Group" <[e-mail]>
Sent: 3/05/2013 12:13:21 p.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>responses inline.
>
>
>On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <[e-mail]> 
>wrote:
>>Some comments on Roberto's doc:
>>
>>In the case where the user-agent has been configured with Chris as a 
>>trusted-proxy, either Anne's connect-stream MUST use either a null- 
>>cipher, or Anne MUST provide the decryption key material to Chris 
>>immediately after tunnel establishment, and before any data traverses 
>>the tunnel.
>>
>>This seems like a showstopper to me. Even if we can get past the 
>>problems associated with a trusted proxy in general, I can't see 
>>getting acceptance of any approach that involves sending a session key 
>>from one machine to another. But why not just use two full SSL 
>>sessions like the typical MITM proxy 
>>(http://crypto.stanford.edu/ssl-mitm/or http://mitmproxy.org/) 
>>approach? But instead of forging certificates like they do, just give 
>>the trusted proxy its own certificate and then display both the 
>>trusted proxy certificate and the content server certificate in the 
>>browser when the user wants info about the two point-to-point SSL 
>>sessions.
>>
>
>Using two connections may require two separate connections at the 
>eventual endpoint, and it contributes to bufferbloat.
>Also, the proxy may wish to influence the private channel (e.g. don't 
>talk to site X). With connection sharing, this is difficult/impossible 
>otherwise (that other connection may not only go to example.com).
>
>>"For the purpose of this document, it is assumed that the user locates
>>a piece of paper upon a wall and reads it, typing these proxy settings 
>>into a configuration field for their user-agent. This is obviously not 
>>the only possible configuration mechanism, but it may, sadly, be the 
>>most secure. It is assumed that alternate distribution techniques may 
>>be discussed.
>>"
>>
>>While explicit proxy configuration may be the most secure, it is very 
>>difficult to manage for mobile devices especially, as others have 
>>mentioned on this list. Transparent interception is the more widely 
>>adopted approach -- not because of security but because of stability 
>>and manageability.
>>
>
>There is no secure automatic proxy configuration unless a completely 
>separate trust chain is somehow created and is reliable (or at least 
>moreso than what we have with TLS today).
>Transparent proxying causes problems in upgrading the protocol as 
>nobody knows where the problem lies. If this wasn't such a painful 
>point, we'd have been using SPDY over port 80...
>I'm fundamentally opposed to transparent proxying because it makes 
>protocol evolution next to impossible when you can't figure out who is 
>messing up...
>
>
>>What about "transparent" proxies that advertise themselves? Is it 
>>possible to use NPN 
>>(https://technotes.googlecode.com/git/nextprotoneg.html) to advertise 
>>the presence of an intercepting proxy for 443 traffic? Then the user 
>>can be notified that a proxy wants to be trusted for X reasons and the 
>>user would then make the opt in or opt out decision. Then, similar to 
>>SPDY, the presence of the trusted proxy in the end-to-end path could 
>>be signaled to the end user via icons in the browser.
>
>
>
>>
>>MITM is used today with no user knowledge. At least in this approach, 
>>a user has the ability to opt in or out and to also be aware of the 
>>presence of the intermediate proxy.
>
>That is the idea.
>Additionally, and this is important, the server gets to decide if the 
>MITM is acceptable, and, in the proposed scheme the MITM doesn't get to 
>modify bytes. It merely gets to advise the recipient of how to deal 
>with them, delay them, or disconnect.
>
>-=R
>
>
>On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <[e-mail]> 
>wrote:
>>Some comments on Roberto's doc:
>>
>>In the case where the user-agent has been configured with Chris as a 
>>trusted-proxy, either Anne's connect-stream MUST use either a null- 
>>cipher, or Anne MUST provide the decryption key material to Chris 
>>immediately after tunnel establishment, and before any data traverses 
>>the tunnel.
>>
>>This seems like a showstopper to me. Even if we can get past the 
>>problems associated with a trusted proxy in general, I can't see 
>>getting acceptance of any approach that involves sending a session key 
>>from one machine to another. But why not just use two full SSL 
>>sessions like the typical MITM proxy 
>>(http://crypto.stanford.edu/ssl-mitm/ or http://mitmproxy.org) 
>>approach? But instead of forging certificates like they do, just give 
>>the trusted proxy its own certificate and then display both the 
>>trusted proxy certificate and the content server certificate in the 
>>browser when the user wants info about the two point-to-point SSL 
>>sessions.
>>
>>"For the purpose of this document, it is assumed that the user locates
>>a piece of paper upon a wall and reads it, typing these proxy settings 
>>into a configuration field for their user-agent. This is obviously not 
>>the only possible configuration mechanism, but it may, sadly, be the 
>>most secure. It is assumed that alternate distribution techniques may 
>>be discussed.
>>"
>>
>>While explicit proxy configuration may be the most secure, it is very 
>>difficult to manage for mobile devices especially, as others have 
>>mentioned on this list. Transparent interception is the more widely 
>>adopted approach -- not because of security but because of stability 
>>and manageability.
>>
>>What about "transparent" proxies that advertise themselves? Is it 
>>possible to use NPN 
>>(https://technotes.googlecode.com/git/nextprotoneg.html) to advertise 
>>the presence of an intercepting proxy for 443 traffic? Then the user 
>>can be notified that a proxy wants to be trusted for X reasons and the 
>>user would then make the opt in or opt out decision. Then, similar to 
>>SPDY, the presence of the trusted proxy in the end-to-end path could 
>>be signaled to the end user via icons in the browser.
>>
>>MITM is used today with no user knowledge. At least in this approach, 
>>a user has the ability to opt in or out and to also be aware of the 
>>presence of the intermediate proxy.
>>
>>Thoughts?
>>
>>Peter
>>
>>
>>On Apr 24, 2013, at 12:49 PM, William Chan (陈智昌) 
>><[e-mail]> wrote:
>>
>>>Yep, but no, it hasn't gone anywhere.
>>>
>>>
>>>On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska <[e-mail]> 
>>>wrote:
>>>>Hi William,
>>>>
>>>>Is this draft by Roberto Peon the one you were referring to?
>>>>
>>>>http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00
>>>>
>>>>Has this gone anywhere?
>>>>
>>>>I'm looking to design and build a "trusted proxy" that aligns with 
>>>>the browser development roadmap/vision in order to provide web 
>>>>acceleration functionality and so would like to get involved in this 
>>>>process if still active.
>>>>
>>>>Thanks,
>>>>
>>>>Peter
>>>>
>>>>
>>>>On Mon, Apr 30, 2012 at 5:57 PM, William Chan (陈智昌) 
>>>><[e-mail]> wrote:
>>>>>On the contrary, I think it's great to have multiple proposals. If 
>>>>>you have your own vision for how this should work, please send it 
>>>>>out! :) My statement was simply an FYI, not a "back off, we've got 
>>>>>this!"
>>>>>
>>>>>On Mon, Apr 30, 2012 at 2:45 PM, Peter Lepeska 
>>>>><[e-mail]> wrote:
>>>>>>Perfect then I'll sit tight.
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Peter
>>>>>>
>>>>>>
>>>>>>On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌) 
>>>>>><[e-mail]> wrote:
>>>>>>>FYI, we (google spdy team) have been discussing a "trusted proxy" 
>>>>>>>internally and I think Roberto's got a draft in the works.
>>>>>>>
>>>>>>>
>>>>>>>On Mon, Apr 30, 2012 at 2:22 PM, Peter Lepeska 
>>>>>>><[e-mail]> wrote:
>>>>>>>>Hi Mark,
>>>>>>>>
>>>>>>>>Earlier this group discussed the idea of a "trusted proxy". Does 
>>>>>>>>that fall under the HTTP/2.0 category?
>>>>>>>>
>>>>>>>>I may have some cycles for this.
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>
>>>>>>>>Peter
>>>>>>>>
>>>>>>>>
>>>>>>>>On Fri, Apr 27, 2012 at 1:28 AM, Mark Nottingham <[e-mail]> 
>>>>>>>>wrote:
>>>>>>>>>Just a reminder that we're still accepting proposals for:
>>>>>>>>>
>>>>>>>>>1. HTTP/2.0
>>>>>>>>>2. New HTTP authentication schemes
>>>>>>>>>
>>>>>>>>>As per our charter 
>>>>>>>>><http://datatracker.ietf.org/wg/httpbis/charter/>.
>>>>>>>>>
>>>>>>>>>So far, we've received the following proposals applicable to 
>>>>>>>>>HTTP/2.0:
>>>>>>>>>  
>>>>>>>>><http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>
>>>>>>>>>
>>>>>>>>>But none yet for authentication schemes:
>>>>>>>>>  
>>>>>>>>><http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals>
>>>>>>>>>
>>>>>>>>>As communicated in Paris, the deadline for proposals is 15 
>>>>>>>>>June, 2012. It's fine if your proposal isn't complete, but we 
>>>>>>>>>do need to have a  good sense of it by then, for discussion.
>>>>>>>>>
>>>>>>>>>Regards,
>>>>>>>>>
>>>>>>>>>--
>>>>>>>>>Mark Nottingham   http://www.mnot.net/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>