Without the SSL splitting the only option is to install some software on the client side. Some "endpoint" security software doing the inspection of the web data transfers on the fly before they pass the TLS tunnel. It's the same like SSL split on Squid, but let's say more transparent. Unfortunately I don't know any such software for Linux - all of those I know are for Windows as this OS has API for that "spying". Can mention two for all of them: - Kaspersky Internet Security - Eset Endpoint Security These are my favorites, but there are other SWs available. The open source and best way to protect children is the proxy with SSLBump. Have a look on Untangle [1] for complete FW solution with the SSLBump feature.
[1] www.untangle.com On Thu, Mar 26, 2015 at 2:04 PM, Michael I. <linux-michae...@abwesend.de> wrote: > Sven Hartge <s...@svenhartge.de> wrote: > >> Michael I. <linux-michae...@abwesend.de> wrote: >> >> But I have a new problem, I want to have a transparent proxy for http >>> this works fine but when I add the iptables rule for https the loading >>> won't work. >>> >> >> Of course not. That this is not working is the _whole point_ of any >> end-to-end encrypted connection. >> >> What you are effectivly trying to do is an Man-in-the-Middle "attack". >> >> > All I want is to protect children of harmful content (adult content). > > You cannot transparently proxy *any* encrypted connection without major >> trickery, like I wrote in my first mail. You would need a fake CA >> certificate (why this is a _very_ bad idea you just have to look at the >> latest CNNIC and MSC debacle: (sorry, German URL) >> <https://www.psw-group.de/blog/cnnic-signiert-falsche- >> google-zertifikate/2112> >> or >> <http://www.heise.de/security/meldung/Google-deckt-erneut- >> Missbrauch-im-SSL-Zertifizierungssystem-auf-2583414.html>), and have >> your proxy terminate the end-to-end encryption by issuing a fake >> certificate on the fly, so that the client is satisfied and then create >> another new encrypted connection to the intended end-point. >> >> There _are_ security appliances out there which work in that way but >> they are considered _very_ *very* bad practice and should be avoided at >> all costs. >> >> > I don't want to fake a CA certificate because the danger. > > Is there any other way to block those sites? Maybe block the IPs in the > firewall, but I think this is a big hassle? > > Grüße, >> Sven. >> >> > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a > subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/551403f7.7080...@abwesend.de > >
