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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
