[squid-users] Squid Version 3.5.20 Any Ideas

[Amos Jeffries]

On 20/07/17 09:10, Yuri wrote:
> Aha,
> 
> 
> 20.07.2017 3:04, Cherukuri, Naresh пишет:
>>
>> Yuri,
>>
>> I am sorry I didn’t get you I already installed certificate on all 
>> clients(trusted root certificate authorities). You want me install 
>> proxy public key also on clients, if so were should I put the proxy 
>> public key. Below is my squid.conf file.
>>
>> Squid.conf
>>
>> key=/etc/squid/pctysquid2sslcerts/pctysquid2prod.pkey \ proxy ca 
>> public key??
>>
> This is proxy private key AFAIK.

Correct. It should be the proxy private key. If the public key is put in 
there and startup actually succeeds I'm not sure what broken runtime 
errors will occur - nothing good anyhow.

Also, note that cert= parameter should be configured *before* the key= 
parameter so Squid loads them from the right place. The very latest 
releases (v4+) will fail to start if the ordering is wrong, so best to 
prepare for that now.


I suspect that part of the problem here is what is being configured in 
that cert= parameter. For SSL-Bump ports in current Squid it needs to 
contains the self-signed *CA* certificate that Squid is using to 
generate other certs from, the key= being the private key of that CA cert.

If you generate a regular proxy cert and load it there (like normal 
proxy cert= would use) the bumping process will get all broken.


The ConfigExample page Yuri linked to earlier had the exact and full 
process to follow for setting up the multiple different certs, keys and 
file types involved with SSL-Bump.


>>
>> cert=/etc/squid/pctysquid2sslcerts/pctysquid2prod.crt \(installed 
>> certificate on IE all clients as a trusted root certificate authorities)
>>
> Yes, if it installed into clients - this is ok.
> 
> So. The only reason I can see - proxy can't see OpenSSL CA's bundle.
> 
> To make it work you should add to your squid's config one of this:
> 
> #  TAG: sslproxy_cafile
> #    file containing CA certificates to use when verifying server
> #    certificates while proxying https:// URLs
> #Default:
> # none
> 
> #  TAG: sslproxy_capath
> #    directory containing CA certificates to use when verifying
> #    server certificates while proxying https:// URLs
> #Default:
> # none

Er, those are for Squid->server connections. You were correct about the 
errors referring to client->Squid connections, so these are irrelevant.

If anything, the  cafile= parameter of the ssl-bump port might be 
needed. Then it should point at the same CA's found in the cert= 
parameter (bit weird, but that is bugs in the SSL-Bump config design).

FTR: those particular errors occur when Squid accepts a connection from 
a client, begins the TLS handshake and the client suddenly disconnects 
before the handshake is complete.
  The "certificate unknown" seems to be saying that either 1) the client 
sent a client-cert to Squid and OpenSSL did not accept it, or 2) that 
the client did not accept the auto-generated cert Squid sent.

If (1) is happening it s because the browser was not correctly 
configured with the self-signed CA public cert.

If (2) is happening, then probably the cert=, key=, cafile= parameters 
on the ssl-bump port are not configured right, OR browser was not 
correctly configured with the self-signed CA public cert.

Or, maybe bugs in that particular Squid release SSL-Bump code. We are 
constantly fixing them and 3.5.20 is now a whole year behind with 
SSL-Bump fixes - many of them rather major behaviour fixes.


==> Best Practice to follow with SSL-Bump is that when having *any* 
problems with the SSL-Bump process try the latest Squid release first 
before spending time trying to figure it out.

Amos