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