Thanks for the reply Amos.
Couple of quick points
1 - Nothing exists today aside from a little prototyping environment, so anything that's possible is still in play.
2 - The CA issuing the client certificates and any signing certificates for the proxy is internal. Just to reinforce, the web applications that the clients intend to access have no knowledge of the CA or requirement for client certificate authentication.
Stating the goal possibly in another way, only clients that possess this internally issued client certificate should be able to connect to a web application through the proxy. If the client does not have a certificate, there is no requirement around whether or not it can connect to the proxy and issue requests...the only requirement is that any requests to connect to applications on the other side of the proxy fail.
On Fri, Nov 13, 2020 at 10:33 PM Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
From your description it appears that the clients are talking to Squid
using HTTP. Any authentication they send to Squid has to be using HTTP
Authentication. Which is validated by the auth_param helper and
proxy_auth ACL type.
<https://wiki.squid-cache.org/Features/Authentication>
Agree, this seems to be a non-starter for the reasons you describe. We do not wish to use HTTP authorization headers if it can be avoided.
However, the way you described your requirement implies that the origin
does not need the credentials anyway. It is only the proxy which cares
about auth to decide whether to relay or block a client.
This is correct.
To me there are only a few options for introducing TLS client certificate authentication.
1 - Run TLS on the proxy listener. This would use https_port directive and would require that we are able to configure the proxy to mandate client certificates before allowing the connection to complete. Clients with no/invalid certificates wouldn't even get to the point where they can send a request to the proxy.
2 - Use ssl-bump functionality to modify the TLS handshake that occurs after a CONNECT request to require a valid client certificate before completing the request. No idea if this is possible.
3 - Use either of the above to establish the mutually authenticated TLS context and then surface that information through ICAP to offload the authorization decision.
I've been able to get ssl-bump working to generate custom certs and I have Squid talking to c-icap. I haven't successfully got Squid to prompt the client to authenticate and I still have quite a bit of learning to do on the ICAP side.
Thanks in advance for any steers (including 'this is a terrible idea' of course :)
Lastly I haven't used gmail with a mailing list before. Let me know if i've stomping on some etiquette.
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
