[squid-users] Mutual Authentication Support

Amos Jeffries squid3 at treenet.co.nz
Wed Nov 18 23:48:44 UTC 2015


On 19/11/2015 12:42 a.m., Mohammad Asif wrote:
> hi
> 
> I am using this particular version of squid.
> 
> [root at squidpc ~]# squid -v
> Squid Cache: Version 2.5.STABLE14
> 

Ouch. Please seriously consider an upgrade. That version is ~10 years
old and does not perform even a handful of modern HTTP protocol needs.
It also has dozens of known security vulnerabilities that cannot and
will not ever be fixed.

Also, when dealing with TLS you will need a current release. Today that
is 3.5.11 or 4.0.2 (beta).

> Purpose:
> Squid is configured to act like a https proxy for some servers like
> Certificate Authority(CA), Device Management Systems(DMS).
> Client which wants to communicate with CA or DMS would initiate SSL
> connection. SSL connection terminates on Squid.

Okay. This is reverse-proxy / CDN. Absolute minimum Squid version for
properly functioning reverse-proxy is Squid-2.6.


> Squid is configured to communicate with DMS or CA on the behalf of client.
> 
> As part SSL connection authentication mechanism, Squid is sending its
> certificate, which is authenticated by the client which is preloaded with
> the root certificate(issuer of squid certificate).
> So, my query is how to configure mutual authentication where squid asks the
> certificate from the client and authenticates it ?
> 

The answer to your specific question is easy. Upgrade to a current Squid
and use the clientca= parameter on the https_port.


However, the overall design that you describe trying to achieve is not
possible.

TLS simply does not work that way. The connection from the device/client
is terminated (*terminated*) on entry to Squid. That includes the
validity of the client certificate, if Squid were to try to use that
certificate on its own outgoign connection the certificate would be
*invalid* in TLS terms.

Squid is a *different* client; different hardware, different software,
differetnt TLS connection, different TLS context, different TLS session,
... --> different client certificate.

Things are not completely hopeless though. There is a Certificate
authentication scheme being designed for use in HTTP. Where a end-client
certificate is sent in the HTTP WWW-Auth security credentials. Squid is
already perfectly capable of relaying that at the HTTP level to the
backend servers.

Amos


More information about the squid-users mailing list