[squid-dev] [RFC] removal of http(s)_port clientca= parameter

[Amos Jeffries]

While converting the TLS/SSL context initialization code into generic
Security:: API operations I have run into the clientca= parameter.

It appears to perform identical CA loading operations to cafile=
parameter. But also stores the CA details in Squid memory, with no
apparent need to do so.

Different from cafile= currently it turns on TLS client authentication
options.

First Bug : This is not obvious from the documentation which states that
cafile= is the parameter for loading CA used in client cert
authentication, whereas clientca= is just "additional CA" to be used.
IIRC there has been some user confusion over the use of these two
options in the past.

Only when both are used at once does client certificate authentication
appear to work as documented. I suspect that OpenSSL is doing some form
of opportunistic client certificate authentication using cafile=
contents *if* the client spontaneously sends a cert. If not then
configuring cafile= is useless.

Second Bug : when cafile= is not set and clientca= is set clientca= gets
loaded twice and added to the context twice. Loaded from file into
memory as a batch, then from file to context as a batch, then copied one
at a time from memory to context. Causing a much larger than necessary
memory footprint for listening ports.



I believe we should do the following:

* Add a new option "tls-require-client-auth" to turn on the client
certificatate verification / authentication actions.
 - This could be a sslflags= value, but I plan to turn those into
individual flag parameters later. So avoiding adding new ones right now.

* Remove clientca=. The config "clientca=/foo" would now be equivalent
to "cafile=/foo tls-require-client-auth" and treated as such by
back-compat code.


PS. The glaring oddity is that all this storing of CA and CRL lists in
memory is happening on the listening ports which change contexts rarely.
Ideal memory optimization would do it for outgoing server connections
where contexts are generated as-needed. But that code is continuously
loading its CA/CRL lists from files.

Amos