On Mon, 1 Feb 2010 09:14:57 -0500, Damon Miller <dmiller@xxxxxxxxxxxxxxx>
wrote:
> Hello again. I apologize for the duplicate topic but I've hit a dead
end.
> I'm hoping that a simpler question will be easier to answer so here
goes:
>
> Is it possible to transparently proxy TLS traffic through Squid when the
> target server requires a client-side certificate for authentication?
>
Theoretically possible. But very hard to the point of impossible for the
currently released Squid.
>
> This works as expected when Squid is operating in non-transparent mode.
> When I switch to transparent mode, however, Squid doesn't request a
> certificate from the client and as a result the server-side handshake
> fails.
> (Standard SSL traffic flows correctly after I accept the name mismatch
> complaints from the browser.)
A little protocol knowledge is needed to understand why...
In regular mode a browser needing HTTPS sends a special CONNECT request to
the proxy which basically opens a binary tunnel. The browser and server
then just shunt the SSL bits back and forward inside the tunnel.
In interception mode ('transparent' proxy) the browser is not aware of the
proxy at all so just opens a TCP link and shunts the SSL bits down it. The
proxy in the middle is forced to break the encryption and re-encrypt it
going out to the server again. It uses it's own client certificate to do
the re-encryption to the server, and also its own server certificate to
respond to the client encryption details. Thus both client and server
become aware that something is happening in the middle.
>
> I've tried to understand the handshake process but I can't determine if
> it's
> possible to transparently proxy this or if Squid just doesn't support it
at
> the moment. Specifically, it seems that CertificateVerify requires the
> client to sign a message to show it possesses the private key associated
> with the provided certificate. This doesn't seem inconsistent with
> transparent proxying, as Squid could simply impersonate the target
server,
> collect the signature from the client, and relay it back to the server.
Or
> am I missing something obvious?
In theory yes.
In practice SSL includes unique details wrapped inside the encryption for
validation of the TCP link itself. The proxy needs to generate a valid
certificate for it's different TCP links to pass validation. This is not
possible with any of the publicly available releases of Squid.
Other than that little speed bump your thinking is correct.
NP: Dynamic cert code is available in experimental form for Squid-3.2 if
you want to assist testing it.
Amos
