On 2014-01-24 09:31, David Deller wrote:
On Jan 23, 2014, at 1:19 PM, Alex Rousskov
<rousskov@xxxxxxxxxxxxxxxxxxxxxxx> 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
