l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
September 2: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2006 Jan 26 23:51

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
RE: [vox-tech] Need to bypass Squid proxy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [vox-tech] Need to bypass Squid proxy



Additionally I need the web server to see the originating IP address so
I can allow and disallow traffic by IP address.  If I do not bypass the
proxy I will only see one IP address and can not use firewall rules to
block access to those who are not authorized.

Subject: RE: [vox-tech] Need to bypass Squid proxy

I don't think I made what I want to accomplish clear.

I am at a county office of Education.  By law all web traffic to the
real Internet must be filtered.  I have a Red Hat Linux server running
N2H2 web filtering.  It is a transparent proxy.  All traffic goes
through the proxy filter and there is no way around it.

I have an internal web server that is only for the schools and is not
publicly accessible.  The proxy server does its job and sends the
traffic out where it dies on the outside of my publicly facing firewall.
I want to bypass the proxy with squid or iptables so that the private
sites can reach the private web site.

-----Original Message-----
From: vox-tech-bounces@lists.lugod.org
[mailto:vox-tech-bounces@lists.lugod.org] On Behalf Of Micah J. Cowan
Sent: Thursday, January 26, 2006 1:27 PM
To: lugod@dokuja.net; lugod's technical discussion forum
Subject: Re: [vox-tech] Need to bypass Squid proxy

On Thu, Jan 26, 2006 at 12:43:47PM -0800, Seth Nagao wrote:
> On 1/26/06, Micah J. Cowan <micah@cowan.name> wrote:
> > I'm aware that squid will proxy SSL, at least on non-transparent
> > connections (I do that often). I don't see how it can do that
> > transparently: It doesn't know the server's private key. It could
use a
> > totally /separate/ key to pretend to be the server, and then pretend
to
> > be the client to the server, but that would be wrong, wrong, WRONG,
and
> > I very much doubt the developers of squid make it do that.
> 
> Interestingly enough, I went to an ISSA meeting which included a
> vendor that intended to do EXACTLY that.  The line of thought went
> something like, "Well, we're the good guys, so it's not really a MITM
> attack."  I'll see if I can find the info I have on them next time I'm
> in the office.  I've been curious of what legal implications that such
> a proxy might incur if a breach of security happened at that point,
> but that might be covered in the big nasty legal documents you often
> have to sign.

There are concerns in doing this, even from the vendor point of view.

For instance, since you can't get a trusted certificate authority to
give you a signature for the destination server you're pretending to be,
the user's browser (if it's any good) will always through up a "WARNING:
not signed by a trusted provider" or "WARNING: certificate doesn't
belong to the site they're claiming to be".

So, being able to do this "transparently" is pretty limited. And once
users realize what's going on, several of them are liable to become
PISSED.

And, documents or not, I'm willing to bet that if a security breach
happened at that point, you can sue their friggin' ass off. Deployed
against employees at a corporation, you could probably sue the
employer's ass off, too: and they probably didn't think hard enough
about it to make you sign documents anyway.

All in all, a much better alternative, if you really want to have
absolute* control over what goes out over your network, is to simply
disallow outgoing HTTPS altogether. Let them check their bank accounts
from home, etc. :-)

Clearly, these guys had not thought things through. And no sysadmin
worth his salt would buy such a product (and, if he were forced to,
would never enable such a stupid feature).

*Practically, no such thing. Even if we do this, what's to prevent
someone from setting up their /own/ proxy over permitted channels?
Someone once implemented IP-over-email to illustrate circumvention of
firewalls...

-- 
Micah J. Cowan
micah@cowan.name
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.