Wouldn't filtering the DNS be more practical? On 5 March 2018 at 18:57, Leon Fauster <leonfauster at googlemail.com> wrote: > > > Am 05.03.2018 um 15:34 schrieb Bill Gee <bgee at campercaver.net>: > > > > > > On Monday, March 5, 2018 7:23:53 AM CST Leon Fauster wrote: > >> Am 05.03.2018 um 13:04 schrieb Nicolas Kovacs <info at microlinux.fr>: > >>> Le 28/02/2018 à 22:23, Nicolas Kovacs a écrit : > >>>> So far, I've only been able to filter HTTP. > >>>> > >>>> Do any of you do transparent HTTPS filtering ? Any suggestions, > >>>> advice, caveats, do's and don'ts ? > >>> > >>> After a week of trial and error, transparent HTTPS filtering works > >>> perfectly. I wrote a detailed blog article about it. > >>> > >>> https://blog.microlinux.fr/squid-https-centos/ > >> > >> I wonder if this works with all https enabled sites? Chrome has > >> capabilities hardcoded to check google certificates. Certificate > >> Transparency, HTTP Public Key Pinning, CAA DNS are also supporting > >> the end node to identify MITM. I hope that such setup will be > unpractical > >> in the near future. > >> > >> About your legal requirements; Weighing is what courts daily do. So, > >> such requirements are not asking you to destroy the integrity and > >> confidentiality >95% of users activity. Blocking Routing, DNS, IPs, > >> Ports are the way to go. > >> > >> -- > >> LF > > > > Although not really related to CentOS, I do have some thoughts on this. > I > > used to work in the IT department of a public library. One of the big > > considerations at a library is patron privacy. We went to great lengths > to > > NOT record what web sites were visited by our patrons. We also deny > requests > > from anyone to find out what books a patron has checked out. > > > > The library is required by law to provide web filtering, mainly because > we > > have public-use computers which are used by children. For http this is > easy. > > Https is, as this discussion reveals, a different animal. > > > > We started to set up a filter which would run directly on our router > (Juniper > > SRX-series) using EWF software. It quickly became apparent that any > kind of > > https filtering requires a MITM attack. We were basically decrypting the > > patron's web traffic on our router, then encrypting it again with a > different > > cert. > > > > When we realized what it would take, we had a HUGE internal discussion > about > > how to proceed. Yeah, the lawyers were all over it! In the end we > decided to > > not attempt to filter https traffic except by whatever was not encrypted. > > Basically that means web site names. > > > > Our test case was the Playboy web site. They are available on https, > but they > > do not automatically redirect http to https. If you open playboy [dot] > com > > with no protocol specified, it goes over http. Our existing filter > blocked > > that. However, if you open https[colon]// playboy [dot] com, it goes > straight > > in. The traffic never goes over http, so the filter on the router never > > processes it. > > > > Security by obscurity ... It was the best we could do without violating > our > > own policies on patron privacy. > > > All browsers sent "server_name" [*] in there https requests. That is the > domain part of > the URI. So, you can identify the requested https site without decrypting > (because its > "lets call it a header" that includes this information) and without > damaging the privacy. > > [*] https://tools.ietf.org/html/rfc6066 > > -- > LF > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >