Re: Talking HTTPS to proxies

Willy -

I love you idea.  I think all browser vendors should support TLS to the
proxy itself.

We ran into the *exact* cookie redirect problem that you ran into.


On Thu, Apr 14, 2011 at 4:30 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> On Fri, Apr 15, 2011 at 1:17 AM, Adrien de Croy <adrien@qbik.com> wrote:
>
>>
>> William
>>
>> are you sure this isn't just support for SSL tunnelling via the CONNECT
>> method?
>>
>
> Yes, I'm sure. I reviewed most of the code for this feature. It's
> experimental right now.
>
>
>>
>> the Chrome UI (or are you referring to the Chromium open source project)
>> uses Internet Explorer settings for proxy config, which doesn't support
>> making a TLS connection to the proxy.
>>
>
> Correct. We haven't changed the UI to support this. You can configure it
> via command line flag though.
>

As a horrible testing hack, you can also use the proxy PAC file - use "HTTPS
<proxyname>" instead of "PROXY <proxyname>".

Keep in mind the wpad.dat fetching is completely unsecured....  But for
testing this works great.   You can even do SPDY this way (ah, true
motivations are revealed!)

Mike


>
>> WinGate 7 supports TLS proxy connections (and conditional auth methods
>> depending on connection security) if anyone needs to test.
>>
>> Regards
>>
>> Adrien
>>
>>
>>
>> On 15/04/2011 7:37 a.m., William Chan (陈智昌) wrote:
>>
>> FWIW, Google Chrome supports HTTPS proxies (
>> http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/net/proxy/proxy_server.h&l=55
>> ).
>>
>> On Thu, Apr 14, 2011 at 9:04 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>>> Hello,
>>>
>>> I'm regularly encountering what I would call dirty and unreliable
>>> hacks to provide proxy authentication in enterprises. And with the
>>> rise of external proxy services, it's going to get even worse.
>>>
>>> A common issue is that in many enterprises, a password must never pass
>>> in clear text over the network. So byebye Basic Auth. Digest requires
>>> that a database of cleartext passwords exists, which is most commonly
>>> refused too. Some proxies support NTLM auth in MS environments, but it
>>> is not the case for all of them, and some proxies simply cannot access
>>> such a service from where they're placed.
>>>
>>> Due to this, we're commonly seeing cookie-based authentication methods
>>> which rely on redirects and which are not much reliable if we put the
>>> efficiency aside.
>>>
>>> The overall principle is approximately the following (I'm saying approx
>>> because I've seen several variants depending on the will to use popups
>>> or forms, and the trade between security and comfort) :
>>>
>>>  1) the browser tries to access example.com through the proxy
>>>  2) the proxy wants user to authenticate and redirects it to a host under
>>>     the proxy's responsibility over https.
>>>  3) the browser follows the redirect through the proxy and gets either an
>>>     auth form or a 401
>>>  4) the user enters his credentials and validates. The request still
>>> contains
>>>     a query string with all the info about the original URL at
>>> example.com
>>>  5) the proxy accepts them, and issues a redirect to a fake host under
>>>     example.com, with the request still encoded in the query string
>>> along
>>>     with a token. It also emits a cookie for the authentication host.
>>>  6) the browser follows the redirect and requests the fake host over HTTP
>>>  7) the proxy intercepts the request, returns a redirect to the initial
>>> URL
>>>     with a set-cookie header so that as long as the user remains on the
>>> same
>>>     site it will present this cookie.
>>>  8) the browser follows that redirect and finally goes to example.comwith
>>>     the cookie.
>>>  9) when the user goes to another site, steps 1 and 2 apply, the proxy
>>>     sees the cookie that was delivered at previous step 5 and is able to
>>>     directly jump there.
>>>
>>> Overall, those are a lot of redirects, in order to safely authenticate a
>>> user over the network. Due to this, I've seen some setups where the
>>> credentials are assigned to the client's IP only. That way once the user
>>> is
>>> authenticated, everybody can access the proxy under his credentials just
>>> by being relayed by his PC. This is a common trick in big enterprises.
>>> Another workaround consists in authenticating the connection regardless
>>> of any request in it. Some clients can then share the same connection by
>>> inserting a proxy in the middle and all browse over the same connection
>>> (I already encountered this case too).
>>>
>>> And the cherry at the top of the cake is that this doesn't work well.
>>> Some sites make use of flash which does not send the cookies (so the
>>> proxy vendors use other tricks for that), and when the users's cookie
>>> for the authentication host expires, you see lots of funny things. If
>>> it expires when loading an image, you often never get it and don't see
>>> the auth form either. Also, XHR and POSTs don't work well either : POSTs
>>> to a site not covered by the current cookie will have its contents lost,
>>> and both XHR and POSTs will be lost when the auth cookie expires (very
>>> annoying in webmails where you know that all your mail's contents are
>>> lost when you see the popup after clicking "send").
>>>
>>> What I've realized is that all those horrors only exist because browsers
>>> offer no provisions for connecting to proxies over HTTPS instead of HTTP.
>>> It would be amazingly simple. We'd just have to check the box "use HTTPS"
>>> in the browser's config, retrieve the proxy's certificate and everything
>>> could safely be exchanged with the proxy. Even basic auth would be easy
>>> to use and safe. We could also make use of client certificates with this.
>>>
>>> So what I'm wondering now is why we have not seen this yet. Is it because
>>> nobody has brought the issue yet, because the vendors who implement the
>>> horrors I described above are too happy to be ahead of competition when
>>> it comes to deploying safe authentication methods, because there are
>>> major drawbacks in doing this, or because I'm stupid and have never
>>> found how to enable this ?
>>>
>>> I'm sure that some proxies do probably already support it as a side
>>> effect
>>> of being used as SSL reverse-proxies. We only need browsers to add the
>>> checkbox in their proxy config to enable this. I have heard about some
>>> sites where an stunnel-like component is installed on the user's PC
>>> (either
>>> as a java applet or as a real daemon) and simply transforms the cleartext
>>> HTTP traffic into HTTPS to connect to the proxy. (I did not see those
>>> myself,
>>> I only saw applets to use stronger crypto than what the browser offers,
>>> but
>>> they were not deployed as explicit proxies).
>>>
>>> Shouldn't we try to encourage both browser vendors and proxy vendors to
>>> enable
>>> HTTPS ?
>>>
>>> Thanks for any insight,
>>> Willy
>>>
>>>
>>>
>>
>> --
>> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
>>
>>
>