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

[Alex Rousskov]

On 10/09/2018 02:58 PM, Arnt Richard Rørvik wrote:

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

OK, I will assume that your clients will explicitly talk to the proxy
using TLS. In that case, certificate-based client authentication by
Squid should work OK.


> 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

Understood. From Squid (and TLS and HTTP) point of view, this URL
rewriting will have nothing to do with usernames and passwords then.

Your custom URL rewriting helper or adaptation service, not Squid, will
contain all the placeholder substitution logic and will access the
tables that drive those substitutions. This separation from Squid is
actually a good thing in most cases.

For more about Squid adaptation interfaces, see
https://wiki.squid-cache.org/SquidFaq/ContentAdaptation


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

You will need to check whether your target browser(s) support:

1. HTTPS proxies: Establishing a TLS connection to the proxy and then
sending HTTP traffic, including CONNECT requests for secure sites inside
that TLS connection to the proxy. FireFox and Chrome (semi-secretly)
support HTTPS proxies, but I do not know much about Safari.

2. Certificate-based proxy authentication: Supplying a client
certificate when requested by the proxy on the other end of the
client-proxy TLS connection described in #1.

If both #1 and #2 are supported, then what you want is

* fairly easy for HTTP origin servers and

* currently unsupported for HTTPS origin servers (but can be supported
by enhancing SslBump to bump TLS-inside-TLS).


Please note that if you want to rewrite URLs of secure web sites (e.g.,
"https://example.com/"), then you will be fighting an increasingly
uphill battle with modern browsers, even if Squid can do (or can be
enhanced to do) what you want. In many cases, an overall better solution
in that case is to rewrite those secure URLs inside the browser instead,
even though that approach often requires instrumenting several browsers
that increasingly resist instrumentation (i.e. another uphill battle
with popular browsers!).


HTH,

Alex.