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

[Amos Jeffries]

On 12/02/2017 11:51 p.m., Varun Singh wrote:
> On Feb 12, 2017 2:21 PM, "Amos Jeffries" <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...

> 
> 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".

* 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.

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.

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?

HTH
Amos