<div dir="auto"><div><div data-smartmail="gmail_signature"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 12, 2017 5:43 PM, "Amos Jeffries" <<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>> wrote:<br type="attribution"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-6872900206847984097quoted-text">On 12/02/2017 11:51 p.m., Varun Singh wrote:<br>
> On Feb 12, 2017 2:21 PM, "Amos Jeffries" <<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>> wrote:<br>
><br>
> On 12/02/2017 7:40 p.m., Varun Singh wrote:<br>
>><br>
>> The answer points to installing a CA on client.<br>
><br>
> The question was about how to get browsers talking TLS *directly to a<br>
> Squid reverse-proxy*. Your Ubuntu package is not capable of that and you<br>
> are not using a reverse-proxy.<br>
><br>
>> Does this mean even if I don't want Squid-in-the-middle approach, my<br>
>> clients would still have to install a certificate?<br>
><br>
> No. It is irrelevant to yrou sitation.<br>
><br>
><br>
> You began this thread with a simple question:<br>
><br>
>> Hi,<br>
>> I have a Squid 3 installed on Ubuntu 16.04. It works perfectly as an<br>
>> HTTP proxy server in transparent mode.<br>
>> I wanted to know whether it can be configured to run as HTTPS proxy<br>
>> server without ssl-bump i.e. without 'man in the middle attack'<br>
>> technique.<br>
><br>
><br>
> Everything you have been asking about since then is various ways to do<br>
> parts of the SSL-bump process. Which does not fit very well with the<br>
> "without ssl-bump" requirement.<br>
><br>
><br>
> Simply put; if you are not going to SSL-Bump then you can discard any<br>
> thoughts of doing things with the HTTPS messages or port 443 traffic.<br>
><br>
> If you have changed your mind and want to use SSL-Bump now, please<br>
> re-describe what you want to actually happen now.<br>
><br>
<br>
</div>You have not described what you want to happen. Just asked how to do<br>
this unknown thing...<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">This proxy server will filter HTTP and HTTPS websites based on ACL provided. For security reasons, I want to avoid using SSL-bump.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="m_-6872900206847984097quoted-text"><br>
><br>
> Hi,<br>
> Simply put, my question has three parts:<br>
> 1. Can Squid be configured as an HTTPS proxy server without SSL-Bump?<br>
<br>
<br>
</div>* The term "HTTPS" is a generic term used to simultaneously describe two<br>
completely different traffic syntaxes (CONNECT tunnels, and port 443 TLS).<br>
<br>
* There are three proxy operating "modes" which may receive each of<br>
those types of traffic (explicit/forward, intercept/tproxy, and<br>
reverse/CDN/accel).<br>
<br>
* For each type of traffic one mode is invalid, leaving 2x2= 4 different<br>
sets of operations all called "proxying HTTPS".<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir="auto">This means the combinations are:</div><div dir="auto">#1 CONNECT - explicit/forward</div><div dir="auto">#2 443 TLS - explicit/forward</div><div dir="auto"><br></div><div dir="auto">#3 CONNECT - intercept/tproxy</div><div dir="auto">#4 443 TLS - intercept/tproxy</div><div dir="auto"><br></div><div dir="auto">#5 CONNECT - reverse/CDN/accel</div><div dir="auto">#6 443 TLS - <span style="font-family:sans-serif">reverse/CDN/accel</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">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.</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* all 4 of those ways may be done with or without SSL-Bump feature.<br>
<br>
When not using SSL-Bump 2 of the ways of "proxying HTTPS" will work, 2<br>
will not.<br>
<br>
When using SSL-Bump the non-working ways of "proxying HTTPS" will start<br>
working, and the working ways will have an extra permutation of splice<br>
vs bump operation that can happen. Extending the possibilities to be 6<br>
ways of "proxying HTTPS".<br>
<br>
<br>
So the answer(s) to your first question are:<br>
<br>
yes, no.  yes, no.  no, yes.<br>
<div class="m_-6872900206847984097quoted-text"><br>
<br>
<br>
> 2. If yes, then what other configurations have to performed other than<br>
> "https_port XXXX"?<br>
<br>
</div>For the cases where the #1 answer was "yes" and not "no".<br>
<br>
a) An explicit/forward or intercept proxy not using ssl-bump and<br>
receiving CONNECT requests does not need any special configuration to<br>
"proxy HTTPS". The proxy will simply enact the requested opaque tunnel<br>
in accordance to HTTP rules.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir="auto">So this means other than specifying "https_port XXXX" no other config is needed. </div><div dir="auto">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".</div><div dir="auto"><br></div><div dir="auto">So either something is wrong in my squid.conf or my assumption is incorrect that my scenario falls in #1 or #3.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
b) A reverse proxy requires the 'accel' mode flag, and the cert= option<br>
must load the cert for the domain you are hosting on that port, and the<br>
key= option must load the private key for that certificate.<br>
<br>
c) all other modes will not work without SSL-Bump feature.<br>
<div class="m_-6872900206847984097quoted-text"><br>
<br>
<br>
> 3. In this configuration, can Squid filter HTTPS requests from ACL?<br>
><br>
<br>
</div>That depends on the meaning of "this". There are 3 different<br>
configurations in the answer to #2.<br>
<br>
For (2a) - no. Only the CONNECT request can be filterd.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir="auto">From below links it looks like destination IP Address or hostname of a CONNECT request is same as HTTPS request. Is that correct?</div><div dir="auto"><br></div><div dir="auto"><a href="https://en.m.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling">https://en.m.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling</a></div><div dir="auto"><br></div><div dir="auto"><a href="http://stackoverflow.com/a/11698002/548403">http://stackoverflow.com/a/11698002/548403</a></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For (2b) - yes. BUT, notice that it requires private key data for certs.<br>
This configuration is only usable when _you own the domain_ which the<br>
client is visiting.<br>
<br>
For (2c) - SSL-Bump feature is the mechanism which enables https://<br>
filtering for all traffic modes other than that described by (2b).<br>
Without using that feature - no.<br>
<br>
<br>
Do you understand now why every path you have tried ends up with how-tos<br>
for configuring SSL-Bump?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Yes, thanks for the elaborate explanation.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6872900206847984097quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
HTH<br>
<font color="#888888">Amos<br>
<br>
</font></blockquote></div><br></div></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div></div>