> Am 05.03.2018 um 15:34 schrieb Bill Gee <bgee@xxxxxxxxxxxxxxx>:
>
>
> On Monday, March 5, 2018 7:23:53 AM CST Leon Fauster wrote:
>> Am 05.03.2018 um 13:04 schrieb Nicolas Kovacs <info@xxxxxxxxxxxxx>:
>>> 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@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
