On Mon, Jun 04, 2007 at 11:34:30PM +0100, Sam Stickland wrote: > > Matthew Palmer wrote: > >I can think of one counter-example to this argument, and that's > >SSL-protected services, where having a proxy, transparent or otherwise, in > >your data stream just isn't going to work. > > Not so. Look at: http://muffin.doit.org/docs/rfc/tunneling_ssl.html
Sorry, that was a *really* poor choice of phrase on my part (so much for my proof-reading skills). It certainly wasn't what I meant to say. What I *meant* to say is that while you *can* tunnel HTTPS (or other SSL/encryption protected) traffic through a regular proxy, it doesn't provide any value that a firewall can't, because you can't get any protocol-specific info out of the data stream (which is what a regular application proxy depends on to do it's work). Everything that I can think of that you can do in a proxy with an HTTPS request can be done in the firewall instead (although you may lack the infrastructure in your firewall to do it while it's built into your proxy, such as restricting IP addresses or request rates or whatever). Your HTTP proxy can't restrict HTTPS traffic based on the requested hostname, it can't cache the request, it can't log the request URL, it can't do any sort of request/response rewriting, and so on. The argumentative person might observe that you can require authentication to use an HTTP proxy, but you can also have logins to firewalls (a la captive portals). Hopefully that's a little more useful (though verbose) than my previous comment. <grin> - Matt
