Re: [proxyTools-users] Privacy in proxytools - url obfuscation?

[wayne <wa...@ny...>]

Jose Bernardo Silva wrote:

> Hello!

> 

> I am using now another software to bypass the corporate firewall censorship

> measures. The use NTLM for authentication, websense for the censorship

> software. My problem is that the sw that I use now, hasn't been updated in

> over 2 years, and doesn't support "translating" much of the javascript being

> used to navigate inside sites.

> I was thinking of using proxytools instead, but I need to know if the url's

> are obfuscated when they are sent thru the corporate proxy (as it is done by

> the sw that I use now), or are they sent in plain view? If so, I can't use

> proxytools, as accessing competitors websites or recruitment sites is reason

> for disciplinary procedures, so finding a url for one of those in the ISA logs

> would get me into trouble.

> Thank you!

> 

> PS: I have a server outside the corporate network with cgi access, so I can

> always put a script or a program there to obfuscate the urls and proxy

> everything...



Several points here:

0) localProxy can be configured manually to do just about anything, but it's not 

easy. Automatic configuration is really the only option for most people.

1) although localproxy can be configured to use a simple non-ssl external obfuscating proxy, 

the configuration to guarantee your safety is not easy. I wrote the thing and I 

would need to do extensive tests before I trusted my own configuration!

2) localproxy seems like a silly way to handle this given that you have an external 

box anyway. LP is really only for those who don't have such a thing. There are 

*far* better ways in this case.

3) if you insist on a CGIProxy, I'd stll recommend James Marshall's CGIProxy, written 

in Perl BTW. Set it up on your external SSL web server, and you're safe.  

It's getting old, and maybe there are better CGI proxies available now though.

4) beware of home-grown proxies. They usually forget to protect against 'replay' 

attacks where the the network admin can just repeat a url he sees you using 

from his proxy logs to see where you were going. I don't know about Michael's, 

but make sure that's included. 

5) Note that using this method, all your obfuscated urls are easily noticeable 

in the NTLM proxy logs.



I think the best way for you (and this is the method i use) is to set up an 

encrypted tunnel to your external box using ssh/sshd. 

Note that if you own the external box,  a VPN would be even better than the 

ssh approach. 

Anyway, use ssh with a dynamic port forwarded (that's a Socks port).

For completeness, you might also forward a port to a proxy 

you run outside too (useful for apps which can't be convinced 

to use Socks). Then set your browser to use the Socks proxy (localhost:1080 

is a good choice). Socksify other apps to use the same thing (IM's are usually 

all ok with this). Others that need an HTTP proxy and can't be socksified (e,g, 

Perl module updates, Linux updates, etc.) will use the static forwarded port. 

Further static ports can be set up fo any other non-HTTP apps.



The trick with that approach is setting up the tunnel. I assume your NTLM 

proxy will allow you to get to secure web sites (it will allow you to CONNECT 

to port 443 on those sites). You better have your external server listening on 

that port (or maybe 80) otherwise it won't be permitted.

The first step is to get something that will talk to NTLM, and make the CONNECT 

tunnel. I use two things for this, but there might be better stuff around now. The 

NTLM is handled by ntlmproxy (Perl, distributed in the proxyTools package). It 

just provides A non-NTLM proxy interface for you. Then I use something like 

'connect' (recommended in the ssh documentation, IIRC) to make the actual 

CONNECT tunnel. Then ssh to the localhost end of the tunnel (with sshd running 

at the other end) will make an encrypted tunnel with the socks and http proxy 

forwarded ports. Any use of this tunnel is now completely safe from prying eyes. 



Every now and then, I find a Java applet in a web page that ignores the 

browser proxy settings, and tries to connect to it's home directly. They don't 

use the NTLM proxy even so, and it would be hard to imagine a network admin 

savvy enough to see and recognize this. I trust my career to that too. :-)



wa...@ny...st

(remove the extra 's')