<div dir="ltr"><div dir="ltr">Thanks for the reply Amos.<div><br></div><div>Couple of quick points</div><div><br></div><div>1 - Nothing exists today aside from a little prototyping environment, so anything that's possible is still in play.</div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 13, 2020 at 10:33 PM Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> From your description it appears that the clients are talking to Squid <br>
using HTTP. Any authentication they send to Squid has to be using HTTP <br>
Authentication. Which is validated by the auth_param helper and <br>
proxy_auth ACL type.<br>
  <<a href="https://wiki.squid-cache.org/Features/Authentication" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/Authentication</a>><br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">However, the way you described your requirement implies that the origin <br>
does not need the credentials anyway. It is only the proxy which cares <br>
about auth to decide whether to relay or block a client.<br></blockquote><div><br></div><div>This is correct.  </div><div><br></div><div>To me there are only a few options for introducing TLS client certificate authentication.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks in advance for any steers (including 'this is a terrible idea' of course :)</div><div><br></div><div>Lastly I haven't used gmail with a mailing list before.  Let me know if i've stomping on some etiquette.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>