<div dir="ltr">This configuration here covers the use case described by the OP: <div><a href="https://gist.githubusercontent.com/splashx/758ff0c59ea291f32edafc516fdaad73/raw/8050fa054821657812961050332b38a56e7e3e68/">https://gist.githubusercontent.com/splashx/758ff0c59ea291f32edafc516fdaad73/raw/8050fa054821657812961050332b38a56e7e3e68/</a><div><br></div><div><div>If everything works well, you'll notice you won't support HTTP proxy at all, but users can reach  both HTTP and HTTPS target websites via your HTTPS proxy.</div><div><br></div><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"># netstat -nltp</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">Active Internet connections (only servers)</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">tcp        0      0 <a href="http://0.0.0.0:22">0.0.0.0:22</a>              0.0.0.0:*               LISTEN      32109/sshd      </p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">tcp6       0      0 :::80                   :::*                    LISTEN      26627/apache2   </p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">tcp6       0      0 :::3443                 :::*                    LISTEN      7303/(squid-1)  </p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">tcp6       0      0 :::22                   :::*                    LISTEN      32109/sshd</p></div></div><div><br></div><div><br><div>The user connects to the proxy ONLY via HTTPS Proxy on port 3443</div><div><br></div><div>All traffic between the OP and the proxy is encrypted using TLS. </div><div>A) If the user enters <a href="http://target.example.com">http://target.example.com</a>, between the proxy and the target you'll see HTTP. </div><div>B) If the user enters <a href="https://target.example.com">https://target.example.com</a>, between the proxy and the target you'll see HTTPS.</div><div><br></div><div>If you sniff the traffic between the client and the proxy, you'll see TLS.</div><div><br></div><div>Tested with:</div><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="">$</span><span style="color:rgb(234,234,234)"> </span><span style="">/Applications/Firefox\ 2.app/Contents/MacOS/firefox -v</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="">Mozilla Firefox 48.0</span></p></div><div><br></div><div>Firefox set up to use PAC: Preferences > Advanced > Network > Settings: "Automatic Proxy Configuration": <a href="http://squid.example.com/proxy.pac">http://squid.example.com/proxy.pac</a></div><div><br></div><div>The downside here of course is the limited amount of clients supporting HTTPS Proxy settings.</div></div></div><div><br></div><div>Dio</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 24, 2016 at 3:46 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just to rewind this conversation to the actual problem ...<br>
<span class=""><br>
On 24/08/2016 11:42 p.m., Samuraiii wrote:<br>
> On 24.8.2016 13:18, Antony Stone wrote:<br>
>> Unfortunately it's not Squid that's the challenge - it's the browser.<br>
>><br>
>> If you're using Firefox and/or Chrome, you should be okay.<br>
>><br>
>> See "Encrypted browser-Squid connection" at the bottom of<br>
>> <a href="http://wiki.squid-cache.org/Features/HTTPS" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/<wbr>Features/HTTPS</a><br>
>><br>
>><br>
>> Antony.<br>
>><br>
> I have seen that, it is the cause of my subscription to this list.<br>
> I haven't been able to find any usable hints.<br>
> My config attempt fails<br>
><br>
<br>
</span><snip><br>
<span class="">><br>
> https_port 8443 \<br>
>     cert=/etc/letsencrypt/live/<a href="http://sklad.duckdns.org/cert.pem" rel="noreferrer" target="_blank">skl<wbr>ad.duckdns.org/cert.pem</a> \<br>
>     key=/etc/letsencrypt/live/<a href="http://sklad.duckdns.org/key.pem" rel="noreferrer" target="_blank">skla<wbr>d.duckdns.org/key.pem</a> \<br>
>     cleintca=/etc/letsencrypt/<wbr>live/<a href="http://sklad.duckdns.org/fullchain.pem" rel="noreferrer" target="_blank">sklad.duckdns.org/<wbr>fullchain.pem</a> \<br>
>     tls-dh=/etc/ssl/certs/dhparam.<wbr>pem \<br>
>     sslproxy_options=NO_SSLv2,NO_<wbr>SSLv3,SINGLE_DH_USE \<br>
>     cipher=HIGH<br>
<br>
<br>
</span>As Dio mentioned the cleintca= (or rather clientca=) is for<br>
authenticating clients ceritficates. Don't use that unless you are<br>
requiring client certs in TLS.<br>
<br>
The rest of your config looks reasonable to me. I suspect you have found<br>
a bug introduced during all the SSL-Bump code changes. Please make a<br>
bugzilla report and include your exact Squid version (found with the<br>
'squid -v' command), the https_port line(s) and the exact error message<br>
produced on startup.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br>--------<br><br>Diogenes S. de Jesus</div></div></div>
</div>