Hinky’s Proxy Obsession

I haven’t had a lot to say the past month because I’ve been a very busy boy.  As they say, I have a lot on my plate.

Unfortunately it is a plate full of shit.  A variety of turds, but all shit nonetheless.

One of those turds is an evaluation of a “Secure Web Gateway” (SWG) from a manufacturer who will remain nameless.

One of the functions of this SWG is Data Loss Prevention (DLP).  This box wants to know everything about anything that’s coming and going through the corporate firewall.  Web pages, email, ftp sessions, you name it.

It accomplishes this by being very snoopy, to the point of sniffing SSL traffic as it passes in and out of the box.

And you thought SSL was secure, didn’t you?

Not when it goes through an Evil Proxy!

Especially not a proxy that spins faux SSL certificates on the fly, which is exactly what this thing does.

Nothing is safe.  Credit cards numbers?  BAH!  It eats them for breakfast.  Those torrid emails you send to your significant other from your Yahoo account?  BLAM!  Laid bare for all to see.  Nothing evades its steely, unimpassioned gaze.

You are 169% PWN3D if you’re unlucky enough to be stuck behind one of these suckers.

Do you scoff?  Think you can get away with SSH tunnels?  Think again.  SSH is not SSL. Never has been, never will be.  SSL wants certificates.  SSH wants session keys.  Your SSH tunnel will simply choke trying to get through.  I know.  I’ve tried.

So what is a L337 H@><0R to do?

Well, there is a half-solution out there.  It’s called stunnel and it allows you to SSL-ify programs that don’t normally do SSL.  It’s been around for ages.  Since the turn of the century!  Very mature. Very robust.

But there’s bad news.

THERE’S NO FUCKING PROXY SUPPORT!!!!!  TEN FUCKING YEARS THIS GODDAMN THING HAS BEEN AROUND AND THERE’S NO FUCKING PROXY SUPPORT!!!!

Testing this SGW last week, I ran across the same exact problem with OpenSSL’s s_client tool.  S_client allows you to peek into the SSL handshake between a server and a client to see what’s going on.  BUT IT DOESN’T FUCKING SUPPORT PROXIES EITHER!

Jesus FUCKING Christ what is it with these people???  Proxies have been around a damn site longer than SSL.  Where is the love?

I was lucky enough to run across a patch to an EIGHT YEAR OLD version of OpenSSL that adds proxy support.  It was never accepted by the OpenSSL geeks.  WHY IS THAT?  WHAT IS THE PROBLEM? In spite of its advanced age, it worked perfectly during my testing.

And, luckily enough, I found a patch for a five year old version of stunnel.  I haven’t tested it yet, but at least it compiles (although Cygwin barfs all over it at link time).

So what is the point?

Like I said, SSH is not SSL.  The SWG expects a browser-like connection on the inside and a Web server-like connection on the outside.  SSH through a (normal) proxy is a simple HTTP “CONNECT”, a straight-through pipe with no muss or fuss.  You need to make the SWG think you have a browser/server handshake going on before it will make the pipe.  Once the pipe is there it will decrypt everything going through it in order to look for naughty bits.

At the point the pipe starts flowing, you just shove your own encrypted tunnel through it.  It can hack away at that traffic all it wants, it’s not going to find any naughty bits.  And if your encrypted tunnel terminates at an obfuscated-openssh server, you are doubly protected since it will never see the initial SSH key exchange (it may not even be looking for it but… You Never Know).

But… and this is a BIG BUT… if the SWG is built right – and I’m 99% certain it’s not, given the dismal track record of this particular vendor - it should be able to tell that the data going through it is encrypted and kill the session (which seems – to me – like the Right Thing To Do if you’re truly concerned about Data Loss Prevention).  Worst case it will either eat up CPU cycles or outright crash and burn. Best case, it will pass the traffic without making a peep or logging anything at all.

Whatever the outcome, it will be reported here!

In just one run today there were a slew of Czech proxies, all on the 77.104.212.0/24 subnet, all on port 8080, all transparent, and the property of this ISP.

But with a ping time of 230+ milliseconds, nothing to write home about.  I’ve used a lot of Czech proxies in the past (hotels, Internet cafes, educational institutions, et cetera), but they’ve always been faster than that.  230ms is pathetic.

And if you telnet to them they’re running good old Mikrotik, so they must be some sort of residential or public access devices.

And yes, I checked.  They’ve changed the default password.  Dang.

Business seems to be picking up lately.  I added a new “supplier” a couple of weeks ago and it seems to be good for at least a page per day of new proxies.  A lot of these are Euro Zone proxies.  And a lot of them seem to be running Mikrotik Httproxy.

Coincidence?

Yeah, probably.

But it sure is nice having some perky German, Spanish, French, and Italian proxies again.  It’s just like the Old Days.  There’s even some UK proxies in there for the Cameroonians, who seem to have deserted me lately.

They’re not the only ones.  Traffic to the List has dropped off precipitously since November.  I’m down to a tenth of the traffic I had back then.  That would probably piss me off if I were depending on ad revenue but I don’t so it doesn’t.  These things are just cyclical.  Always have been, always will.

I’ve been waiting for another Bahrain-like incident.  Last summer we had the Canadian Health Care problem, which was fixed fairly fast.  Then there was the Macau Madness last April.  Koobface wasn’t exactly the same kind of thing, since it was a malware infection.

No, this Czech thing, like Bahrain and CHC, is more like a massive “Ooops”.  Shit happens.

I don’t expect it to last and since it’s a Class C subnet I don’t expect it to spread much.  Time will tell.

If you do any kind of hacking around with Web sites, nginx (“Engine X”) is an awesome Web server.

I do most of my keyboard-banging through a residential ISP, so I’m not technically allowed to run any kind of Web server at my end of the pipe, but I do bang the keyboard from work as well (and I’m not technically allowed to do that, either, so don’t tell anyone).  I run a few Web sites from behind my residential IP address just for educational purposes (my own education).

I decided I needed to educate myself after reading that nginx had plowed it’s way to the #3 spot behind IIS and Apache back in December (it may have happened before that – I just happened to read about it in December).

So I downloaded it and compiled it.  After I set it up and got it working, I shut down Apache for good.

Adios, old friend.  Time has come to part.

What I like most about nginx is its utter simplicity.  They tell me it’s fast as well, but I have it installed on an 800 mHz PIII, so I wouldn’t know (however, it is “fast enough”).  The WordPress sites I’m running – educationally – are served up by nginx, with the MySQL backend on the same virtual machine that runs the proxy project.  At the present time, they are served to a limited set of IP addresses via SQUID reverse-proxy, but this is going to change as soon as I can set up an nginx reverse-proxy on that particular box.

If you’re looking for technical tips and HOWTOs, I’m too much of a beginner to go that deep right now (but I will say watch out for the quick setup guides you can find online – they leave out important stuff in the example configs).  My goal is simply to gush over nginx and tell you how wonderful it is.  It is extremely simple, and if you have an IQ over 85 it should be a snap to set it up.

If you don’t have an IQ over 85, stick with IIS.

The last few times the system has hung, I noticed a trend.  Each time, without fail, there was a pop-up balloon noting that the wireless network had reconnected (the system is on the wired network, but uses a “secure” ad hoc 802.11b “point-to-point” network to route the wired network to a wireless camera).

This wireless NIC had a Marvell-based chip.  I have several of these.  I hate them all because they are proprietary and don’t work worth a damn with Linux.  Apparently this is yet another reason to despise them.

I pulled it and replaced it with a RaLink RT61 based card.  If you want to run Linux wirelessly, RaLink is the only way to fly.  It’s been fully supported in the Linux kernel for a few years now and the drivers are in active development.  You never need to mess with that god-awful ndiswrapper abortion (don’t get me wrong, ndiswrapper is a very slick hack… it just shouldn’t exist).  Unfortunately, RaLink cards are hard to find.  I’ve been burned twice by “errors in photography” where the box or the online illustration clearly shows a RaLink chip on the card, but when you open the box the damned thing has a Marvell chip.

It’s been running all week without a hitch.  I’ll give it another week and if all goes well I’ll start un-doing my previous attempts at “fixing” the problem, especially that extra gigabyte of RAM I removed a few months back.

In other news, CoDeeN servers continue to disappear.  There are now only 34 active servers left in the database.

The box overheated.

In January I pulled three fans out to make the thing a little quieter. 

So today I put them back in.