[squid-users] TLS passthrough
Rafael Akchurin
rafael.akchurin at diladele.com
Sat Sep 30 08:02:13 UTC 2023
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 <squid-users-bounces at lists.squid-cache.org> On Behalf Of Fernando Giorgetti
Sent: Saturday, September 30, 2023 12:07 AM
To: Alex Rousskov <rousskov at measurement-factory.com>
Cc: squid-users at 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 <rousskov at measurement-factory.com<mailto:rousskov at 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
> <rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>
> <mailto:rousskov at measurement-factory.com<mailto:rousskov at 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
> 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
> > > <rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>
> <mailto:rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>>
> > <mailto:rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>
> <mailto:rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>>>
> > > <mailto:rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>
> <mailto:rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>>
> > <mailto:rousskov at measurement-factory.com<mailto:rousskov at measurement-factory.com>
> <mailto:rousskov at measurement-factory.com<mailto:rousskov at 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
> > > > > > 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?
> > > > > > >
> > > > > > > --
> > > > > > > Depression is merely anger
> without
> > > enthusiasm.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20230930/c2051ecd/attachment-0001.htm>
More information about the squid-users
mailing list