<div dir="auto">If someone has already done that, with the client running in a different machine, I would love to know how.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thanks</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 29 de set. de 2023 18:13, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2023-09-29 13:55, Fernando Giorgetti wrote:<br>
<br>
> The "intercept" scenario demonstrated here <br>
> <a href="https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource" rel="noreferrer noreferrer" target="_blank">https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource</a> <br>
> makes sense to me, as we are just redirecting internal traffic into Squid,<br>
> so the original destination IP is preserved.<br>
<br>
> I was able to make it work and that TLS app worked just fine. The<br>
> only constraint is that it requires that both the client and Squid<br>
> ran on the same machine, but at least it worked perfectly.<br>
<br>
I am very glad you are making progress. FWIW, there are also ways to <br>
intercept traffic from applications that do not run on the same machine <br>
as Squid. This is not my area of expertise, but others on the list can <br>
guide you if you need that kind of setup.<br>
<br>
<br>
> Here is my squid.conf (just in case someone eventually has a similar<br>
> issue):<br>
<br>
Thank you!<br>
<br>
Alex.<br>
<br>
<br>
<br>
> acl CONNECT method CONNECT<br>
> acl mytlsserverip dst 10.0.0.10<br>
> http_access allow CONNECT mytlsserverip<br>
> <br>
> http_port 3128<br>
> <br>
> https_port <a href="http://127.0.0.1:3129" rel="noreferrer noreferrer" target="_blank">127.0.0.1:3129</a> intercept ssl-bump \<br>
> tls-cert=/tmp/certs/squid.pem \<br>
> tls-key=/tmp/certs/squid.key \<br>
> generate-host-certificates=off<br>
> <br>
> ssl_bump splice all<br>
> <br>
> <br>
> And here are the firewall rules I have used:<br>
> <br>
> iptables -t nat -I OUTPUT -p tcp -d 10.0.0.10 --dport 55671 -j DNAT <br>
> --to-destination <a href="http://127.0.0.1:3129" rel="noreferrer noreferrer" target="_blank">127.0.0.1:3129</a> <<a href="http://127.0.0.1:3129" rel="noreferrer noreferrer" target="_blank">http://127.0.0.1:3129</a>><br>
> iptables -t nat -I OUTPUT --match owner --uid-owner squid -p tcp -d <br>
> 10.0.0.10 --dport 55671 -j ACCEPT<br>
> <br>
> I appreciate all the guidance and discussion Matus and Alex.<br>
> <br>
> Thank you,<br>
> Fernando<br>
> <br>
> On Fri, Sep 29, 2023 at 12:53 PM Alex Rousskov <br>
> <<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a> <br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a>>> wrote:<br>
> <br>
> On 2023-09-29 10:55, Fernando Giorgetti wrote:<br>
> > Do you control the client application? If yes, then perhaps<br>
> it can be<br>
> > adjusted to support HTTP proxies? In other words, the client<br>
> will send a<br>
> > plain text HTTP CONNECT request to Squid and, upon receiving<br>
> a 200<br>
> > (Connection Established) response headers, will start using<br>
> TLS with the<br>
> > origin server. In this case, you do not need interception.<br>
> <br>
> <br>
> > Nope, the client application is also used to communicate with<br>
> other apps in<br>
> > other environments.<br>
> <br>
> FWIW, "used with other apps" does not imply or explain the "nope, we do<br>
> not control the application" answer IMHO.<br>
> <br>
> <br>
> > The SNI has to be used as the client/server apps perform<br>
> > mutual TLS authentication.<br>
> <br>
> To avoid a misunderstanding, nothing I have said precludes the use of<br>
> TLS SNI by the client application. Thus, I am not sure why you are<br>
> saying the above.<br>
> <br>
> <br>
> > In order to evaluate if we can use Squid for this purpose, I have<br>
> > also created a basic TLS client/server app to validate what is<br>
> > happening. Basically my TLS client tries to connect directly to Squid<br>
> > IP/Port and I am indicating the SNI so that the TLS handshake<br>
> > passes.<br>
> <br>
> FWIW, a scenario where the client application establishes a TLS<br>
> connection with Squid https_port (configured as a reverse HTTPS proxy)<br>
> will not work for your use case AFAICT. I am not sure why you are<br>
> testing this. It has not been suggested on this mailing list.<br>
> <br>
> BTW, you can use ("curl" or even "openssl s_client") and "openssl<br>
> s_server" for basic tests. I recommend using well-known test programs<br>
> (instead of custom apps) because doing so makes it easier for mailing<br>
> list readers to understand what your test clients and servers are doing<br>
> (and to reproduce your setup).<br>
> <br>
> <br>
> > When I tried to make it work using a forward proxy with intercept and<br>
> > ssl_bump, I could not make Squid peek at the SNI and tunnel the<br>
> > request to the correct destination.<br>
> <br>
> Please note that "forward proxy with intercept" is an oxymoron -- the<br>
> two port modes (i.e. explicit "intercept" and default forward proxying)<br>
> are mutually exclusive.<br>
> <br>
> If you do not want to or cannot modify/configure the client application<br>
> to use Squid as a forward HTTP proxy (as I detailed earlier; see the<br>
> paragraph still quoted at the beginning of this message), then your<br>
> other choice is interception (as I detailed earlier; see the "Squid<br>
> supports blind tunneling of intercepted TCP connections" discussion in<br>
> the previous exchange).<br>
> <br>
> When Squid https_port gets an intercepted client TCP connection, Squid<br>
> does not need SNI to know where to forward that TCP connection. Squid<br>
> opens a TCP connection to the IP address where the client TCP<br>
> connection<br>
> was going (or trying to go) before it was intercepted. That intended<br>
> destination IP address is delivered to Squid by the OS, as a part of<br>
> interception mechanism/setup. TLS and SNI are not involved in this<br>
> process.<br>
> <br>
> If you have not tested an interception scenario, please do. If you<br>
> have,<br>
> please share your interception configuration, Squid configuration, and<br>
> any relevant error/problem information.<br>
> <br>
> <br>
> HTH,<br>
> <br>
> Alex.<br>
> <br>
> <br>
> > On Fri, Sep 29, 2023 at 11:35 AM Alex Rousskov wrote:<br>
> ><br>
> > On 2023-09-29 09:17, Fernando Giorgetti wrote:<br>
> ><br>
> > > Actually I am evaluating if Squid can be used to proxy<br>
> Non-HTTP/TLS<br>
> > > data, as we have a restricted environment where Squid is<br>
> > currently the<br>
> > > only way to get out to the internet.<br>
> ><br>
> > Yes, Squid can tunnel non-HTTP data, including TLS data.<br>
> ><br>
> ><br>
> > > The idea is that the client application will open a<br>
> connection to<br>
> > a given<br>
> > > hostname and port (setting the SNI in the TLS options),<br>
> > considering that<br>
> > > the given hostname/port is the actual backend they're<br>
> trying to<br>
> > reach.<br>
> ><br>
> > Do you control the client application? If yes, then perhaps<br>
> it can be<br>
> > adjusted to support HTTP proxies? In other words, the client will<br>
> > send a<br>
> > plain text HTTP CONNECT request to Squid and, upon receiving<br>
> a 200<br>
> > (Connection Established) response headers, will start using<br>
> TLS with<br>
> > the<br>
> > origin server. In this case, you do not need interception.<br>
> ><br>
> ><br>
> > > We can either try to use a fake hostname (defined in the<br>
> > /etc/hosts of the<br>
> > > tls client machine) which would actually point to Squid's IP<br>
> ><br>
> > AFAICT, faking the IP address will not work without Squid<br>
> source code<br>
> > modifications because a non-intercepting Squid https_port<br>
> will want to<br>
> > terminate TLS -- such a port does not support blindly<br>
> tunneling traffic.<br>
> ><br>
> ><br>
> > > or eventually<br>
> > > redirect traffic to the real destination into Squid using<br>
> a DNAT<br>
> > rule.<br>
> ><br>
> > I am not a DNAT expert, but this sounds like interception to<br>
> me. Bugs<br>
> > notwithstanding, Squid supports blind tunneling of<br>
> intercepted TCP<br>
> > connections (to their intended destination):<br>
> ><br>
> > https_port X intercept ssl-bump ...<br>
> > ssl_bump splice all<br>
> ><br>
> > On a successful tunneling path, the above configuration does<br>
> not care<br>
> > whether the intercepted traffic is TLS and will not peek at<br>
> TLS SNI,<br>
> > but<br>
> > nothing in your requirements necessitates SNI knowledge AFAICT.<br>
> ><br>
> > If Squid fails to establish a TCP connection to the intended<br>
> > destination<br>
> > of the intercepted connection, then the situation becomes<br>
> more complex:<br>
> > Squid (with the above configuration) assumes that the client is<br>
> > speaking<br>
> > TLS. Squid will attempt to bump the TLS client connection and<br>
> send a<br>
> > Squid-generated HTTP error response to the client. AFAIK,<br>
> this bumping<br>
> > and error sending attempt cannot be prevented in this case<br>
> without<br>
> > Squid<br>
> > source code modifications: Squid used to be able to terminate a<br>
> > client-Squid connection instead of sending a Squid-generated<br>
> HTTP error<br>
> > response (by replacing the corresponding Squid error page<br>
> contents with<br>
> > a word "reset"). However, that feature was accidentally(?)<br>
> dropped in<br>
> > 2002 commit 76cdc28 AFAICT.<br>
> ><br>
> ><br>
> > HTH,<br>
> ><br>
> > Alex.<br>
> ><br>
> ><br>
> > > But overall, it will be a 1:1 relationship, meaning, the<br>
> > https_port on Squid<br>
> > > would be used exclusively to this purpose of proxying from a<br>
> > given source<br>
> > > to a given destination.<br>
> > ><br>
> > > That is why I was considering a reverse-proxy, but I had<br>
> no luck<br>
> > with it<br>
> > > (actually<br>
> > > I was able to proxy HTTP/HTTPS, but not non-http).<br>
> > ><br>
> > > Thank you again,<br>
> > > Fernando<br>
> > ><br>
> > > On Thu, Sep 28, 2023 at 11:39 PM Alex Rousskov<br>
> > > <<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a>><br>
> > <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a>>><br>
> > > <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a>><br>
> > <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank" rel="noreferrer">rousskov@measurement-factory.com</a>>>>> wrote:<br>
> > ><br>
> > > On 2023-09-28 20:35, Fernando Giorgetti wrote:<br>
> > ><br>
> > > > Do you have any recommendations on how I could have<br>
> it done?<br>
> > ><br>
> > > I am unable to confirm whether Squid can do what you<br>
> want or<br>
> > provide<br>
> > > configuration recommendations because I do not yet<br>
> know how<br>
> > your Squid<br>
> > > will receive traffic (e.g., an intercepting proxy or<br>
> an explicit<br>
> > > forward<br>
> > > HTTP proxy), what traffic Squid will receive (e.g., TLS,<br>
> > plain HTTP,<br>
> > > something else), and what you want Squid to do with<br>
> that traffic.<br>
> > ><br>
> > > To make progress, I recommend describing the above details<br>
> > (for one<br>
> > > typical use case?) and then answering any followup<br>
> questions.<br>
> > ><br>
> > ><br>
> > > Cheers,<br>
> > ><br>
> > > Alex.<br>
> > ><br>
> > ><br>
> > > > When my tls client tries to reach the target<br>
> > through Squid, using<br>
> > > > a "ssl_bump splice", it seems like squid is trying<br>
> to reach<br>
> > > itself in a<br>
> > > > loop.<br>
> > > ><br>
> > > > I have also tried including a peek first, but no luck.<br>
> > > ><br>
> > > > Thanks again for all suggestions.<br>
> > > ><br>
> > > > On Thu, Sep 28, 2023 at 7:23 PM Alex Rousskov wrote:<br>
> > > ><br>
> > > > On 2023-09-28 15:23, Fernando Giorgetti wrote:<br>
> > > ><br>
> > > > > Actually with the suggested blind passthrough,<br>
> > Squid would not<br>
> > > > handle<br>
> > > > > the TLS termination.<br>
> > > ><br>
> > > > Correct.<br>
> > > ><br>
> > > ><br>
> > > > > how will Squid know what the target is?<br>
> > > ><br>
> > > > In many cases, Squid can learn SNI by peeking<br>
> at TLS<br>
> > ClientHello,<br>
> > > > without terminating TLS. Bugs notwithstanding,<br>
> none of the<br>
> > > > configuration<br>
> > > > sketches I shared previously will do that though.<br>
> > > ><br>
> > > ><br>
> > > > HTH,<br>
> > > ><br>
> > > > Alex.<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > > On Thu, Sep 28, 2023 at 1:02 PM Alex<br>
> Rousskov wrote:<br>
> > > > ><br>
> > > > > On 2023-09-28 11:31, Fernando Giorgetti<br>
> wrote:<br>
> > > > ><br>
> > > > > > And what should I do to let Squid use<br>
> the SNI<br>
> > > defined by<br>
> > > > the TLS<br>
> > > > > client?<br>
> > > > ><br>
> > > > > What do you want Squid to use that SNI for?<br>
> > > > ><br>
> > > > > Alex.<br>
> > > > ><br>
> > > > ><br>
> > > > > > On Thu, Sep 28, 2023 at 11:51 AM Alex<br>
> > Rousskov wrote:<br>
> > > > > ><br>
> > > > > > On 2023-09-28 09:06, Fernando<br>
> Giorgetti<br>
> > wrote:<br>
> > > > > > > Hi Matus, do you mean<br>
> something like<br>
> > a DNAT<br>
> > > > (iptables) rule?<br>
> > > > > > > If so, I would say, it should<br>
> work as<br>
> > well.<br>
> > > > > > ><br>
> > > > > > > But this is an environment I<br>
> do not<br>
> > control,<br>
> > > and I have<br>
> > > > > been told<br>
> > > > > > to try<br>
> > > > > > > using an existing squid<br>
> installation<br>
> > to proxy<br>
> > > > non-http/TLS<br>
> > > > > data<br>
> > > > > > through.<br>
> > > > > > ><br>
> > > > > > > I appreciate any guidance or<br>
> > recommendation.<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > Bugs notwithstanding, Squid can<br>
> blindly<br>
> > tunnel<br>
> > > intercepted<br>
> > > > > (at TCP port<br>
> > > > > > X) TCP traffic to its intended<br>
> destination:<br>
> > > > > ><br>
> > > > > > https_port X intercept<br>
> ssl-bump ...<br>
> > > > > > ssl_bump splice all<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > Without interception, then Squid<br>
> can only<br>
> > > tunnel stuff<br>
> > > > inside<br>
> > > > > HTTP<br>
> > > > > > CONNECT tunnels (for HTTP CONNECT<br>
> requests<br>
> > > received at TCP<br>
> > > > > port Y):<br>
> > > > > ><br>
> > > > > > http_port Y ssl-bump ...<br>
> > > > > > ssl_bump splice all<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > In both cases, Squid does not<br>
> care about the<br>
> > > protocols<br>
> > > > that<br>
> > > > > tunneled<br>
> > > > > > traffic is using. It could be HTTP,<br>
> > HTTPS, TLS, or<br>
> > > > anything<br>
> > > > > else on top<br>
> > > > > > of TCP.<br>
> > > > > ><br>
> > > > > > Your ACLs may differ from "all"<br>
> in the above<br>
> > > sketches,<br>
> > > > of course,<br>
> > > > > > but if<br>
> > > > > > traffic is not TLS, then you want an<br>
> > "ssl_bump<br>
> > > splice"<br>
> > > > rule that<br>
> > > > > > matches<br>
> > > > > > during SslBump step1. A rule with an<br>
> > "all" ACLs<br>
> > > is the<br>
> > > > > simplest example<br>
> > > > > > of that.<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > HTH,<br>
> > > > > ><br>
> > > > > > Alex.<br>
> > > > > > P.S. I am getting an "Internal Server<br>
> > Error" when<br>
> > > > following<br>
> > > > > the haproxy<br>
> > > > > > link in the original question, so I<br>
> > cannot map what<br>
> > > > that page<br>
> > > > > says to<br>
> > > > > > the configurations above.<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > > On Thu, Sep 28, 2023 at<br>
> 3:41 AM Matus<br>
> > UHLAR -<br>
> > > > fantomas wrote:<br>
> > > > > > ><br>
> > > > > > > On 27.09.23 16:48, Fernando<br>
> > Giorgetti wrote:<br>
> > > > > > > >I would like to know if<br>
> it is<br>
> > possible<br>
> > > to set up<br>
> > > > > Squid to<br>
> > > > > > perform<br>
> > > > > > > >TLS passthrough to a<br>
> given backend,<br>
> > > relaying TLS<br>
> > > > > encrypted<br>
> > > > > > > >traffic to the backend,<br>
> > similarly to<br>
> > > what HAProxy<br>
> > > > > does below?<br>
> > > > > > > ><br>
> > > > > > ><br>
> > > > > ><br>
> > > > ><br>
> > > ><br>
> > ><br>
> > <br>
> ><a href="https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough" rel="noreferrer noreferrer" target="_blank">https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough</a> <<a href="https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough" rel="noreferrer noreferrer" target="_blank">https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough</a>><br>
> > > > > > > ><br>
> > > > > > > >I have tried a few different<br>
> > > configurations using<br>
> > > > > reverse<br>
> > > > > > proxy,<br>
> > > > > > > >or peek and splice, but<br>
> I could not<br>
> > > make it<br>
> > > > work without<br>
> > > > > > providing<br>
> > > > > > > >a valid HTTP request or a<br>
> > CONNECT request.<br>
> > > > > > ><br>
> > > > > > > what's the difference<br>
> between TCP<br>
> > > redirect and<br>
> > > > this?<br>
> > > > > > ><br>
> > > > > > > --<br>
> > > > > > > Depression is merely anger<br>
> without<br>
> > > enthusiasm.<br>
> <br>
<br>
</blockquote></div>