[squid-users] Using subordinate CA for SSL Bump

[Amos Jeffries]

On 15/12/2015 10:26 a.m., Yuri Voinov wrote:
> 
> Hi all.
> 
> Does anybody can tell me - is it possible to use subordinate secondary
> CA in squid for SSL Bumping purpose?
> 
> I.e., we have self-signed primary CA for issue subordinate CA,
> 
> subordinate CA we install in squid's setup,
> 
> primary CA certificate install to clients.
> 
> For example.
> 
> For mimicking we'll using subordinate CA, and, in case of subordinate
> key forgery, we can use primary CA to revoke subordinate CA and re-issue
> them without total replacement primary CA on clients.
> 
> This will seriously increase bumping security procedure, hm?
> 
> I've tried this scheme with 3.5.11, but without success.

I suspect its not going to work in the current releases. The more I look
at this part of the SSL code the more twisted it appears to be.

There are multiple code paths loading certs in different orders for
different features and traffic types. I have been trying to clean up
those code paths recently, but it is all still a bit tangled to even see
which one is handling what type of traffic.

AFAICT (so far) both the bumping and reverse-proxy code loads
Intermediary certs if they are listed in the cert= PEM file after the
cert Squid is using for either signing-cert or as server-cert. Some
other code path is loading them from cafile=, it looks like its the main
SSL code but I've not yet found how that code path actually happens (grr).

With all that looking hopeful, and the certs identified as the secondary
chain being attached (everything except the firstprimary/signing cert).
I'm not actually finding anywhere sending the actual signing certificate
itself during the bumping steps. So Squid may be horribly sending
all-but-one of the certs needed, on the assumption that the signing cert
is itself installed on the client.

Amos