- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 15 Feb 2017 20:33:56 +0000
- To: "Ryan Hamilton" <rch@google.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-Id: <emc155fae7-2801-4e71-846e-5c9e65e6ff1f@bodybag>
Maybe that's where we need to start. In the way that the browser discovers and selects the proxy. DHCP + DNS + WPAD is completely insecure. Let alone not even standardised. Different clients do proxy auto-detect in different ways. Maybe some of these cases should involve different behaviour depedning on how the client selected the proxy. For example in a corporate network, where the proxy is mandated by AD group policy, you could argue that the publis wifi attacker argument doesn't hold water. Adrien ------ Original Message ------ From: "Adrien de Croy" <adrien@qbik.com> To: "Ryan Hamilton" <rch@google.com> Sent: 16/02/2017 9:23:35 AM Subject: Re: The future of forward proxy servers in an http/2 over TLS world > >how did they trust the proxy? > >I'm suggesting trusted proxy, which means the proxy would need to use a >cert trusted by the client. > >I'd go further and say we need to do better than proxy auto-detect as >well - it needs to be secured. > >Adrien > > >------ Original Message ------ >From: "Ryan Hamilton" <rch@google.com> >To: "Adrien de Croy" <adrien@qbik.com> >Sent: 16/02/2017 9:22:06 AM >Subject: Re: The future of forward proxy servers in an http/2 over TLS >world > >>On Wed, Feb 15, 2017 at 12:11 PM, Adrien de Croy <adrien@qbik.com> >>wrote: >>>We already support this with WinGate and I've verified it with Chrome >>>and Firefox. In that case couldn't the client trust an error >>>response body from CONNECT? >> >>We used to do this in Chrome, but removed it because of the potential >>for phishing. Here's just on example >> >>Imagine that at user has their browser configured to do proxy auto >>discovery. They walk into a cafe and join a wireless network which >>sends their traffic to a malicious proxy. The user types >>https://mail.example.com/, and is presented with a CONNECT error page >>whose contents look exactly like the actual mail.example.com login >>page to which they dutifully type their username and password.
Received on Wednesday, 15 February 2017 20:34:33 UTC