auth_param tls? limiting proxy access based on client TLS authentication

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

auth_param tls? limiting proxy access based on client TLS authentication

Bob Rich
Hi folks,

Apologies if this is a faq or has treatment elsewhere but I can't find it.

I've got squid configured as an old-school explicit forward proxy.  

I would like to limit access through the proxy to only those clients that authenticate either to an HTTPS proxy listener or via client auth injected into a CONNECT request to the origin server.  Please note that in this use case the origin server is not expecting TLS auth in any way.  This is just being used initially to prevent unauthenticated clients from using the proxy.

Ideally we would be able to base access control on information derived from subject DN or other attributes in the certificate, but I'm just aiming for basic functionality right now.

I built 4.13 locally on Ubuntu and as far as I can tell all of the other SSL features are working (ssl_bump, generate-host-certificates, etc)

Thanks in advance for any advice!



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: auth_param tls? limiting proxy access based on client TLS authentication

Amos Jeffries
Administrator
On 14/11/20 8:30 am, Bob Rich wrote:

>
> I've got squid configured as an old-school explicit forward proxy.
>
> I would like to limit access through the proxy to only those clients
> that authenticate either to an HTTPS proxy listener or via client auth
> injected into a CONNECT request to the origin server.  Please note that
> in this use case the origin server is not expecting TLS auth in any
> way.  This is just being used initially to prevent unauthenticated
> clients from using the proxy.
>

You seem to have been confused by the presence of TLS / HTTPS.

 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>


To a regular forward-proxy a CONNECT request is an instruction to open a
TCP tunnel to the origin. There is no way to pass authentication
credentials in a TCP SYN packet. So the origin will not be aware of
*which* client authenticated.

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.



> Ideally we would be able to base access control on information derived
> from subject DN or other attributes in the certificate, but I'm just
> aiming for basic functionality right now.
>

That requires a completely different design for the proxy architecture.
One which has no relation to HTTP authentication at all.


If you really want this TLS certification to be the primary access for
clients I think it better to concentrate on getting that design working,
then add any HTTP auth as a backup later.



> I built 4.13 locally on Ubuntu and as far as I can tell all of the other
> SSL features are working (ssl_bump, generate-host-certificates, etc)
>
> Thanks in advance for any advice!
>


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: auth_param tls? limiting proxy access based on client TLS authentication

Alex Rousskov
On 11/14/20 1:53 PM, Bob Rich wrote:

> 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.

Yes, this is how certificate-based authentication is usually done with
Squid. There are large Squid deployments using this mechanism. It is
also the most secure method of using a proxy...

    https_port 3443 clientca=auth.pem tls-cert=squid.pem ...

The biggest problem with this approach is being able to configure
clients to use an HTTPS proxy (as opposed to using an HTTP proxy for
HTTPS traffic). Popular browsers support HTTPS proxies (but may require
PAC-based configuration to enable that support[1]). Many clients do not
support HTTPS proxies.

[1] Look for "HTTPS proxy" at
https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file

Please note that one cannot combine SslBump and certificate-based client
authentication on the same port (yet?).

BTW, the other two options for certificate-based authentication that you
were thinking about will not work out of the box, for various reasons.


HTH,

Alex.


> 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users