<div dir="ltr">Unfortunately the peeking only logs the fqdn and no subdirectories, which doesnt meet our logging requirements for security :(.  It sounds like there isn't a way to have squid do both currently, I do appreciate the information though!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 28, 2021 at 12:40 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/27/21 6:23 PM, Justin Cook wrote:<br>
> In this case we're not looking to authenticate the user themselves with<br>
> the squid server but with the destination web server, does that change<br>
> the scope?<br>
<br>
* If you do need to bump TLS connections:<br>
<br>
Yes, certificate authentication with an origin server is a different<br>
problem. If Squid does not possess the client certificate key, then<br>
Squid cannot both bump the TLS client connection (i.e. become the client<br>
from the origin server point of view) and keep the old client from the<br>
origin server point of view.<br>
<br>
In this case, this is not a technical limitation of the current Squid<br>
implementation like "TLS inside TLS"; it is a protocol-level conflict<br>
that no implementation can resolve. TLS design makes<br>
faking/impersonating the authenticating client impossible without<br>
leaking the client key to the proxy.<br>
<br>
If you can refactor so that the origin server trusts Squid instead of<br>
the client, and Squid authenticates the TLS client, then we will be back<br>
to the earlier "TLS inside TLS" problem (not to mention client<br>
changes/complications), so this kind of refactoring is unlikely to be<br>
the right way forward.<br>
<br>
<br>
* If you only need to peek at TLS connections:<br>
<br>
You should be able to keep client certificate authentication. If Squid<br>
cannot keep that while peeking at the TLS client or the origin server,<br>
then there is a Squid bug somewhere.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
<br>
> On Tue, Apr 27, 2021 at 10:57 AM Alex Rousskov wrote:<br>
> <br>
>     On 4/27/21 1:33 PM, Justin Cook wrote:<br>
>     > We are running into a situation where we are unable to fully<br>
>     > authenticate our users to an internal tooling service that requires<br>
>     > certificate authentication as part of its login process, when going<br>
>     > through squid forward proxy with SSL bump enabled.<br>
> <br>
>     SslBump does not support "TLS inside TLS" configurations, which is what<br>
>     you get when you combine certificate-based proxy authentication (which<br>
>     requires an https_port working in a forward proxy mode) with SslBump<br>
>     (which, for an https_port, currently requires an interception proxy<br>
>     mode).<br>
> <br>
>     It is possible to add support for "TLS inside TLS", but it requires a<br>
>     serious development effort.<br>
> <br>
>     <a href="https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F</a><br>
> <br>
> <br>
>     HTH,<br>
> <br>
>     Alex.<br>
> <br>
<br>
</blockquote></div>