Re: [squid-users] HTTPS forward proxy?

On 2014-01-24 09:31, David Deller wrote:
> On Jan 23, 2014, at 1:19 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>
>> On 2014-01-22 11:44, David Deller wrote:
>>>>> Here's another request, this time with HTTPS:
>>>>> $ curl --proxy https://my-proxy-server.example:3129 \
>>>>> --proxy-anyauth --proxy-user redacted:redacted -w '\n' \
>>>>> http://urlecho.appspot.com/echo?body=OK
>>>>> curl: (56) Recv failure: Connection reset by peer
>>>>> Nothing in `access.log` after this one, but in `cache.log`:
>>>>> 2014/01/20 20:46:15| clientNegotiateSSL: Error negotiating SSL
>>>>> connection on FD 10: error:1407609C:SSL
>>>>> routines:SSL23_GET_CLIENT_HELLO:http request (1/-1)
>>>>
>>>> See the serverfault response. curl is connecting to the proxy using
>>>> plain-text instead of SSL.
>>
>> Official curl does not support SSL connections to HTTP proxies.
>> Factory
>> has an experimental curl patch adding such support, including client
>> SSL
>> certificate authentication IIRC. If all you need is a single
>> SSL-to-proxy client, that will work for you (please contact me off
>> list
>> if interested). If you need SSL-to-proxy support in popular browsers
>> and
>> other clients, a single patched curl will not help, of course.
>
> Thanks for confirming this for me. I was only using curl in this case
> to troubleshoot my Squid server and see if I had configured it
> correctly. Now I at least know not to waste more time on it :)
>
> What I really need is a Ruby HTTP library that can connect to Squid
> using SSL. Ruby can use libcurl (via ‘curb’), but I don’t think I can
> deploy a patched version of curl to my web host. I have tried several
> libraries and none of them so far have worked with my Squid server on
> its https_port.
>
> Well, let me back up a little. If there was another way to
> authenticate securely to Squid, that would also be acceptable. As I
> mentioned before, I don’t think I’m comfortable with Digest (certainly
> not Basic). The only other options I see are NTLM and Negotiate, which
> both seem to be Microsoft-specific. Am I missing anything there?

Those are the ones currently supported by Squid.

Negotiate is only sort-of MS specific. It is usually a MS wrapper
protocol around the Kerberos scheme. This is currently the most secure
of auth schemes supported explicitly by Squid.

NTLM is second best. NTLMv2 has most of the same high-security
properties as Kerberos (slightly less algorithms though) but is much
more MS-specific and violates HTTP protocol in nasty ways that block
usage over the Internet / WAN.

Digest is next best. The MD5 step is simply to one-way hash a short
lived nonce, the password itself is never sent and the system can be
configured to rotate nonces fast enough that replay attacks are very
difficult (but not impossible).

Basic auth is ironically both the worst and the best of all of them. It
is just a scheme for sending two credential tokens to the service.
Historically is has been used to send user:password details and that is
terribly bad. However, provided you can configure both the sender and
receiver to agree on algorithms out-of-band (the HTTP scheme provides no
way to do so) you can send any type of secured one-use token in the
"password" field. You just need the client to be able to generate them
and a Squid Basic auth helper to verify and accept/reject. Properly done
this can be far more secure than even Negotiate.

>
>>> I did notice this and wondered if it might be a problem with curl
>>> itself. So I also tried similar tests with Google Chrome and a Ruby
>>> HTTP library called excon, both of which specifically mention support
>>> of HTTPS proxies. I also tried a few other HTTP libraries that have
>>> HTTP proxy support but don’t specifically mention HTTPS. Since I saw
>>> the same failing result with all of them, I went back to trying to
>>> troubleshoot Squid as the likely source of the problem.
>>
>> In many cases, "HTTPS proxy support" simply means tunneling SSL
>> connections through HTTP proxies by sending HTTP CONNECT requests to
>> those HTTP proxies first. That is not SSL-to-proxy mode that you are
>> looking for.
>
> Very enlightening; that hadn’t occurred to me.
>
> Here are the docs about Chrome’s ‘secure web proxy’ support:
> http://www.chromium.org/developers/design-documents/secure-web-proxy
>
> That page specifically mentions Squid’s https_port, suggesting it
> should work with this Chrome feature, although from the phrasing of it
> (‘appears to’), the person who wrote that may not have actually tested
> it to find out.

We have had some responses about success with Chrome here on the list
years back. No mention recently. And Chrome is very much out there alone
in the browser market on this now.

>
> Indeed, I tried replicating the same set of tests that I did with
> curl, with Google Chrome, and had the same unsuccessful results.

Note that the UI is not mentioned in that page. Only the PAC and command
line options support this type of connection AFAIK.

Amos
Received on Thu Jan 23 2014 - 21:20:43 MST