On Thu, Jan 26, 2006 at 12:43:47PM -0800, Seth Nagao wrote: > On 1/26/06, Micah J. Cowan <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
