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
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. > > -- > LFAlthough 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. -- Bill Gee
Starting with version 3.5 of Squid, was introduced a new feature named "*SslBump Peek and Splice*". With this functionality, Squid is able to intercept HTTPS traffic transparently (with exceptions, of course). This manner, Squid, with spike, is able to logging HTTPS traffic and apply directives like dstdomain on HTTPS traffic without need of a auto-signed CA. This resource of Squid is the same functionality available on apliances like Sonicwall, Fortigate, Checkpoint, and etc. A example of config: http_port 80 intercept https_port 443 intercept ssl-bump cert=/etc/squid3/ssl/ca/intermediate/certs/wilcard.pem key=/etc/squid3/ssl/ca/intermediate/private/wildcard.key generate-host-certificates=off version=4 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE cache_log /var/log/squid3/cache.log access_log daemon:/var/log/squid3/access.log squid netdb_filename stdio:/var/log/squid3/netdb.state sslcrtd_program /usr/libexec/ssl_crtd -s /var/log/squid3/ssl_db -M 4MB sslcrtd_children 1 startup=1 idle=1 cache_effective_user proxy cache_effective_group proxy pinger_enable off dns_v4_first on acl HTTPS dstdomain "/etc/squid3/https" acl BLOCK url_regex "(torrent)|sex(y|o)" cache deny all ssl_bump bump HTTPS ssl_bump splice all http_access deny BLOCK http_access allow all PS: the use of "ssl-bump" is only to satisfy de Squid parser. Best clarifications: https://wiki.squid-cache.org/Features/SslPeekAndSplice Att, 2018-03-05 11:34 GMT-03:00 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. > > -- > Bill Gee > > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
On 03/05/18 07:23, 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.Google, huh ;-( see below...> 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.I would add avoiding google and all google products by all means to the above list ;-) valeri> > -- > LF > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 03/05/18 08:34, Bill Gee wrote:> > 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.I bet, your servers never embedded links to anything external. If it is external link, it is requested to open in new browser window. No part of the page should need external (not living on our server) content. That was the way we did it since forever. It sounds like I will have to fight soon against "google-analytics" glued into each page of our websites. It is amazing that people who have no knowledge rule technical aspects of IT in many places... Valeri> > 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. >-- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
> 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
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.And how do you get a list of IPs from which data could be retrieved which the students are not supposed to see? How is this done anyway, does the government give out a list of URLs or IPs which you are required to block? If not, what if you overlook something?
Le 06/03/2018 ? 18:48, hw a ?crit?:> And how do you get a list of IPs from which data could be retrieved > which the students are not supposed to see? > > How is this done anyway, does the government give out a list of URLs > or IPs which you are required to block?? If not, what if you overlook > something?Here's some information. https://dsi.ut-capitole.fr/documentations/cache/squidguard_en.html Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32