Am 28.06.2013 19:47, schrieb Karl E. Jorgensen: > On Fri, Jun 28, 2013 at 01:12:38PM +0100, Chris Davies wrote: >> Frank Lanitz <fr...@frank.uvena.de> wrote: >>> Is there a way of using a squid proxy in transparent way [...] for SSL. >>> If I'm entering the proxy directly into >>> e.g. Firefox it's working -- but don't got it running via transparent mode. >> >> As you'll know, it's pretty straightforward to set up a transparent >> proxy for (unencrypted) HTTP traffic. However, creating one for HTTPS/SSL >> traffic is far harder. >> >> The simplistic answer is that you can't do this. The reason here is >> that the web browser won't issue a proxy CONNECT request unless it knows >> there's a proxy involved. And because you've got a transparent setup it >> doesn't know. So it tries to go directly to the target website. But you're >> intercepting the traffic and routing it via squid, so it can't get there - >> or else you're going to be providing an incorrect certificate. >> >> There are a number of options you've got at this point. >> >> 1. Prevent all SSL-based web browsing. (Probably unrealistic.) >> >> 2. Create a Certificate Authority and install your CA certificate on all >> users' web browers. Hijack tcp/443 SSL traffic as before but spoof the >> appropriate certificate dynamically (sign it with your own CA). Decrypt >> the traffic, route it via squid or whatever, re-encrypt it and send it >> on to the target host. (Probable privacy concerns with this option.) >> >> 3. Abandon the transparent approach. Block all tcp/80 and tcp/443 access >> except via your proxy. Provide a wpad configuration file that people will >> find by enabling "auto configure", and have this instruct web browsers >> to use your proxy. (Recommended solution.) >> >> 3a. As for #3 but also continue to hijack tcp/80 and tcp/443, pointing >> them to a static page that explains how to enable automatic configuration. >> >> If you really want/need to force all traffic via your proxy I'd recommend >> you seriously consider option 3/3a. > > I just realised: there is a 4th (or is that 5th?) option: policy based > routing. > > By default the IP routing is done solely based on destination IP > address. With policy based routing, you can base the routing decisions > on other things too - e.g. source IP address, port numbers etc. > > This would allow you to route e.g. https traffic (identified by being > TCP + port 443) e.g. through a VPN and (hopefully) being SNATed at the > other end without sending ALL traffic to that destination. Assuming > correct NATing (where applicable), this should be completely > transparent to browsers and other apps. > > This link may be handy: > http://lartc.org/howto/
Sounds like a nice idea. Will give it a try. Was already thinking about a NAT-box inside the network of 2nd side. Cheers, Frank -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51cddba2.5050...@frank.uvena.de
