I applied patch to trunk as r14428.
I used the sslproxy_foreign_intermediate_certs name.

I hope that we will have soon the final solution so this parameter will be a minor parameter.

I will update the bugzilla and I will post here the squid-3.5 patch in the case someone want to use it.

Regards,
   Christos

On 12/02/2015 05:53 PM, Alex Rousskov wrote:
On 12/01/2015 10:18 PM, Amos Jeffries wrote:
On 2/12/2015 6:08 a.m., Alex Rousskov wrote:
On 12/01/2015 04:38 AM, Amos Jeffries wrote:
Nod. "untrusted" is not exactly a clear name to anyone unfamiliar with
the internals of OpenSSL. To the rest of the world (including Squid's
usage) these are "intermediate certificates". So calling it
"sslproxy_intermediate_certs" might be clearer to admin than untrusted.


Agreed. On the other hand, the proxy itself may need send its own
intermediate certificates (for regular https_port connections, when
_not_ doing SslBump) so some admins will try to stuff those proxy
intermediate certificates here.


AFAICS, "sslproxy_" directive set are all consistently scoped as being
for configuring the outgoing server connections (specifically DIRECT
ones, not cache_peer).

The equivalent https_port intermediate certificates are probably best
loaded as multiple certificates from the cert= file. That seems to be
where admin are first attempting to putting them already.


My argument is that if we add a directive called
sslproxy_intermediate_certs, many admins are likely to attempt to put
intermediate https_port certificates there because it will look like a
good fit to them, _despite_ the facts you cite. Many will focus on the
"intermediate_cert" part and block out the other signals you mentioned.

This naming issue is not important to me. If you think
sslproxy_intermediate_certs is better than
sslproxy_untrusted_intermediate_certs or
sslproxy_foreign_intermediate_certs, then let's use
sslproxy_intermediate_certs.

Otherwise, let Christos pick the best out of those three names.


Thank you,

Alex.

_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev

Reply via email to