Mutual TLS for the upstream example

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Mutual TLS for the upstream example

Sergey Maslyakov
Folks,

Is the CONNECT tunnel designed in a way that enables it to "enrich" the outgoing connection with mTLS authentication? "tls_outgoing_options" does not seem to work the way I was hoping it does.

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.

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.

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?

I got it working using NGINX with some minor hiccups and I was hoping I can do it more elegantly with Squid.


Thank you,
/Sergey

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Mutual TLS for the upstream example

Eliezer Croitoru-3

I don’t know about Squid but I assume varnish has this feature:

https://docs.varnish-software.com/varnish-cache-plus/features/backend-ssl/

 

If you just need a GW without caching it should work as expected.

 

Eliezer

 

----

Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: [hidden email]

Zoom: Coming soon

 

 

From: squid-users <[hidden email]> On Behalf Of Sergey Maslyakov
Sent: Thursday, January 14, 2021 9:41 PM
To: [hidden email]
Subject: [squid-users] Mutual TLS for the upstream example

 

Folks,

 

Is the CONNECT tunnel designed in a way that enables it to "enrich" the outgoing connection with mTLS authentication? "tls_outgoing_options" does not seem to work the way I was hoping it does.

 

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.

 

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.

 

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?

 

I got it working using NGINX with some minor hiccups and I was hoping I can do it more elegantly with Squid.

 

 

Thank you,

/Sergey


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Mutual TLS for the upstream example

Alex Rousskov
In reply to this post by Sergey Maslyakov
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Mutual TLS for the upstream example

Sergey Maslyakov
Thank you for the very detailed explanation, Alex!

Having looked at the sequence diagram of the mTLS handshake, I now see why I cannot get what I want.

I can either get plain-text HTTP to mTLS-secured forwarding, or I have to have two independent legs of communication when the authenticity of client-to-Squid connection is ensured using its (Squid's) own key-cert pair, which is different from authentication credentials of the handshake between Squid and my target server.

I cannot afford to have unencrypted the client-to-Squid leg, otherwise, I could do it in a single "socat" invocation.

I don't have the server key-cert pair, which makes the sslbump impractical too.

In NGINX, I implemented the reverse proxy model (option 2 on your list), when the proxy terminated SSL with its own cert, received the request, rewrote some headers, and forwarded it over an mTLS-secured connection. The problem is that under some circumstances I also need to rewrite the body of the HTTP request and this was taking the whole solution to a whole new level of complexity...

I guess I need to start looking into automation that would allow me to manage mTLS configuration of clients at scale instead of trying to defeat the whole purpose of the mTLS integrity mechanism :)

On Thu, Jan 14, 2021 at 2:42 PM Alex Rousskov <[hidden email]> wrote:
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Mutual TLS for the upstream example

Sergey Maslyakov
In reply to this post by Eliezer Croitoru-3
Thank you, Eliezer! I will look into it but it appears that the underlying problem is not solvable by design of the mTLS handshake... There are corner cases that can be solved but not the original issue.


On Thu, Jan 14, 2021 at 2:39 PM Eliezer Croitoru <[hidden email]> wrote:

I don’t know about Squid but I assume varnish has this feature:

https://docs.varnish-software.com/varnish-cache-plus/features/backend-ssl/

 

If you just need a GW without caching it should work as expected.

 

Eliezer

 

----

Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: [hidden email]

Zoom: Coming soon

 

 

From: squid-users <[hidden email]> On Behalf Of Sergey Maslyakov
Sent: Thursday, January 14, 2021 9:41 PM
To: [hidden email]
Subject: [squid-users] Mutual TLS for the upstream example

 

Folks,

 

Is the CONNECT tunnel designed in a way that enables it to "enrich" the outgoing connection with mTLS authentication? "tls_outgoing_options" does not seem to work the way I was hoping it does.

 

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.

 

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.

 

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?

 

I got it working using NGINX with some minor hiccups and I was hoping I can do it more elegantly with Squid.

 

 

Thank you,

/Sergey


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Mutual TLS for the upstream example

Eliezer Croitoru-3

Can we try to understand the issue again?

 

In this setup, should squid know about the client certificate and pass it to the service  backend

Or maybe just terminate the clients certificate?

 

I am not sure I understood what you need/want to do with squid.

 

Eliezer

 

----

Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: [hidden email]

Zoom: Coming soon

 

 

From: Sergey Maslyakov <[hidden email]>
Sent: Friday, January 15, 2021 1:38 AM
To: Eliezer Croitoru <[hidden email]>
Cc: [hidden email]
Subject: Re: [squid-users] Mutual TLS for the upstream example

 

Thank you, Eliezer! I will look into it but it appears that the underlying problem is not solvable by design of the mTLS handshake... There are corner cases that can be solved but not the original issue.

 

 

On Thu, Jan 14, 2021 at 2:39 PM Eliezer Croitoru <[hidden email]> wrote:

I don’t know about Squid but I assume varnish has this feature:

https://docs.varnish-software.com/varnish-cache-plus/features/backend-ssl/

 

If you just need a GW without caching it should work as expected.

 

Eliezer

 

----

Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: [hidden email]

Zoom: Coming soon

 

 

From: squid-users <[hidden email]> On Behalf Of Sergey Maslyakov
Sent: Thursday, January 14, 2021 9:41 PM
To: [hidden email]
Subject: [squid-users] Mutual TLS for the upstream example

 

Folks,

 

Is the CONNECT tunnel designed in a way that enables it to "enrich" the outgoing connection with mTLS authentication? "tls_outgoing_options" does not seem to work the way I was hoping it does.

 

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.

 

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.

 

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?

 

I got it working using NGINX with some minor hiccups and I was hoping I can do it more elegantly with Squid.

 

 

Thank you,

/Sergey


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Mutual TLS for the upstream example

Alex Rousskov
In reply to this post by Sergey Maslyakov
On 1/14/21 6:36 PM, Sergey Maslyakov wrote:

> I can either get plain-text HTTP to mTLS-secured forwarding, or I have
> to have two independent legs of communication when the authenticity of
> client-to-Squid connection is ensured using its (Squid's) own key-cert
> pair, which is different from authentication credentials of the
> handshake between Squid and my target server.

I doubt you can simply do plain-text HTTP to the proxy in this case
(without SslBump) even if you were OK with the risks because most
clients will not send "GET https://" requests to the proxy. They will
send CONNECT requests instead. The proxy would have to decrypt their
CONNECT tunnels with SslBump in order to add mTLS.

Thus, the second part of your summary essentially covers all practical
cases, including reverse proxy and SslBump-based ones.


> I don't have the server key-cert pair, which makes the
> sslbump impractical too.

FYI: SslBump is meant for cases where you do _not_ have the origin
server key. Squid generates/fakes server certificates and signs them
with its own CA key. The clients have to be configured to trust that CA
key. It is not a "nice" solution by any means, but, sometimes, it is the
best one available.


> In NGINX, I implemented the reverse proxy model (option 2 on your list),
> when the proxy terminated SSL with its own cert, received the request,
> rewrote some headers, and forwarded it over an mTLS-secured connection.
> The problem is that under some circumstances I also need to rewrite the
> body of the HTTP request and this was taking the whole solution to a
> whole new level of complexity...

FWIW, Squid should be able to do that as well. Body rewrites are
supported via eCAP/ICAP adaptations, but the result will be quite
complex indeed! Technically, this setup is pretty much as (in)secure as
a setup based on SslBump -- it is based on you securing the client-proxy
leg with your own certificate and forcing the clients to trust your
certificate.


Cheers,

Alex.


> On Thu, Jan 14, 2021 at 2:42 PM Alex Rousskov wrote:
>
>     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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users