Saturday, September 30, 2006

Looking for a FreeBSD VSP

I'm looking for a new home for this site and a few other things (like my e-mail). Somewhere that doesn't belong to my employer, and that isn't on exorbitantly expensive South African bandwidth. Ideally what I'm looking for is a virtual machine at a commercial VSP hosting company. I can't really justify having a whole machine to myself and the VSP idea represents a pretty good compromise.

The complication arises when I start being fussy. I like FreeBSD, and I want my virtual machine to run FreeBSD. I know this is easily possible because I've been running FreeBSD under VMWare for some time. Unfortunately there seems a distinct lack of commercial VSP providers who're willing to enter this market. Those that I've found have very specific limitations — for instance, they'll only run a FreeBSD 4-based system.

What I want is reasonably affordable (USD20-30 pm, assuming a stable exchange rate) hosting that lets me use FreeBSD 6.x, install my own MTA, Apache, DNS, etc and run the machine myself. I'm not looking for lots of bandwidth (I currently use < 2GB pm), huge amounts of disk space, or fantastically fast machines. I just want something that works™.

If anyone has any bright ideas, please let me know :-)

posted by guy at: 16:37 SAST | path: /general | permanent link

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

Friday, September 22, 2006

Getting Real Names into RT3

We've been using Best Practical's RT3 to do request tracking for many years. Recently it's been bugging me that RT3 uses usernames rather than people's real names when displaying tickets. Today I decided to fix that.

RT3 is entirely Mason based, so fixing the way it display things involved hacking Mason templates. I'd never done this before, so I was a little nervous. I needn't have been, it's really straight forward.

The result is a patch. The patch is fairly straightforward and applies to an installed RT 3.4.5. The only catch is that Mason caches things, so you have to delete the cache to see the changes.

Now I see "Guy Antony Halse" as the owner of a ticket rather than "mapu025". Since I don't know everyone's username this makes my life a lot easier. Where the RealName field is different from the Name field, both are displayed. YMMV and all that.

posted by guy at: 22:20 SAST | path: /systems | permanent link