On 1/14/21 2:41 PM, Sergey Maslyakov wrote: > Is the CONNECT tunnel designed in a way that enables it to "enrich" the > outgoing connection with mTLS authentication? If, by "designed", you are asking about HTTP protocol design, then the CONNECT tunnel is a blind TCP tunnel by that design. Hence, by design, a proxy dealing with CONNECT tunnels does not assume they are related to TLS. Squid SslBump feature allows the admin to disregard the general design principles above and interpret the CONNECT tunnel bytes as TLS. Usually, when folks ask about "enriching" TLS, they talk about SslBump. It is not yet clear to me whether you need SslBump. Neither Squid nor any other proxy can enrich a client TLS connection. TLS is designed to protect from such fiddling by proxies. I suspect that what you need is for Squid to use mTLS when forwarding a client request to the origin server. This is supported in principle, but the devil is in the details. > My destination server requires mTLS authentication of the client. I have > a valid key-cert pair and I can successfully execute a "curl" command to > fetch a document from that server using the key-cert pair at hand. Squid supports mTLS authentication with HTTPS cache_peers (including origin servers) via the cache_peers sslcert option. > I want to put Squid between my clients (Maven, Gradle, Docker Engine, > etc) and the server so that clients would be configured to use the > instance of Squid as an HTTPS proxy but would not have to be configured > with the mTLS key-cert pair. 1. "HTTPS proxy" is a proxy that accepts TLS connections opened by clients that want to explicitly ask that proxy to forward their request to some origin server. I suspect that is not what you meant by "HTTPS proxy". Whether there are CONNECT requests in this case depends on the client, but all popular clients I know about do send CONNECT requests inside that secure TLS connection to the proxy (unfortunately). For those clients, SslBump is required. 2. It is possible that you are talking about an HTTPS surrogate or HTTPS reverse proxy/accelerator. In this configuration, clients talk to Squid thinking that Squid is an HTTPS origin server. There are no CONNECT requests in this case. Clients receive Squid certificates. No SslBump. 3. If you meant that Squid should intercept/hijack client TCP connections to HTTPS origin servers, then it is a third kind of configuration. There are no CONNECT requests in this case. Clients receive Squid certificates. SslBump is required. 4. If you meant that Squid, as a regular HTTP forward proxy, should hijack client CONNECT tunnels to HTTPS origin servers, then it is a yet another kind of configuration. There are CONNECT requests in this case. Clients receive Squid certificates. SslBump is required. Each scenario above would present its own Squid challenges. Please clarify what you are dealing with. > Here is how I see it: > Maven --- (HTTPS/CONNECT) ---> Squid (stores my mTLS key-cert pair) --- > (mTLS/SSL) ---> Server > Is this doable within Squid architecture? The "HTTPS/CONNECT" part can be misinterpreted as any of the four cases above. Please clarify what it means to you. If this is all too overwhelming, we can start with a simple question: Do your clients establish TCP connections to a Squid port (cases 1, 2, 4)? Or do they open TCP connections to origin servers instead (case 3)? Cheers, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
