Re: The future of forward proxy servers in an http/2 over TLS world

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