Monday, September 25, 2006

Securing client connections to Squid

One of the problems with proxy servers is that requests from a web browser to the proxy server are sent in the clear. This is particularly a problem for those proxy servers that make use HTTP basic authentication — username and password tuples are sent unencrypted over the wire. On a fully switched network this might be an "acceptable" risk, but it's still not a fantastic idea.

In order to support acceleration and true SSL proxying, most proxy server software has supported SSL/TLS client connections for some time. This is certainly true of Squid, which is what I use. Squid has had an https_port directive since 2.5-STABLE1 to support SSL acceleration. In reality it's just a normal client port that happens to do SSL/TLS.

The logical next step seemed to be for web browsers to support the use of HTTPS as a protocol for connecting to proxy servers. I've been waiting for this to happen for a while and, to date, it doesn't seem to be. Being a firm believer of Larry Wall's "There's more than one way to do it" mantra, I decided to find a way to solve this problem that didn't rely on browser vendors doing my bidding.

Enter Stunnel, the universal SSL wrapper. Stunnel has the ability to act as an SSL broker, with unencrypted connections on one side and encrypted ones on the other. In retrospect, it was the obvious solution :-). Best of all, it comes with both *nix and Windows ports, making this a very portable solution. I've got it working with Firefox on Windows XP.

The trick is to run Stunnel on the same machine as your web browser. You can then configure it to accept unencrypted connections from your local machine, and forward them as encrypted connections to your proxy server. This doesn't quite give you end-to-end encryption, but provided that you trust your local machine it is pretty good. It certainly eliminates a lot of the normal network sniffing risks, which in turn is good for securing HTTP basic passwords.

A minimalist Stunnel config to do this is as follows:

[proxy]
accept = localhost:3128
connect = proxy.example.com:3129
client = yes

Which requires a corresponding line in the squid.conf on proxy.example.com to accept SSL connections on port 3129:

https_port 3129 cert=/usr/local/etc/squid/proxyserver.pem

With this set up and working, change your web browser's proxy settings to point at localhost port 3128 (or whatever).

UPDATE 2006/09/25:
If you're a Rhodes person, don't expect this to work on the University's proxy servers just yet. The Squid side needs more testing; watch this space.

posted by guy at: 15:48 SAST | path: /systems | permanent link