[squid-users] Basic HTTPS filtering via CONNECT in Squid

Wed Feb 15 07:21:35 UTC 2017

On Mon, Feb 13, 2017 at 12:04 PM, Eliezer Croitoru <eliezer at ngtech.co.il> wrote:
>
> Hey Varun,
>
> Filtering content based on the URL level\layer of the connection is not possible without SSL-bump.
> There for you must use for some aspect of the connections SSL-bump.
> However you can selectively choose which destinations would be bumped and which are not.
> Most of the current browsers supports SNI which allows squid in some degree to decide if to fully bump the connection to the URL level or to decide to only proxy the connection in the TCP level.
> As simple as it sounds URL level filtering requires full SSL-bump and TCP and basic TLS level filtering will not require you to fully utilize SSL-bump but will require you to fully setup squid for SSL-bump.
>
> This is the place to clarify that SNI based filtering is not 100% bullet proof and it could be exploited to override in a way your basic SNI based SSL level filtering.
>
> Do you have specific sites that you want to filter in the URL level or just globally?
> The answer to the above question will guide us towards what might be the right path for your solution(which could be full SSL-BUMP or partial).
>
> Eliezer
>
> ----
> http://ngtech.co.il/lmgtfy/
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: eliezer at ngtech.co.il
>
>
> From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Varun Singh
> Sent: Monday, February 13, 2017 5:37 AM
> To: Amos Jeffries <squid3 at treenet.co.nz>
> Cc: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Basic HTTPS filtering via CONNECT in Squid
>
>
>
> On Feb 12, 2017 5:43 PM, "Amos Jeffries" <mailto:squid3 at treenet.co.nz> wrote:
> On 12/02/2017 11:51 p.m., Varun Singh wrote:
> > On Feb 12, 2017 2:21 PM, "Amos Jeffries" <mailto:squid3 at treenet.co.nz> wrote:
> >
> > On 12/02/2017 7:40 p.m., Varun Singh wrote:
> >>
> >> The answer points to installing a CA on client.
> >
> > The question was about how to get browsers talking TLS *directly to a
> > Squid reverse-proxy*. Your Ubuntu package is not capable of that and you
> > are not using a reverse-proxy.
> >
> >> Does this mean even if I don't want Squid-in-the-middle approach, my
> >> clients would still have to install a certificate?
> >
> > No. It is irrelevant to yrou sitation.
> >
> >
> > You began this thread with a simple question:
> >
> >> Hi,
> >> I have a Squid 3 installed on Ubuntu 16.04. It works perfectly as an
> >> HTTP proxy server in transparent mode.
> >> I wanted to know whether it can be configured to run as HTTPS proxy
> >> server without ssl-bump i.e. without 'man in the middle attack'
> >> technique.
> >
> >
> > Everything you have been asking about since then is various ways to do
> > parts of the SSL-bump process. Which does not fit very well with the
> > "without ssl-bump" requirement.
> >
> >
> > Simply put; if you are not going to SSL-Bump then you can discard any
> > thoughts of doing things with the HTTPS messages or port 443 traffic.
> >
> > If you have changed your mind and want to use SSL-Bump now, please
> > re-describe what you want to actually happen now.
> >
> You have not described what you want to happen. Just asked how to do
> this unknown thing...
>
> I want to implement a URL filter using proxy server. My clients will use this server either from their web-browsers or via strongSwan IPSec VPN server. If they use the proxy server via VPN server, their VPN profile will have HTTP and HTTPS proxy server configuration.
>
> This proxy server will filter HTTP and HTTPS websites based on ACL provided. For security reasons, I want to avoid using SSL-bump.
>
>
> >
> > Hi,
> > Simply put, my question has three parts:
> > 1. Can Squid be configured as an HTTPS proxy server without SSL-Bump?
>
> * The term "HTTPS" is a generic term used to simultaneously describe two
> completely different traffic syntaxes (CONNECT tunnels, and port 443 TLS).
>
> * There are three proxy operating "modes" which may receive each of
> those types of traffic (explicit/forward, intercept/tproxy, and
> reverse/CDN/accel).
>
> * For each type of traffic one mode is invalid, leaving 2x2= 4 different
> sets of operations all called "proxying HTTPS".
>
> This means the combinations are:
> #1 CONNECT - explicit/forward
> #2 443 TLS - explicit/forward
>
> #3 CONNECT - intercept/tproxy
> #4 443 TLS - intercept/tproxy
>
> #5 CONNECT - reverse/CDN/accel
> #6 443 TLS - reverse/CDN/accel
>
> One of modes in each type is invalid. So, from Squid's HTTPS feature page, looks like my scenario falls either in #1 or #3.
>
> * all 4 of those ways may be done with or without SSL-Bump feature.
>
> When not using SSL-Bump 2 of the ways of "proxying HTTPS" will work, 2
> will not.
>
> When using SSL-Bump the non-working ways of "proxying HTTPS" will start
> working, and the working ways will have an extra permutation of splice
> vs bump operation that can happen. Extending the possibilities to be 6
> ways of "proxying HTTPS".
>
>
> So the answer(s) to your first question are:
>
> yes, no.  yes, no.  no, yes.
>
>
>
> > 2. If yes, then what other configurations have to performed other than
> > "https_port XXXX"?
> For the cases where the #1 answer was "yes" and not "no".
>
> a) An explicit/forward or intercept proxy not using ssl-bump and
> receiving CONNECT requests does not need any special configuration to
> "proxy HTTPS". The proxy will simply enact the requested opaque tunnel
> in accordance to HTTP rules.
>
> So this means other than specifying "https_port XXXX" no other config is needed.
> When I setup Squid with just "https_port xxxx" and configured Firefox to use my proxy server for HTTP and HTTPS, it worked fine for HTTP but for HTTPS it gave "Proxy server rejected connection".
>
> So either something is wrong in my squid.conf or my assumption is incorrect that my scenario falls in #1 or #3.
>
>
> b) A reverse proxy requires the 'accel' mode flag, and the cert= option
> must load the cert for the domain you are hosting on that port, and the
> key= option must load the private key for that certificate.
>
> c) all other modes will not work without SSL-Bump feature.
>
>
>
> > 3. In this configuration, can Squid filter HTTPS requests from ACL?
> >
> That depends on the meaning of "this". There are 3 different
> configurations in the answer to #2.
>
> For (2a) - no. Only the CONNECT request can be filterd.
>
> From below links it looks like destination IP Address or hostname of a CONNECT request is same as HTTPS request. Is that correct?
>
> https://en.m.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling
>
> http://stackoverflow.com/a/11698002/548403
>
>
> For (2b) - yes. BUT, notice that it requires private key data for certs.
> This configuration is only usable when _you own the domain_ which the
> client is visiting.
>
> For (2c) - SSL-Bump feature is the mechanism which enables https://
> filtering for all traffic modes other than that described by (2b).
> Without using that feature - no.
>
>
> Do you understand now why every path you have tried ends up with how-tos
> for configuring SSL-Bump?
>
> Yes, thanks for the elaborate explanation.
>
>
> HTH
> Amos
>
>
>
>
>
>
>
>
>
>
>

Thanks for your reply Eliezer. As I understand, if I want to filter
HTTPS websites based on only hostname/IP-Address, I will still have to
configure SSL-bump. However, I may not have to use the complete
feature in order to do so. Moreover, I can choose which website to
apply SSL-bump to.
Am I correct in my assumptions?

> This is the place to clarify that SNI based filtering is not 100% bullet proof and it could be exploited to override in a way your basic SNI based SSL level filtering.

The SNI solution may work with web-browsers but my solution is also
targeting clients connecting via to proxy via VPN. I think SNI won't
work in that case. Is that right?

>
> Do you have specific sites that you want to filter in the URL level or just globally?

I have a list of URL regexes. I have to filter HTTPS websites whose
URLs match the regex pattern.

> The answer to the above question will guide us towards what might be the right path for your solution(which could be full SSL-BUMP or partial).

-- 
Thanks,
Varun