[squid-users] auth_param tls? limiting proxy access based on client TLS authentication

[Bob Rich]

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 at treenet.co.nz> 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.


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20201114/f3f5aff7/attachment.htm>