[squid-users] ERR_CANNOT_FORWARD with Squid + Privoxy

[Amos Jeffries]

On 12/01/2017 4:56 a.m., Stepan Bujnak wrote:
> Thank you very much for the reply!
> 
> On Wed, Jan 11, 2017 at 6:23 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:
>> On 11/01/2017 2:26 p.m., Stepan Bujnak wrote:
>>> Hi,
>>>
>>> I've been trying to configure intercepting proxy with privoxy as a
>>> cache_peer. This is my Squid configuration:
>>>
>>> acl all src all
>>>
>>> acl SSL_ports  port 443
>>> acl Safe_ports port 80          # http
>>> acl Safe_ports port 21          # ftp
>>> acl Safe_ports port 443         # https
>>> acl Safe_ports port 70          # gopher
>>> acl Safe_ports port 210         # wais
>>> acl Safe_ports port 1025-65535  # unregistered ports
>>> acl Safe_ports port 280         # http-mgmt
>>> acl Safe_ports port 488         # gss-http
>>> acl Safe_ports port 591         # filemaker
>>> acl Safe_ports port 777         # multiling http
>>> acl CONNECT    method CONNECT
>>>
>>> #http_access deny !Safe_ports
>>> #http_access deny CONNECT !SSL_ports
>>> http_access allow all
>>>
>>> # stop squid taking forever to restart.
>>> shutdown_lifetime 3 second
>>>
>>> client_dst_passthru off
>>> host_verify_strict off
>>
>> Please pay attention to the docs for these options. Specifically how it
>> says host_verify_strict has no effect on intercepted traffic. Also how
>> it says client_dst_passthru has no effect when the Host verify process
>> detects an origin mismatch (eg 'fails').
> 
> I figured out the origin mismatch part. Unfortunately, this is very
> important to me so I had to dig into the code turn the check off.
> 

Sigh. Please don't. That makes a short web script (eg a web advert) able
to hijack your proxy and use it as a base to hijack your whole network -
hiding the attacker while doing so.

There are details and some mitigations to reduce the pain listed at
<http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery>


>>>
>>> # IMPORTANT! squid requires at least one forward-proxy port configured
>>> #            http://wiki.squid-cache.org/KnowledgeBase/NoForwardProxyPorts
>>> http_port 0.0.0.0:3127
>>> http_port 0.0.0.0:3128 intercept
>>> https_port 0.0.0.0:3129 intercept ssl-bump
>>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>> cert=/etc/squid/ssl_certs/squid.pem
>>>
>>> sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/squid/ssl_db -M
>>> 4MB sslcrtd_children 8 startup=1 idle=1
>>> sslproxy_capath /etc/ssl/certs
>>>
>>> acl step1 at_step SslBump1
>>> ssl_bump peek step1
>>> ssl_bump bump all
>>
>> So what you have configured is Server-first bumping.
>>
>> All clients will be presented with the Privoxy SSL certificate as if
>> Privoxy (at 127.0.0.1:8118) was the authoritative web server for the
>> HTTPS website being fetched.
>>
>> "What could go wrong?" as the saying goes. A better question would be
>> what could possibly go _right_ in that setup. Very few websites will
>> work, and only where the TLS was completely broken in the first place.
> 
> Would better solution be client-first configuration where client would
> be presented with squid's self generated certificate, read the traffic
> and then send it to the actual destination through privoxy

That can be done by making the ssl_bump directive decide to bump on
step1. It still has all the same problems as the existing config, the
issues all center around the fact that the client is not presented with
anything that looks even remotely like the real servers certificate or
TLS options. So any TLS/SSL security the client may be using is useless.

> using CONNECT?

No Squid is currently able to do that. Once decrypted the traffic has to
go to an HTTPS server directly (ORIGINAL_DST) or to a proxy which is
connected to using a secure channel, ie. TLS/SSL.


>>
>>>
>>> As a result, the client receives ERR_CANNOT_FORWARD. Could someone
>>> point me to the right direction? Thank you.
>>
>> Your best hope is to recreate in squid.conf settings the privacy
>> operations you are using privoxy for. Then remove privoxy from the chain
>> of proxies.
> 
> I thought about this solution, but it seems that squid cannot use
> socks parent yet.

You should be able to send Squids outbound traffic through a regular
SOCKS tunnel/gateway if you need to. It is just configured at the OS
routing level rather than anything in squid.conf.

Amos