[squid-users] Proxy client certificate authentication rewritten to username/password authentication

Tue Oct 9 20:58:40 UTC 2018

Hi, Alex!

Thank you for your very kind and intelligent reply!

The origin server does not request any certificates from the client. We can instruct the clients to use the proxy directly, if terminating traffic directly in Squid can easen the implementation.

Furthermore, commenting your additons (>):

> * IIRC, X509 certificates do not contain user names and passwords, at least not in HTTP authentication sense. Where should Squid get the user name and password to add to the URL?

The general idea is to have a table in Squid (or make accessible such a table from elsewhere) with a number of usernames and passwords, that would match certain placeholders in the startup URL issued by the clients  that would easily and uniquely match a certain pattern, such as

https://www.service4us.com/ login/dologin.php?username=usernameplaceholder1&password=passwordplaceholder1 for iPad 1
Here, the username- and password placeholder 1 would of course be replaced with the proper usernames and passwords looked up in the aforementioned table before being handed over to the origin server.

> If you detail whether your TLS clients know about Squid existence (i.e. connect to/through Squid),

That would be possible.

> whether your clients are regular browsers (or custom software you control), 

This would probably be the standard managed browser on iPads, that is, Safari with policies. They could in theory be anything, but manageability would normally dictate a managed browser.

> and whether your origin servers request client certificates
Nope! :-)

> , then it may be possible to determine whether what you want is or can be supported. To detail your setup, consider describing what happens at TCP, TLS, and HTTP layers between a typical client, Squid, and origin server in your environment.

We will indeed do a more thorough inspection of how the traffic is performed on the different levels, and ask the origin server vendor for assistance.

Once again - thank you for your very kind and insightful help!

Arnt Richard Rørvik
Senior engineer
Dept. of IT
Section of strategy and governance
Norwegian university of Science and Technology (NTNU), https://www.ntnu.edu/ 
7491 Trondheim
Norway

SfB-address: sip:arnt.r.rorvik at ntnu.no
Phone.: +47 73 55 91 67/ Mobile: +47 957 01 081
https://www.ntnu.no/ansatte/arnt.r.rorvik
https://no.linkedin.com/in/arrorvik 
https://www.youracclaim.com/badges/eaae291f-c686-4e84-b48d-96fa01a37401

-----Opprinnelig melding-----
Fra: Alex Rousskov <rousskov at measurement-factory.com> 
Sendt: 9. oktober 2018 22:26
Til: squid-users at lists.squid-cache.org; Arnt Richard Rørvik <arnt.r.rorvik at ntnu.no>
Emne: Re: [squid-users] Proxy client certificate authentication rewritten to username/password authentication

On 10/09/2018 01:39 PM, Arnt Richard Rørvik wrote:

> Can the Squid web proxy be used to request and verify the machine 
> certificate of workstations trying to initiate a session towards a 
> given web server (outside Squid),

Yes if by "machine certificate" you mean an X509 certificate that TLS servers can request from TLS clients. Squid supports TLS client certificate request/validation.

Please note that if Squid requests that certificate, then the TLS connection has to be between the client and Squid, not between the client and the origin server. It is impossible for Squid to request a client certificate on a TLS connection that Squid does not participate in (beyond shoveling TCP payload bytes).

If the origin server itself requests a TLS client certificate, then, in theory, Squid can inspect the certificate returned by the client.
However, I doubt such requested-by-origin TLS client certificate inspection works out of the box, and it usually would not make sense in common deployments (because Squid would not have access to the validating CA used to sign the client certificate), but it is technically possible to extract that client certificate from a client-origin connection IIRC -- it is not encrypted -- and validate it against known-to-Squid CAs.

> and, rewrite this session initiation on the way out (towards the the 
> given web server),

If you want Squid to request the certificate, then the TLS connection has to be between the client and Squid. If needed, Squid will open a TLS connection to the origin server. The two TLS connections are unrelated from TLS point of view.

> adding a username and password in the URL.

Yes, if client sends plain text requests to Squid, or if Squid bumps encrypted client requests. However:

* TLS client certificate validation is currently not fully compatible with TLS client connection bumping (i.e. SslBump) IIRC.

* When dealing with secure origin servers, popular browsers will not send plain text requests to Squid (i.e. "GET https://example.com").
Instead, they will want to establish dumb CONNECT tunnels through Squid.
Those tunnels do not expose HTTP request URLs (unless Squid bumps them).

* IIRC, X509 certificates do not contain user names and passwords, at least not in HTTP authentication sense. Where should Squid get the user name and password to add to the URL?

* Rewriting URLs requires using a url_rewrite_program helper or an ICAP/eCAP service.

In summary, various pieces of what you want are supported, but it is unclear what combination of those pieces would be applicable to your exact use case. Most likely, the combination you want is not and cannot be supported.

If you detail whether your TLS clients know about Squid existence (i.e.
connect to/through Squid), whether your clients are regular browsers (or custom software you control), and whether your origin servers request client certificates, then it may be possible to determine whether what you want is or can be supported. To detail your setup, consider describing what happens at TCP, TLS, and HTTP layers between a typical client, Squid, and origin server in your environment.

HTH,

Alex.