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

[Alex Rousskov]

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.