Re: Squid and HTTPS interception on CentOS 7 ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Wouldn't filtering the DNS be more practical?

On 5 March 2018 at 18:57, Leon Fauster <leonfauster@xxxxxxxxxxxxxx> wrote:

>
> > 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
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux