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/ Hope this helps -- Karl E. Jorgensen -- 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/20130628174741.GY15076@hawking
