Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

Thank you Amos and Rafael,

Using the LinuxDnat approach worked great as well.

On Sat, Sep 30, 2023 at 5:18 AM Amos Jeffries  wrote:

> On 30/09/23 11:06, Fernando Giorgetti wrote:
> > If someone has already done that, with the client running in a different
> > machine, I would love to know how.
>
>
> There are several ways;
>
>   1) run Squid on the gateway router for your network, or
>
>   2) place Squid in a DMZ between the LAN gateway and WAN gateway.
>
>   3) setup a custom route+gateway for port 80 and 443 LAN traffic as the
> Squid machine. Excluding traffic from that machine itself.
>
>
> >
> > In case Squid runs on the same machine used as a network gateway to the
> > client machine, I suppose the config would be similar, but if it's not
> > running on the same machine used as the gateway, then it would be nice
> > to see how.
> >
>
> That would be (1). See
>  for
> how to configure the gateway router running Squid.
>
> The configuration difference between the at-source (aka, on client
> machine) you are/were using is just some iptables rules.
>
>
> HTH
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TLS passthrough

[Amos Jeffries]

On 30/09/23 11:06, Fernando Giorgetti wrote:
If someone has already done that, with the client running in a different 
machine, I would love to know how.



There are several ways;

 1) run Squid on the gateway router for your network, or

 2) place Squid in a DMZ between the LAN gateway and WAN gateway.

 3) setup a custom route+gateway for port 80 and 443 LAN traffic as the 
Squid machine. Excluding traffic from that machine itself.





In case Squid runs on the same machine used as a network gateway to the 
client machine, I suppose the config would be similar, but if it's not 
running on the same machine used as the gateway, then it would be nice 
to see how.




That would be (1). See 
 for 
how to configure the gateway router running Squid.


The configuration difference between the at-source (aka, on client 
machine) you are/were using is just some iptables rules.



HTH
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TLS passthrough

[Rafael Akchurin]

Helo Fendando,

One way to do that is to use policy-based-routing on your gateway.

This can be easily done with for example Microtik (see 
https://docs.diladele.com/tutorials/mikrotik_transparent_squid/index.html)
But also with native say Debian (we only have somewhat outdated tutorial with 
Debian 10/Ubuntu 20 at  
https://docs.diladele.com/tutorials/policy_based_routing_squid/index.html).

Hope this will help.
Best regards,
Rafael

From: squid-users  On Behalf Of 
Fernando Giorgetti
Sent: Saturday, September 30, 2023 12:07 AM
To: Alex Rousskov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] TLS passthrough

If someone has already done that, with the client running in a different 
machine, I would love to know how.

In case Squid runs on the same machine used as a network gateway to the client 
machine, I suppose the config would be similar, but if it's not running on the 
same machine used as the gateway, then it would be nice to see how.

Thanks

Em sex., 29 de set. de 2023 18:13, Alex Rousskov 
mailto:rouss...@measurement-factory.com>> 
escreveu:
On 2023-09-29 13:55, Fernando Giorgetti wrote:

> The "intercept" scenario demonstrated here
> https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource
> makes sense to me, as we are just redirecting internal traffic into Squid,
> so the original destination IP is preserved.

> I was able to make it work and that TLS app worked just fine. The
> only constraint is that it requires that both the client and Squid
> ran on the same machine, but at least it worked perfectly.

I am very glad you are making progress. FWIW, there are also ways to
intercept traffic from applications that do not run on the same machine
as Squid. This is not my area of expertise, but others on the list can
guide you if you need that kind of setup.


> Here is my squid.conf (just in case someone eventually has a similar
> issue):

Thank you!

Alex.



> acl CONNECT method CONNECT
> acl mytlsserverip dst 10.0.0.10
> http_access allow CONNECT mytlsserverip
>
> http_port 3128
>
> https_port 127.0.0.1:3129<http://127.0.0.1:3129> intercept ssl-bump \
>tls-cert=/tmp/certs/squid.pem \
>tls-key=/tmp/certs/squid.key \
>generate-host-certificates=off
>
> ssl_bump splice all
>
>
> And here are the firewall rules I have used:
>
> iptables -t nat -I OUTPUT -p tcp -d 10.0.0.10 --dport 55671 -j DNAT
> --to-destination 127.0.0.1:3129<http://127.0.0.1:3129> <http://127.0.0.1:3129>
> iptables -t nat -I OUTPUT --match owner --uid-owner squid  -p tcp -d
> 10.0.0.10 --dport 55671 -j ACCEPT
>
> I appreciate all the guidance and discussion Matus and Alex.
>
> Thank you,
> Fernando
>
> On Fri, Sep 29, 2023 at 12:53 PM Alex Rousskov
> mailto:rouss...@measurement-factory.com>
> <mailto:rouss...@measurement-factory.com<mailto:rouss...@measurement-factory.com>>>
>  wrote:
>
> On 2023-09-29 10:55, Fernando Giorgetti wrote:
>  > Do you control the client application? If yes, then perhaps
> it can be
>  > adjusted to support HTTP proxies? In other words, the client
> will send a
>  > plain text HTTP CONNECT request to Squid and, upon receiving
> a 200
>  > (Connection Established) response headers, will start using
> TLS with the
>  > origin server. In this case, you do not need interception.
>
>
>  > Nope, the client application is also used to communicate with
> other apps in
>  > other environments.
>
> FWIW, "used with other apps" does not imply or explain the "nope, we do
> not control the application" answer IMHO.
>
>
>  > The SNI has to be used as the client/server apps perform
>  > mutual TLS authentication.
>
> To avoid a misunderstanding, nothing I have said precludes the use of
> TLS SNI by the client application. Thus, I am not sure why you are
> saying the above.
>
>
>  > In order to evaluate if we can use Squid for this purpose, I have
>  > also created a basic TLS client/server app to validate what is
>  > happening. Basically my TLS client tries to connect directly to Squid
>  > IP/Port and I am indicating the SNI so that the TLS handshake
>  > passes.
>
> FWIW, a scenario where the client application establishes a TLS
> connection with Squid https_port (configured as a reverse HTTPS proxy)
> will not work for your use case AFAICT. I am not sure why you are
> testing this. It has not been suggested on this mailing list.
>
> BTW, you can use ("curl" or even "openssl s_client") and "openssl
> s_server" for basic tests. I recommend using wel

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

If someone has already done that, with the client running in a different
machine, I would love to know how.

In case Squid runs on the same machine used as a network gateway to the
client machine, I suppose the config would be similar, but if it's not
running on the same machine used as the gateway, then it would be nice to
see how.

Thanks

Em sex., 29 de set. de 2023 18:13, Alex Rousskov <
rouss...@measurement-factory.com> escreveu:

> On 2023-09-29 13:55, Fernando Giorgetti wrote:
>
> > The "intercept" scenario demonstrated here
> > https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource
> > makes sense to me, as we are just redirecting internal traffic into
> Squid,
> > so the original destination IP is preserved.
>
> > I was able to make it work and that TLS app worked just fine. The
> > only constraint is that it requires that both the client and Squid
> > ran on the same machine, but at least it worked perfectly.
>
> I am very glad you are making progress. FWIW, there are also ways to
> intercept traffic from applications that do not run on the same machine
> as Squid. This is not my area of expertise, but others on the list can
> guide you if you need that kind of setup.
>
>
> > Here is my squid.conf (just in case someone eventually has a similar
> > issue):
>
> Thank you!
>
> Alex.
>
>
>
> > acl CONNECT method CONNECT
> > acl mytlsserverip dst 10.0.0.10
> > http_access allow CONNECT mytlsserverip
> >
> > http_port 3128
> >
> > https_port 127.0.0.1:3129 intercept ssl-bump \
> >tls-cert=/tmp/certs/squid.pem \
> >tls-key=/tmp/certs/squid.key \
> >generate-host-certificates=off
> >
> > ssl_bump splice all
> >
> >
> > And here are the firewall rules I have used:
> >
> > iptables -t nat -I OUTPUT -p tcp -d 10.0.0.10 --dport 55671 -j DNAT
> > --to-destination 127.0.0.1:3129 
> > iptables -t nat -I OUTPUT --match owner --uid-owner squid  -p tcp -d
> > 10.0.0.10 --dport 55671 -j ACCEPT
> >
> > I appreciate all the guidance and discussion Matus and Alex.
> >
> > Thank you,
> > Fernando
> >
> > On Fri, Sep 29, 2023 at 12:53 PM Alex Rousskov
> >  > > wrote:
> >
> > On 2023-09-29 10:55, Fernando Giorgetti wrote:
> >  > Do you control the client application? If yes, then perhaps
> > it can be
> >  > adjusted to support HTTP proxies? In other words, the client
> > will send a
> >  > plain text HTTP CONNECT request to Squid and, upon receiving
> > a 200
> >  > (Connection Established) response headers, will start using
> > TLS with the
> >  > origin server. In this case, you do not need interception.
> >
> >
> >  > Nope, the client application is also used to communicate with
> > other apps in
> >  > other environments.
> >
> > FWIW, "used with other apps" does not imply or explain the "nope, we
> do
> > not control the application" answer IMHO.
> >
> >
> >  > The SNI has to be used as the client/server apps perform
> >  > mutual TLS authentication.
> >
> > To avoid a misunderstanding, nothing I have said precludes the use of
> > TLS SNI by the client application. Thus, I am not sure why you are
> > saying the above.
> >
> >
> >  > In order to evaluate if we can use Squid for this purpose, I have
> >  > also created a basic TLS client/server app to validate what is
> >  > happening. Basically my TLS client tries to connect directly to
> Squid
> >  > IP/Port and I am indicating the SNI so that the TLS handshake
> >  > passes.
> >
> > FWIW, a scenario where the client application establishes a TLS
> > connection with Squid https_port (configured as a reverse HTTPS
> proxy)
> > will not work for your use case AFAICT. I am not sure why you are
> > testing this. It has not been suggested on this mailing list.
> >
> > BTW, you can use ("curl" or even "openssl s_client") and "openssl
> > s_server" for basic tests. I recommend using well-known test programs
> > (instead of custom apps) because doing so makes it easier for mailing
> > list readers to understand what your test clients and servers are
> doing
> > (and to reproduce your setup).
> >
> >
> >  > When I tried to make it work using a forward proxy with intercept
> and
> >  > ssl_bump, I could not make Squid peek at the SNI and tunnel the
> >  > request to the correct destination.
> >
> > Please note that "forward proxy with intercept" is an oxymoron -- the
> > two port modes (i.e. explicit "intercept" and default forward
> proxying)
> > are mutually exclusive.
> >
> > If you do not want to or cannot modify/configure the client
> application
> > to use Squid as a forward HTTP proxy (as I detailed earlier; see the
> > paragraph still quoted at the beginning of this message), then your
> > other choice is interception (as I detailed earlier; see the "Squid
> > supports blind tunneling of 

Re: [squid-users] TLS passthrough

[Alex Rousskov]

On 2023-09-29 13:55, Fernando Giorgetti wrote:

The "intercept" scenario demonstrated here 
https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource 
makes sense to me, as we are just redirecting internal traffic into Squid,

so the original destination IP is preserved.



I was able to make it work and that TLS app worked just fine. The
only constraint is that it requires that both the client and Squid
ran on the same machine, but at least it worked perfectly.


I am very glad you are making progress. FWIW, there are also ways to 
intercept traffic from applications that do not run on the same machine 
as Squid. This is not my area of expertise, but others on the list can 
guide you if you need that kind of setup.




Here is my squid.conf (just in case someone eventually has a similar
issue):


Thank you!

Alex.




acl CONNECT method CONNECT
acl mytlsserverip dst 10.0.0.10
http_access allow CONNECT mytlsserverip

http_port 3128

https_port 127.0.0.1:3129 intercept ssl-bump \
   tls-cert=/tmp/certs/squid.pem \
   tls-key=/tmp/certs/squid.key \
   generate-host-certificates=off

ssl_bump splice all


And here are the firewall rules I have used:

iptables -t nat -I OUTPUT -p tcp -d 10.0.0.10 --dport 55671 -j DNAT 
--to-destination 127.0.0.1:3129 
iptables -t nat -I OUTPUT --match owner --uid-owner squid  -p tcp -d 
10.0.0.10 --dport 55671 -j ACCEPT


I appreciate all the guidance and discussion Matus and Alex.

Thank you,
Fernando

On Fri, Sep 29, 2023 at 12:53 PM Alex Rousskov 
> wrote:


On 2023-09-29 10:55, Fernando Giorgetti wrote:
 >     Do you control the client application? If yes, then perhaps
it can be
 >     adjusted to support HTTP proxies? In other words, the client
will send a
 >     plain text HTTP CONNECT request to Squid and, upon receiving
a 200
 >     (Connection Established) response headers, will start using
TLS with the
 >     origin server. In this case, you do not need interception.


 > Nope, the client application is also used to communicate with
other apps in
 > other environments.

FWIW, "used with other apps" does not imply or explain the "nope, we do
not control the application" answer IMHO.


 > The SNI has to be used as the client/server apps perform
 > mutual TLS authentication.

To avoid a misunderstanding, nothing I have said precludes the use of
TLS SNI by the client application. Thus, I am not sure why you are
saying the above.


 > In order to evaluate if we can use Squid for this purpose, I have
 > also created a basic TLS client/server app to validate what is
 > happening. Basically my TLS client tries to connect directly to Squid
 > IP/Port and I am indicating the SNI so that the TLS handshake
 > passes.

FWIW, a scenario where the client application establishes a TLS
connection with Squid https_port (configured as a reverse HTTPS proxy)
will not work for your use case AFAICT. I am not sure why you are
testing this. It has not been suggested on this mailing list.

BTW, you can use ("curl" or even "openssl s_client") and "openssl
s_server" for basic tests. I recommend using well-known test programs
(instead of custom apps) because doing so makes it easier for mailing
list readers to understand what your test clients and servers are doing
(and to reproduce your setup).


 > When I tried to make it work using a forward proxy with intercept and
 > ssl_bump, I could not make Squid peek at the SNI and tunnel the
 > request to the correct destination.

Please note that "forward proxy with intercept" is an oxymoron -- the
two port modes (i.e. explicit "intercept" and default forward proxying)
are mutually exclusive.

If you do not want to or cannot modify/configure the client application
to use Squid as a forward HTTP proxy (as I detailed earlier; see the
paragraph still quoted at the beginning of this message), then your
other choice is interception (as I detailed earlier; see the "Squid
supports blind tunneling of intercepted TCP connections" discussion in
the previous exchange).

When Squid https_port gets an intercepted client TCP connection, Squid
does not need SNI to know where to forward that TCP connection. Squid
opens a TCP connection to the IP address where the client TCP
connection
was going (or trying to go) before it was intercepted. That intended
destination IP address is delivered to Squid by the OS, as a part of
interception mechanism/setup. TLS and SNI are not involved in this
process.

If you have not tested an interception scenario, please do. If you
have,
please share your interception configuration, Squid configuration, and
any relevant error/problem information.


HTH,

Alex.


 > On Fri, Sep 29, 2023 at 11:35 AM Alex Rousskov wrote:
 >
   

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

Alex,

Sorry for my misconceptions in my previous email.

The "intercept" scenario demonstrated here
https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource
makes sense to me, as we are just redirecting internal traffic into Squid,
so the original destination IP is preserved.

I was able to make it work and that TLS app (which I have no control at
all),
worked just fine. The only constraint is that it requires that both the
client and
Squid ran on the same machine, but at least it worked perfectly.

Here is my squid.conf (just in case someone eventually has a similar issue):

acl CONNECT method CONNECT
acl mytlsserverip dst 10.0.0.10
http_access allow CONNECT mytlsserverip

http_port 3128

https_port 127.0.0.1:3129 intercept ssl-bump \
  tls-cert=/tmp/certs/squid.pem \
  tls-key=/tmp/certs/squid.key \
  generate-host-certificates=off

ssl_bump splice all


And here are the firewall rules I have used:

iptables -t nat -I OUTPUT -p tcp -d 10.0.0.10 --dport 55671 -j DNAT
--to-destination 127.0.0.1:3129
iptables -t nat -I OUTPUT --match owner --uid-owner squid  -p tcp -d
10.0.0.10 --dport 55671 -j ACCEPT

I appreciate all the guidance and discussion Matus and Alex.

Thank you,
Fernando

On Fri, Sep 29, 2023 at 12:53 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2023-09-29 10:55, Fernando Giorgetti wrote:
> > Do you control the client application? If yes, then perhaps it can be
> > adjusted to support HTTP proxies? In other words, the client will
> send a
> > plain text HTTP CONNECT request to Squid and, upon receiving a 200
> > (Connection Established) response headers, will start using TLS with
> the
> > origin server. In this case, you do not need interception.
>
>
> > Nope, the client application is also used to communicate with other apps
> in
> > other environments.
>
> FWIW, "used with other apps" does not imply or explain the "nope, we do
> not control the application" answer IMHO.
>
>
> > The SNI has to be used as the client/server apps perform
> > mutual TLS authentication.
>
> To avoid a misunderstanding, nothing I have said precludes the use of
> TLS SNI by the client application. Thus, I am not sure why you are
> saying the above.
>
>
> > In order to evaluate if we can use Squid for this purpose, I have
> > also created a basic TLS client/server app to validate what is
> > happening. Basically my TLS client tries to connect directly to Squid
> > IP/Port and I am indicating the SNI so that the TLS handshake
> > passes.
>
> FWIW, a scenario where the client application establishes a TLS
> connection with Squid https_port (configured as a reverse HTTPS proxy)
> will not work for your use case AFAICT. I am not sure why you are
> testing this. It has not been suggested on this mailing list.
>
> BTW, you can use ("curl" or even "openssl s_client") and "openssl
> s_server" for basic tests. I recommend using well-known test programs
> (instead of custom apps) because doing so makes it easier for mailing
> list readers to understand what your test clients and servers are doing
> (and to reproduce your setup).
>
>
> > When I tried to make it work using a forward proxy with intercept and
> > ssl_bump, I could not make Squid peek at the SNI and tunnel the
> > request to the correct destination.
>
> Please note that "forward proxy with intercept" is an oxymoron -- the
> two port modes (i.e. explicit "intercept" and default forward proxying)
> are mutually exclusive.
>
> If you do not want to or cannot modify/configure the client application
> to use Squid as a forward HTTP proxy (as I detailed earlier; see the
> paragraph still quoted at the beginning of this message), then your
> other choice is interception (as I detailed earlier; see the "Squid
> supports blind tunneling of intercepted TCP connections" discussion in
> the previous exchange).
>
> When Squid https_port gets an intercepted client TCP connection, Squid
> does not need SNI to know where to forward that TCP connection. Squid
> opens a TCP connection to the IP address where the client TCP connection
> was going (or trying to go) before it was intercepted. That intended
> destination IP address is delivered to Squid by the OS, as a part of
> interception mechanism/setup. TLS and SNI are not involved in this process.
>
> If you have not tested an interception scenario, please do. If you have,
> please share your interception configuration, Squid configuration, and
> any relevant error/problem information.
>
>
> HTH,
>
> Alex.
>
>
> > On Fri, Sep 29, 2023 at 11:35 AM Alex Rousskov wrote:
> >
> > On 2023-09-29 09:17, Fernando Giorgetti wrote:
> >
> >  > Actually I am evaluating if Squid can be used to proxy
> Non-HTTP/TLS
> >  > data, as we have a restricted environment where Squid is
> > currently the
> >  > only way to get out to the internet.
> >
> > Yes, Squid can tunnel non-HTTP data, including TLS data.
> >
> >
> >  > The idea is that the client application will open a con

Re: [squid-users] TLS passthrough

[Alex Rousskov]

On 2023-09-29 10:55, Fernando Giorgetti wrote:

Do you control the client application? If yes, then perhaps it can be
adjusted to support HTTP proxies? In other words, the client will send a
plain text HTTP CONNECT request to Squid and, upon receiving a 200
(Connection Established) response headers, will start using TLS with the
origin server. In this case, you do not need interception.




Nope, the client application is also used to communicate with other apps in
other environments. 


FWIW, "used with other apps" does not imply or explain the "nope, we do 
not control the application" answer IMHO.




The SNI has to be used as the client/server apps perform
mutual TLS authentication.


To avoid a misunderstanding, nothing I have said precludes the use of 
TLS SNI by the client application. Thus, I am not sure why you are 
saying the above.




In order to evaluate if we can use Squid for this purpose, I have
also created a basic TLS client/server app to validate what is
happening. Basically my TLS client tries to connect directly to Squid
IP/Port and I am indicating the SNI so that the TLS handshake
passes.


FWIW, a scenario where the client application establishes a TLS 
connection with Squid https_port (configured as a reverse HTTPS proxy) 
will not work for your use case AFAICT. I am not sure why you are 
testing this. It has not been suggested on this mailing list.


BTW, you can use ("curl" or even "openssl s_client") and "openssl 
s_server" for basic tests. I recommend using well-known test programs 
(instead of custom apps) because doing so makes it easier for mailing 
list readers to understand what your test clients and servers are doing 
(and to reproduce your setup).




When I tried to make it work using a forward proxy with intercept and
ssl_bump, I could not make Squid peek at the SNI and tunnel the
request to the correct destination.


Please note that "forward proxy with intercept" is an oxymoron -- the 
two port modes (i.e. explicit "intercept" and default forward proxying) 
are mutually exclusive.


If you do not want to or cannot modify/configure the client application 
to use Squid as a forward HTTP proxy (as I detailed earlier; see the 
paragraph still quoted at the beginning of this message), then your 
other choice is interception (as I detailed earlier; see the "Squid 
supports blind tunneling of intercepted TCP connections" discussion in 
the previous exchange).


When Squid https_port gets an intercepted client TCP connection, Squid 
does not need SNI to know where to forward that TCP connection. Squid 
opens a TCP connection to the IP address where the client TCP connection 
was going (or trying to go) before it was intercepted. That intended 
destination IP address is delivered to Squid by the OS, as a part of 
interception mechanism/setup. TLS and SNI are not involved in this process.


If you have not tested an interception scenario, please do. If you have, 
please share your interception configuration, Squid configuration, and 
any relevant error/problem information.



HTH,

Alex.



On Fri, Sep 29, 2023 at 11:35 AM Alex Rousskov wrote:

On 2023-09-29 09:17, Fernando Giorgetti wrote:

 > Actually I am evaluating if Squid can be used to proxy Non-HTTP/TLS
 > data, as we have a restricted environment where Squid is
currently the
 > only way to get out to the internet.

Yes, Squid can tunnel non-HTTP data, including TLS data.


 > The idea is that the client application will open a connection to
a given
 > hostname and port (setting the SNI in the TLS options),
considering that
 > the given hostname/port is the actual backend they're trying to
reach.

Do you control the client application? If yes, then perhaps it can be
adjusted to support HTTP proxies? In other words, the client will
send a
plain text HTTP CONNECT request to Squid and, upon receiving a 200
(Connection Established) response headers, will start using TLS with
the
origin server. In this case, you do not need interception.


 > We can either try to use a fake hostname (defined in the
/etc/hosts of the
 > tls client machine) which would actually point to Squid's IP

AFAICT, faking the IP address will not work without Squid source code
modifications because a non-intercepting Squid https_port will want to
terminate TLS -- such a port does not support blindly tunneling traffic.


 > or eventually
 > redirect traffic to the real destination into Squid using a DNAT
rule.

I am not a DNAT expert, but this sounds like interception to me. Bugs
notwithstanding, Squid supports blind tunneling of intercepted TCP
connections (to their intended destination):

      https_port X intercept ssl-bump ...
      ssl_bump splice all

On a successful tunneling path, the above configuration does not care
whether the intercepted traffic is TLS and will not peek at TLS SNI,
 

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

>
> Do you control the client application? If yes, then perhaps it can be
> adjusted to support HTTP proxies? In other words, the client will send a
> plain text HTTP CONNECT request to Squid and, upon receiving a 200
> (Connection Established) response headers, will start using TLS with the
> origin server. In this case, you do not need interception.


Nope, the client application is also used to communicate with other apps in
other environments. The SNI has to be used as the client/server apps perform
mutual TLS authentication.

In other words, the client will send a
> plain text HTTP CONNECT request to Squid and, upon receiving a 200
> (Connection Established) response headers, will start using TLS with the
> origin server. In this case, you do not need interception.


In order to evaluate if we can use Squid for this purpose, I have also
created a
basic TLS client/server app to validate what is happening. Basically my TLS
client
tries to connect directly to Squid IP/Port and I am indicating the SNI so
that the
TLS handshake passes.

Using a reverse I was able to make it reach the TLS server after faking a
CONNECT
request. But without a fake CONNECT or a valid HTTP request it failed.

When I tried to make it work using a forward proxy with intercept and
ssl_bump, I
could not make Squid peek at the SNI and tunnel the request to the correct
destination.

Fernando

On Fri, Sep 29, 2023 at 11:35 AM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2023-09-29 09:17, Fernando Giorgetti wrote:
>
> > Actually I am evaluating if Squid can be used to proxy Non-HTTP/TLS
> > data, as we have a restricted environment where Squid is currently the
> > only way to get out to the internet.
>
> Yes, Squid can tunnel non-HTTP data, including TLS data.
>
>
> > The idea is that the client application will open a connection to a given
> > hostname and port (setting the SNI in the TLS options), considering that
> > the given hostname/port is the actual backend they're trying to reach.
>
> Do you control the client application? If yes, then perhaps it can be
> adjusted to support HTTP proxies? In other words, the client will send a
> plain text HTTP CONNECT request to Squid and, upon receiving a 200
> (Connection Established) response headers, will start using TLS with the
> origin server. In this case, you do not need interception.
>
>
> > We can either try to use a fake hostname (defined in the /etc/hosts of
> the
> > tls client machine) which would actually point to Squid's IP
>
> AFAICT, faking the IP address will not work without Squid source code
> modifications because a non-intercepting Squid https_port will want to
> terminate TLS -- such a port does not support blindly tunneling traffic.
>
>
> > or eventually
> > redirect traffic to the real destination into Squid using a DNAT rule.
>
> I am not a DNAT expert, but this sounds like interception to me. Bugs
> notwithstanding, Squid supports blind tunneling of intercepted TCP
> connections (to their intended destination):
>
>  https_port X intercept ssl-bump ...
>  ssl_bump splice all
>
> On a successful tunneling path, the above configuration does not care
> whether the intercepted traffic is TLS and will not peek at TLS SNI, but
> nothing in your requirements necessitates SNI knowledge AFAICT.
>
> If Squid fails to establish a TCP connection to the intended destination
> of the intercepted connection, then the situation becomes more complex:
> Squid (with the above configuration) assumes that the client is speaking
> TLS. Squid will attempt to bump the TLS client connection and send a
> Squid-generated HTTP error response to the client. AFAIK, this bumping
> and error sending attempt cannot be prevented in this case without Squid
> source code modifications: Squid used to be able to terminate a
> client-Squid connection instead of sending a Squid-generated HTTP error
> response (by replacing the corresponding Squid error page contents with
> a word "reset"). However, that feature was accidentally(?) dropped in
> 2002 commit 76cdc28 AFAICT.
>
>
> HTH,
>
> Alex.
>
>
> > But overall, it will be a 1:1 relationship, meaning, the https_port on
> Squid
> > would be used exclusively to this purpose of proxying from a given source
> > to a given destination.
> >
> > That is why I was considering a reverse-proxy, but I had no luck with it
> > (actually
> > I was able to proxy HTTP/HTTPS, but not non-http).
> >
> > Thank you again,
> > Fernando
> >
> > On Thu, Sep 28, 2023 at 11:39 PM Alex Rousskov
> >  > > wrote:
> >
> > On 2023-09-28 20:35, Fernando Giorgetti wrote:
> >
> >  > Do you have any recommendations on how I could have it done?
> >
> > I am unable to confirm whether Squid can do what you want or provide
> > configuration recommendations because I do not yet know how your
> Squid
> > will receive traffic (e.g., an intercepting proxy or an explicit
> > forward
> > HTTP proxy), what

Re: [squid-users] TLS passthrough

[Alex Rousskov]

On 2023-09-29 09:17, Fernando Giorgetti wrote:


Actually I am evaluating if Squid can be used to proxy Non-HTTP/TLS
data, as we have a restricted environment where Squid is currently the
only way to get out to the internet.


Yes, Squid can tunnel non-HTTP data, including TLS data.



The idea is that the client application will open a connection to a given
hostname and port (setting the SNI in the TLS options), considering that
the given hostname/port is the actual backend they're trying to reach.


Do you control the client application? If yes, then perhaps it can be 
adjusted to support HTTP proxies? In other words, the client will send a 
plain text HTTP CONNECT request to Squid and, upon receiving a 200 
(Connection Established) response headers, will start using TLS with the 
origin server. In this case, you do not need interception.




We can either try to use a fake hostname (defined in the /etc/hosts of the
tls client machine) which would actually point to Squid's IP 


AFAICT, faking the IP address will not work without Squid source code 
modifications because a non-intercepting Squid https_port will want to 
terminate TLS -- such a port does not support blindly tunneling traffic.




or eventually
redirect traffic to the real destination into Squid using a DNAT rule.


I am not a DNAT expert, but this sounds like interception to me. Bugs 
notwithstanding, Squid supports blind tunneling of intercepted TCP 
connections (to their intended destination):


https_port X intercept ssl-bump ...
ssl_bump splice all

On a successful tunneling path, the above configuration does not care 
whether the intercepted traffic is TLS and will not peek at TLS SNI, but 
nothing in your requirements necessitates SNI knowledge AFAICT.


If Squid fails to establish a TCP connection to the intended destination 
of the intercepted connection, then the situation becomes more complex: 
Squid (with the above configuration) assumes that the client is speaking 
TLS. Squid will attempt to bump the TLS client connection and send a 
Squid-generated HTTP error response to the client. AFAIK, this bumping 
and error sending attempt cannot be prevented in this case without Squid 
source code modifications: Squid used to be able to terminate a 
client-Squid connection instead of sending a Squid-generated HTTP error 
response (by replacing the corresponding Squid error page contents with 
a word "reset"). However, that feature was accidentally(?) dropped in 
2002 commit 76cdc28 AFAICT.



HTH,

Alex.



But overall, it will be a 1:1 relationship, meaning, the https_port on Squid
would be used exclusively to this purpose of proxying from a given source
to a given destination.

That is why I was considering a reverse-proxy, but I had no luck with it 
(actually

I was able to proxy HTTP/HTTPS, but not non-http).

Thank you again,
Fernando

On Thu, Sep 28, 2023 at 11:39 PM Alex Rousskov 
> wrote:


On 2023-09-28 20:35, Fernando Giorgetti wrote:

 > Do you have any recommendations on how I could have it done?

I am unable to confirm whether Squid can do what you want or provide
configuration recommendations because I do not yet know how your Squid
will receive traffic (e.g., an intercepting proxy or an explicit
forward
HTTP proxy), what traffic Squid will receive (e.g., TLS, plain HTTP,
something else), and what you want Squid to do with that traffic.

To make progress, I recommend describing the above details (for one
typical use case?) and then answering any followup questions.


Cheers,

Alex.


 > When my tls client tries to reach the target through Squid, using
 > a "ssl_bump splice", it seems like squid is trying to reach
itself in a
 > loop.
 >
 > I have also tried including a peek first, but no luck.
 >
 > Thanks again for all suggestions.
 >
 > On Thu, Sep 28, 2023 at 7:23 PM Alex Rousskov wrote:
 >
 >     On 2023-09-28 15:23, Fernando Giorgetti wrote:
 >
 >      > Actually with the suggested blind passthrough, Squid would not
 >     handle
 >      > the TLS termination.
 >
 >     Correct.
 >
 >
 >      > how will Squid know what the target is?
 >
 >     In many cases, Squid can learn SNI by peeking at TLS ClientHello,
 >     without terminating TLS. Bugs notwithstanding, none of the
 >     configuration
 >     sketches I shared previously will do that though.
 >
 >
 >     HTH,
 >
 >     Alex.
 >
 >
 >
 >      > On Thu, Sep 28, 2023 at 1:02 PM Alex Rousskov wrote:
 >      >
 >      >     On 2023-09-28 11:31, Fernando Giorgetti wrote:
 >      >
 >      >      > And what should I do to let Squid use the SNI
defined by
 >     the TLS
 >      >     client?
 >      >
 >      >     What do you want Squid to use that SNI for?
 >      >
 >      >     Alex.
   

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

Hello Alex,

First of all, thanks for your attention and time.

Actually I am evaluating if Squid can be used to proxy Non-HTTP/TLS
data, as we have a restricted environment where Squid is currently the
only way to get out to the internet.

The idea is that the client application will open a connection to a given
hostname and port (setting the SNI in the TLS options), considering that
the given hostname/port is the actual backend they're trying to reach.

We can either try to use a fake hostname (defined in the /etc/hosts of the
tls client machine) which would actually point to Squid's IP or eventually
redirect traffic to the real destination into Squid using a DNAT rule.

But overall, it will be a 1:1 relationship, meaning, the https_port on Squid
would be used exclusively to this purpose of proxying from a given source
to a given destination.

That is why I was considering a reverse-proxy, but I had no luck with it
(actually
I was able to proxy HTTP/HTTPS, but not non-http).

Thank you again,
Fernando

On Thu, Sep 28, 2023 at 11:39 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2023-09-28 20:35, Fernando Giorgetti wrote:
>
> > Do you have any recommendations on how I could have it done?
>
> I am unable to confirm whether Squid can do what you want or provide
> configuration recommendations because I do not yet know how your Squid
> will receive traffic (e.g., an intercepting proxy or an explicit forward
> HTTP proxy), what traffic Squid will receive (e.g., TLS, plain HTTP,
> something else), and what you want Squid to do with that traffic.
>
> To make progress, I recommend describing the above details (for one
> typical use case?) and then answering any followup questions.
>
>
> Cheers,
>
> Alex.
>
>
> > When my tls client tries to reach the target through Squid, using
> > a "ssl_bump splice", it seems like squid is trying to reach itself in a
> > loop.
> >
> > I have also tried including a peek first, but no luck.
> >
> > Thanks again for all suggestions.
> >
> > On Thu, Sep 28, 2023 at 7:23 PM Alex Rousskov wrote:
> >
> > On 2023-09-28 15:23, Fernando Giorgetti wrote:
> >
> >  > Actually with the suggested blind passthrough, Squid would not
> > handle
> >  > the TLS termination.
> >
> > Correct.
> >
> >
> >  > how will Squid know what the target is?
> >
> > In many cases, Squid can learn SNI by peeking at TLS ClientHello,
> > without terminating TLS. Bugs notwithstanding, none of the
> > configuration
> > sketches I shared previously will do that though.
> >
> >
> > HTH,
> >
> > Alex.
> >
> >
> >
> >  > On Thu, Sep 28, 2023 at 1:02 PM Alex Rousskov wrote:
> >  >
> >  > On 2023-09-28 11:31, Fernando Giorgetti wrote:
> >  >
> >  >  > And what should I do to let Squid use the SNI defined by
> > the TLS
> >  > client?
> >  >
> >  > What do you want Squid to use that SNI for?
> >  >
> >  > Alex.
> >  >
> >  >
> >  >  > On Thu, Sep 28, 2023 at 11:51 AM Alex Rousskov wrote:
> >  >  >
> >  >  > On 2023-09-28 09:06, Fernando Giorgetti wrote:
> >  >  >  > Hi Matus, do you mean something like a DNAT
> > (iptables) rule?
> >  >  >  > If so, I would say, it should work as well.
> >  >  >  >
> >  >  >  > But this is an environment I do not control, and I
> have
> >  > been told
> >  >  > to try
> >  >  >  > using an existing squid installation to proxy
> > non-http/TLS
> >  > data
> >  >  > through.
> >  >  >  >
> >  >  >  > I appreciate any guidance or recommendation.
> >  >  >
> >  >  >
> >  >  > Bugs notwithstanding, Squid can blindly tunnel
> intercepted
> >  > (at TCP port
> >  >  > X) TCP traffic to its intended destination:
> >  >  >
> >  >  >   https_port X intercept ssl-bump ...
> >  >  >   ssl_bump splice all
> >  >  >
> >  >  >
> >  >  > Without interception, then Squid can only tunnel stuff
> > inside
> >  > HTTP
> >  >  > CONNECT tunnels (for HTTP CONNECT requests received at
> TCP
> >  > port Y):
> >  >  >
> >  >  >   http_port Y ssl-bump ...
> >  >  >   ssl_bump splice all
> >  >  >
> >  >  >
> >  >  > In both cases, Squid does not care about the protocols
> > that
> >  > tunneled
> >  >  > traffic is using. It could be HTTP, HTTPS, TLS, or
> > anything
> >  > else on top
> >  >  > of TCP.
> >  >  >
> >  >  > Your ACLs may differ from "all" in the above sketches,
> > of course,
> >  >  > but if
> >  >  > traffic is not TLS, then you want an "ssl_bump splice"
> > rule that
> >  >  > matc

Re: [squid-users] TLS passthrough

[Alex Rousskov]

On 2023-09-28 20:35, Fernando Giorgetti wrote:


Do you have any recommendations on how I could have it done?


I am unable to confirm whether Squid can do what you want or provide 
configuration recommendations because I do not yet know how your Squid 
will receive traffic (e.g., an intercepting proxy or an explicit forward 
HTTP proxy), what traffic Squid will receive (e.g., TLS, plain HTTP, 
something else), and what you want Squid to do with that traffic.


To make progress, I recommend describing the above details (for one 
typical use case?) and then answering any followup questions.



Cheers,

Alex.



When my tls client tries to reach the target through Squid, using
a "ssl_bump splice", it seems like squid is trying to reach itself in a 
loop.


I have also tried including a peek first, but no luck.

Thanks again for all suggestions.

On Thu, Sep 28, 2023 at 7:23 PM Alex Rousskov wrote:

On 2023-09-28 15:23, Fernando Giorgetti wrote:

 > Actually with the suggested blind passthrough, Squid would not
handle
 > the TLS termination.

Correct.


 > how will Squid know what the target is?

In many cases, Squid can learn SNI by peeking at TLS ClientHello,
without terminating TLS. Bugs notwithstanding, none of the
configuration
sketches I shared previously will do that though.


HTH,

Alex.



 > On Thu, Sep 28, 2023 at 1:02 PM Alex Rousskov wrote:
 >
 >     On 2023-09-28 11:31, Fernando Giorgetti wrote:
 >
 >      > And what should I do to let Squid use the SNI defined by
the TLS
 >     client?
 >
 >     What do you want Squid to use that SNI for?
 >
 >     Alex.
 >
 >
 >      > On Thu, Sep 28, 2023 at 11:51 AM Alex Rousskov wrote:
 >      >
 >      >     On 2023-09-28 09:06, Fernando Giorgetti wrote:
 >      >      > Hi Matus, do you mean something like a DNAT
(iptables) rule?
 >      >      > If so, I would say, it should work as well.
 >      >      >
 >      >      > But this is an environment I do not control, and I have
 >     been told
 >      >     to try
 >      >      > using an existing squid installation to proxy
non-http/TLS
 >     data
 >      >     through.
 >      >      >
 >      >      > I appreciate any guidance or recommendation.
 >      >
 >      >
 >      >     Bugs notwithstanding, Squid can blindly tunnel intercepted
 >     (at TCP port
 >      >     X) TCP traffic to its intended destination:
 >      >
 >      >           https_port X intercept ssl-bump ...
 >      >           ssl_bump splice all
 >      >
 >      >
 >      >     Without interception, then Squid can only tunnel stuff
inside
 >     HTTP
 >      >     CONNECT tunnels (for HTTP CONNECT requests received at TCP
 >     port Y):
 >      >
 >      >           http_port Y ssl-bump ...
 >      >           ssl_bump splice all
 >      >
 >      >
 >      >     In both cases, Squid does not care about the protocols
that
 >     tunneled
 >      >     traffic is using. It could be HTTP, HTTPS, TLS, or
anything
 >     else on top
 >      >     of TCP.
 >      >
 >      >     Your ACLs may differ from "all" in the above sketches,
of course,
 >      >     but if
 >      >     traffic is not TLS, then you want an "ssl_bump splice"
rule that
 >      >     matches
 >      >     during SslBump step1. A rule with an "all" ACLs is the
 >     simplest example
 >      >     of that.
 >      >
 >      >
 >      >     HTH,
 >      >
 >      >     Alex.
 >      >     P.S. I am getting an "Internal Server Error" when
following
 >     the haproxy
 >      >     link in the original question, so I cannot map what
that page
 >     says to
 >      >     the configurations above.
 >      >
 >      >
 >      >      > On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR -
fantomas wrote:
 >      >      >
 >      >      >     On 27.09.23 16:48, Fernando Giorgetti wrote:
 >      >      >      >I would like to know if it is possible to set up
 >     Squid to
 >      >     perform
 >      >      >      >TLS passthrough to a given backend, relaying TLS
 >     encrypted
 >      >      >      >traffic to the backend, similarly to what HAProxy
 >     does below?
 >      >      >      >
 >      >      >
 >      >
 > 
 >https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough  > 

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

>
> Bugs notwithstanding, none of the configuration
> sketches I shared previously will do that though.


Do you have any recommendations on how I could have it done?
When my tls client tries to reach the target through Squid, using
a "ssl_bump splice", it seems like squid is trying to reach itself in a
loop.

I have also tried including a peek first, but no luck.

Thanks again for all suggestions.

On Thu, Sep 28, 2023 at 7:23 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2023-09-28 15:23, Fernando Giorgetti wrote:
>
> > Actually with the suggested blind passthrough, Squid would not handle
> > the TLS termination.
>
> Correct.
>
>
> > how will Squid know what the target is?
>
> In many cases, Squid can learn SNI by peeking at TLS ClientHello,
> without terminating TLS. Bugs notwithstanding, none of the configuration
> sketches I shared previously will do that though.
>
>
> HTH,
>
> Alex.
>
>
>
> > On Thu, Sep 28, 2023 at 1:02 PM Alex Rousskov wrote:
> >
> > On 2023-09-28 11:31, Fernando Giorgetti wrote:
> >
> >  > And what should I do to let Squid use the SNI defined by the TLS
> > client?
> >
> > What do you want Squid to use that SNI for?
> >
> > Alex.
> >
> >
> >  > On Thu, Sep 28, 2023 at 11:51 AM Alex Rousskov wrote:
> >  >
> >  > On 2023-09-28 09:06, Fernando Giorgetti wrote:
> >  >  > Hi Matus, do you mean something like a DNAT (iptables)
> rule?
> >  >  > If so, I would say, it should work as well.
> >  >  >
> >  >  > But this is an environment I do not control, and I have
> > been told
> >  > to try
> >  >  > using an existing squid installation to proxy non-http/TLS
> > data
> >  > through.
> >  >  >
> >  >  > I appreciate any guidance or recommendation.
> >  >
> >  >
> >  > Bugs notwithstanding, Squid can blindly tunnel intercepted
> > (at TCP port
> >  > X) TCP traffic to its intended destination:
> >  >
> >  >   https_port X intercept ssl-bump ...
> >  >   ssl_bump splice all
> >  >
> >  >
> >  > Without interception, then Squid can only tunnel stuff inside
> > HTTP
> >  > CONNECT tunnels (for HTTP CONNECT requests received at TCP
> > port Y):
> >  >
> >  >   http_port Y ssl-bump ...
> >  >   ssl_bump splice all
> >  >
> >  >
> >  > In both cases, Squid does not care about the protocols that
> > tunneled
> >  > traffic is using. It could be HTTP, HTTPS, TLS, or anything
> > else on top
> >  > of TCP.
> >  >
> >  > Your ACLs may differ from "all" in the above sketches, of
> course,
> >  > but if
> >  > traffic is not TLS, then you want an "ssl_bump splice" rule
> that
> >  > matches
> >  > during SslBump step1. A rule with an "all" ACLs is the
> > simplest example
> >  > of that.
> >  >
> >  >
> >  > HTH,
> >  >
> >  > Alex.
> >  > P.S. I am getting an "Internal Server Error" when following
> > the haproxy
> >  > link in the original question, so I cannot map what that page
> > says to
> >  > the configurations above.
> >  >
> >  >
> >  >  > On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas
> wrote:
> >  >  >
> >  >  > On 27.09.23 16:48, Fernando Giorgetti wrote:
> >  >  >  >I would like to know if it is possible to set up
> > Squid to
> >  > perform
> >  >  >  >TLS passthrough to a given backend, relaying TLS
> > encrypted
> >  >  >  >traffic to the backend, similarly to what HAProxy
> > does below?
> >  >  >  >
> >  >  >
> >  >
> >  >
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough>
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough>>
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough>
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> >>>
> >  >  >  >
> >  >  >  >I have tried a few different configurations using
> > reverse
> >  > proxy,
> >  >  >  >or peek and splice, but I could not make it work
> without
> >  > providing
> >  >  >  >a valid H

Re: [squid-users] TLS passthrough

[Alex Rousskov]

On 2023-09-28 15:23, Fernando Giorgetti wrote:

Actually with the suggested blind passthrough, Squid would not handle 
the TLS termination.


Correct.



how will Squid know what the target is?


In many cases, Squid can learn SNI by peeking at TLS ClientHello, 
without terminating TLS. Bugs notwithstanding, none of the configuration 
sketches I shared previously will do that though.



HTH,

Alex.




On Thu, Sep 28, 2023 at 1:02 PM Alex Rousskov wrote:

On 2023-09-28 11:31, Fernando Giorgetti wrote:

 > And what should I do to let Squid use the SNI defined by the TLS
client?

What do you want Squid to use that SNI for?

Alex.


 > On Thu, Sep 28, 2023 at 11:51 AM Alex Rousskov wrote:
 >
 >     On 2023-09-28 09:06, Fernando Giorgetti wrote:
 >      > Hi Matus, do you mean something like a DNAT (iptables) rule?
 >      > If so, I would say, it should work as well.
 >      >
 >      > But this is an environment I do not control, and I have
been told
 >     to try
 >      > using an existing squid installation to proxy non-http/TLS
data
 >     through.
 >      >
 >      > I appreciate any guidance or recommendation.
 >
 >
 >     Bugs notwithstanding, Squid can blindly tunnel intercepted
(at TCP port
 >     X) TCP traffic to its intended destination:
 >
 >           https_port X intercept ssl-bump ...
 >           ssl_bump splice all
 >
 >
 >     Without interception, then Squid can only tunnel stuff inside
HTTP
 >     CONNECT tunnels (for HTTP CONNECT requests received at TCP
port Y):
 >
 >           http_port Y ssl-bump ...
 >           ssl_bump splice all
 >
 >
 >     In both cases, Squid does not care about the protocols that
tunneled
 >     traffic is using. It could be HTTP, HTTPS, TLS, or anything
else on top
 >     of TCP.
 >
 >     Your ACLs may differ from "all" in the above sketches, of course,
 >     but if
 >     traffic is not TLS, then you want an "ssl_bump splice" rule that
 >     matches
 >     during SslBump step1. A rule with an "all" ACLs is the
simplest example
 >     of that.
 >
 >
 >     HTH,
 >
 >     Alex.
 >     P.S. I am getting an "Internal Server Error" when following
the haproxy
 >     link in the original question, so I cannot map what that page
says to
 >     the configurations above.
 >
 >
 >      > On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas wrote:
 >      >
 >      >     On 27.09.23 16:48, Fernando Giorgetti wrote:
 >      >      >I would like to know if it is possible to set up
Squid to
 >     perform
 >      >      >TLS passthrough to a given backend, relaying TLS
encrypted
 >      >      >traffic to the backend, similarly to what HAProxy
does below?
 >      >      >
 >      >
 > 
 >https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough  >  >>

 >      >      >
 >      >      >I have tried a few different configurations using
reverse
 >     proxy,
 >      >      >or peek and splice, but I could not make it work without
 >     providing
 >      >      >a valid HTTP request or a CONNECT request.
 >      >
 >      >     what's the difference between TCP redirect and this?
 >      >
 >      >     --
 >      >     Matus UHLAR - fantomas, uh...@fantomas.sk

 >     >

 >     >>
 >      >     ; http://www.fantomas.sk/ 
>
 >     
>>
 >      >     Warning: I wish NOT to receive e-mail advertising to this
 >     address.
 >      >     Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek
reklamnu
 >     postu.
 >      >     Depression is merely anger wit

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

Actually with the suggested blind passthrough, Squid would not handle the
TLS termination.
So without a reverse proxy (accel mode), how will Squid know what the
target is?

On Thu, Sep 28, 2023 at 1:02 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2023-09-28 11:31, Fernando Giorgetti wrote:
>
> > And what should I do to let Squid use the SNI defined by the TLS client?
>
> What do you want Squid to use that SNI for?
>
> Alex.
>
>
> > On Thu, Sep 28, 2023 at 11:51 AM Alex Rousskov wrote:
> >
> > On 2023-09-28 09:06, Fernando Giorgetti wrote:
> >  > Hi Matus, do you mean something like a DNAT (iptables) rule?
> >  > If so, I would say, it should work as well.
> >  >
> >  > But this is an environment I do not control, and I have been told
> > to try
> >  > using an existing squid installation to proxy non-http/TLS data
> > through.
> >  >
> >  > I appreciate any guidance or recommendation.
> >
> >
> > Bugs notwithstanding, Squid can blindly tunnel intercepted (at TCP
> port
> > X) TCP traffic to its intended destination:
> >
> >   https_port X intercept ssl-bump ...
> >   ssl_bump splice all
> >
> >
> > Without interception, then Squid can only tunnel stuff inside HTTP
> > CONNECT tunnels (for HTTP CONNECT requests received at TCP port Y):
> >
> >   http_port Y ssl-bump ...
> >   ssl_bump splice all
> >
> >
> > In both cases, Squid does not care about the protocols that tunneled
> > traffic is using. It could be HTTP, HTTPS, TLS, or anything else on
> top
> > of TCP.
> >
> > Your ACLs may differ from "all" in the above sketches, of course,
> > but if
> > traffic is not TLS, then you want an "ssl_bump splice" rule that
> > matches
> > during SslBump step1. A rule with an "all" ACLs is the simplest
> example
> > of that.
> >
> >
> > HTH,
> >
> > Alex.
> > P.S. I am getting an "Internal Server Error" when following the
> haproxy
> > link in the original question, so I cannot map what that page says to
> > the configurations above.
> >
> >
> >  > On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas wrote:
> >  >
> >  > On 27.09.23 16:48, Fernando Giorgetti wrote:
> >  >  >I would like to know if it is possible to set up Squid to
> > perform
> >  >  >TLS passthrough to a given backend, relaying TLS encrypted
> >  >  >traffic to the backend, similarly to what HAProxy does
> below?
> >  >  >
> >  >
> >  >
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough>
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> >>
> >  >  >
> >  >  >I have tried a few different configurations using reverse
> > proxy,
> >  >  >or peek and splice, but I could not make it work without
> > providing
> >  >  >a valid HTTP request or a CONNECT request.
> >  >
> >  > what's the difference between TCP redirect and this?
> >  >
> >  > --
> >  > Matus UHLAR - fantomas, uh...@fantomas.sk
> >   > >
> >  > ; http://www.fantomas.sk/ 
> > >
> >  > Warning: I wish NOT to receive e-mail advertising to this
> > address.
> >  > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu
> > postu.
> >  > Depression is merely anger without enthusiasm.
> >  > ___
> >  > squid-users mailing list
> >  > squid-users@lists.squid-cache.org
> > 
> >  >  > >
> >  > https://lists.squid-cache.org/listinfo/squid-users
> > 
> >  >  > >
> >  >
> >  >
> >  > ___
> >  > squid-users mailing list
> >  > squid-users@lists.squid-cache.org
> > 
> >  > https://lists.squid-cache.org/listinfo/squid-users
> > 
> >
> > ___
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > 
> > https://lists.sq

Re: [squid-users] TLS passthrough

[Alex Rousskov]

On 2023-09-28 11:31, Fernando Giorgetti wrote:


And what should I do to let Squid use the SNI defined by the TLS client?


What do you want Squid to use that SNI for?

Alex.



On Thu, Sep 28, 2023 at 11:51 AM Alex Rousskov wrote:

On 2023-09-28 09:06, Fernando Giorgetti wrote:
 > Hi Matus, do you mean something like a DNAT (iptables) rule?
 > If so, I would say, it should work as well.
 >
 > But this is an environment I do not control, and I have been told
to try
 > using an existing squid installation to proxy non-http/TLS data
through.
 >
 > I appreciate any guidance or recommendation.


Bugs notwithstanding, Squid can blindly tunnel intercepted (at TCP port
X) TCP traffic to its intended destination:

      https_port X intercept ssl-bump ...
      ssl_bump splice all


Without interception, then Squid can only tunnel stuff inside HTTP
CONNECT tunnels (for HTTP CONNECT requests received at TCP port Y):

      http_port Y ssl-bump ...
      ssl_bump splice all


In both cases, Squid does not care about the protocols that tunneled
traffic is using. It could be HTTP, HTTPS, TLS, or anything else on top
of TCP.

Your ACLs may differ from "all" in the above sketches, of course,
but if
traffic is not TLS, then you want an "ssl_bump splice" rule that
matches
during SslBump step1. A rule with an "all" ACLs is the simplest example
of that.


HTH,

Alex.
P.S. I am getting an "Internal Server Error" when following the haproxy
link in the original question, so I cannot map what that page says to
the configurations above.


 > On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas wrote:
 >
 >     On 27.09.23 16:48, Fernando Giorgetti wrote:
 >      >I would like to know if it is possible to set up Squid to
perform
 >      >TLS passthrough to a given backend, relaying TLS encrypted
 >      >traffic to the backend, similarly to what HAProxy does below?
 >      >
 > 
 >https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough  >

 >      >
 >      >I have tried a few different configurations using reverse
proxy,
 >      >or peek and splice, but I could not make it work without
providing
 >      >a valid HTTP request or a CONNECT request.
 >
 >     what's the difference between TCP redirect and this?
 >
 >     --
 >     Matus UHLAR - fantomas, uh...@fantomas.sk
 >
 >     ; http://www.fantomas.sk/ 
>
 >     Warning: I wish NOT to receive e-mail advertising to this
address.
 >     Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu
postu.
 >     Depression is merely anger without enthusiasm.
 >     ___
 >     squid-users mailing list
 > squid-users@lists.squid-cache.org

 >     >
 > https://lists.squid-cache.org/listinfo/squid-users

 >     >
 >
 >
 > ___
 > squid-users mailing list
 > squid-users@lists.squid-cache.org

 > https://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org

https://lists.squid-cache.org/listinfo/squid-users




___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

Hello Alex, thanks for your reply.

And what should I do to let Squid use the SNI defined by the TLS client?

Thanks again,
Fernando

On Thu, Sep 28, 2023 at 11:51 AM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2023-09-28 09:06, Fernando Giorgetti wrote:
> > Hi Matus, do you mean something like a DNAT (iptables) rule?
> > If so, I would say, it should work as well.
> >
> > But this is an environment I do not control, and I have been told to try
> > using an existing squid installation to proxy non-http/TLS data through.
> >
> > I appreciate any guidance or recommendation.
>
>
> Bugs notwithstanding, Squid can blindly tunnel intercepted (at TCP port
> X) TCP traffic to its intended destination:
>
>  https_port X intercept ssl-bump ...
>  ssl_bump splice all
>
>
> Without interception, then Squid can only tunnel stuff inside HTTP
> CONNECT tunnels (for HTTP CONNECT requests received at TCP port Y):
>
>  http_port Y ssl-bump ...
>  ssl_bump splice all
>
>
> In both cases, Squid does not care about the protocols that tunneled
> traffic is using. It could be HTTP, HTTPS, TLS, or anything else on top
> of TCP.
>
> Your ACLs may differ from "all" in the above sketches, of course, but if
> traffic is not TLS, then you want an "ssl_bump splice" rule that matches
> during SslBump step1. A rule with an "all" ACLs is the simplest example
> of that.
>
>
> HTH,
>
> Alex.
> P.S. I am getting an "Internal Server Error" when following the haproxy
> link in the original question, so I cannot map what that page says to
> the configurations above.
>
>
> > On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas wrote:
> >
> > On 27.09.23 16:48, Fernando Giorgetti wrote:
> >  >I would like to know if it is possible to set up Squid to perform
> >  >TLS passthrough to a given backend, relaying TLS encrypted
> >  >traffic to the backend, similarly to what HAProxy does below?
> >  >
> >  >
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> <
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> >
> >  >
> >  >I have tried a few different configurations using reverse proxy,
> >  >or peek and splice, but I could not make it work without providing
> >  >a valid HTTP request or a CONNECT request.
> >
> > what's the difference between TCP redirect and this?
> >
> > --
> > Matus UHLAR - fantomas, uh...@fantomas.sk 
> > ; http://www.fantomas.sk/ 
> > Warning: I wish NOT to receive e-mail advertising to this address.
> > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> > Depression is merely anger without enthusiasm.
> > ___
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > 
> > https://lists.squid-cache.org/listinfo/squid-users
> > 
> >
> >
> > ___
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > https://lists.squid-cache.org/listinfo/squid-users
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TLS passthrough

[Alex Rousskov]

On 2023-09-28 09:06, Fernando Giorgetti wrote:

Hi Matus, do you mean something like a DNAT (iptables) rule?
If so, I would say, it should work as well.

But this is an environment I do not control, and I have been told to try
using an existing squid installation to proxy non-http/TLS data through.

I appreciate any guidance or recommendation.



Bugs notwithstanding, Squid can blindly tunnel intercepted (at TCP port 
X) TCP traffic to its intended destination:


https_port X intercept ssl-bump ...
ssl_bump splice all


Without interception, then Squid can only tunnel stuff inside HTTP 
CONNECT tunnels (for HTTP CONNECT requests received at TCP port Y):


http_port Y ssl-bump ...
ssl_bump splice all


In both cases, Squid does not care about the protocols that tunneled 
traffic is using. It could be HTTP, HTTPS, TLS, or anything else on top 
of TCP.


Your ACLs may differ from "all" in the above sketches, of course, but if 
traffic is not TLS, then you want an "ssl_bump splice" rule that matches 
during SslBump step1. A rule with an "all" ACLs is the simplest example 
of that.



HTH,

Alex.
P.S. I am getting an "Internal Server Error" when following the haproxy 
link in the original question, so I cannot map what that page says to 
the configurations above.




On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas wrote:

On 27.09.23 16:48, Fernando Giorgetti wrote:
 >I would like to know if it is possible to set up Squid to perform
 >TLS passthrough to a given backend, relaying TLS encrypted
 >traffic to the backend, similarly to what HAProxy does below?
 >
 
>https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
 

 >
 >I have tried a few different configurations using reverse proxy,
 >or peek and splice, but I could not make it work without providing
 >a valid HTTP request or a CONNECT request.

what's the difference between TCP redirect and this?

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk 

; http://www.fantomas.sk/ 
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.
___
squid-users mailing list
squid-users@lists.squid-cache.org

https://lists.squid-cache.org/listinfo/squid-users



___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TLS passthrough

[Matus UHLAR - fantomas]

On 28.09.23 10:06, Fernando Giorgetti wrote:

Hi Matus, do you mean something like a DNAT (iptables) rule?


that was my question.


If so, I would say, it should work as well.


If you want simply redirect incoming connections to another IP/port, port 
redirector should work just like DNAT.



But this is an environment I do not control, and I have been told to try
using an existing squid installation to proxy non-http/TLS data through.

I appreciate any guidance or recommendation.


SQUID however does not have this functionality, packages like 
redir, rinetd, or xinetd do have it.




On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas 
wrote:


On 27.09.23 16:48, Fernando Giorgetti wrote:
>I would like to know if it is possible to set up Squid to perform
>TLS passthrough to a given backend, relaying TLS encrypted
>traffic to the backend, similarly to what HAProxy does below?
>
>
https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
>
>I have tried a few different configurations using reverse proxy,
>or peek and splice, but I could not make it work without providing
>a valid HTTP request or a CONNECT request.

what's the difference between TCP redirect and this?



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TLS passthrough

[Fernando Giorgetti]

Hi Matus, do you mean something like a DNAT (iptables) rule?
If so, I would say, it should work as well.

But this is an environment I do not control, and I have been told to try
using an existing squid installation to proxy non-http/TLS data through.

I appreciate any guidance or recommendation.

Thank you,
Fernando

On Thu, Sep 28, 2023 at 3:41 AM Matus UHLAR - fantomas 
wrote:

> On 27.09.23 16:48, Fernando Giorgetti wrote:
> >I would like to know if it is possible to set up Squid to perform
> >TLS passthrough to a given backend, relaying TLS encrypted
> >traffic to the backend, similarly to what HAProxy does below?
> >
> >
> https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough
> >
> >I have tried a few different configurations using reverse proxy,
> >or peek and splice, but I could not make it work without providing
> >a valid HTTP request or a CONNECT request.
>
> what's the difference between TCP redirect and this?
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Depression is merely anger without enthusiasm.
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TLS passthrough

[Matus UHLAR - fantomas]

On 27.09.23 16:48, Fernando Giorgetti wrote:

I would like to know if it is possible to set up Squid to perform
TLS passthrough to a given backend, relaying TLS encrypted
traffic to the backend, similarly to what HAProxy does below?

https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough

I have tried a few different configurations using reverse proxy,
or peek and splice, but I could not make it work without providing
a valid HTTP request or a CONNECT request.


what's the difference between TCP redirect and this?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

[squid-users] TLS passthrough

[Fernando Giorgetti]

Hello,

I would like to know if it is possible to set up Squid to perform
TLS passthrough to a given backend, relaying TLS encrypted
traffic to the backend, similarly to what HAProxy does below?

https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough

I have tried a few different configurations using reverse proxy,
or peek and splice, but I could not make it work without providing
a valid HTTP request or a CONNECT request.

Thank you,
Fernando
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users