On 19/11/2015 12:42 a.m., Mohammad Asif wrote: > hi > > I am using this particular version of squid. > > [root@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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
