<div dir="ltr">Alex,<div><br></div><div>Sorry for my misconceptions in my previous email.</div><div><br></div><div>The "intercept" scenario demonstrated here <a href="https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource">https://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource</a></div><div>makes sense to me, as we are just redirecting internal traffic into Squid,</div><div>so the original destination IP is preserved.</div><div><br></div><div>I was able to make it work and that TLS app (which I have no control at all),</div><div>worked just fine. The only constraint is that it requires that both the client and </div><div>Squid ran on the same machine, but at least it worked perfectly.</div><div><br></div><div>Here is my squid.conf (just in case someone eventually has a similar issue):</div><div><br></div><div><font face="monospace">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">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></font></div><div><font face="monospace"><br></font></div><div><br></div><div>And here are the firewall rules I have used:</div><div><br></div><div><font face="monospace">iptables -t nat -I OUTPUT -p tcp -d 10.0.0.10 --dport 55671 -j DNAT --to-destination <a href="http://127.0.0.1:3129">127.0.0.1:3129</a><br>iptables -t nat -I OUTPUT --match owner --uid-owner squid -p tcp -d 10.0.0.10 --dport 55671 -j ACCEPT<br></font></div><div><br></div><div>I appreciate all the guidance and discussion Matus and Alex.<br></div><div><br></div><div>Thank you,</div><div>Fernando</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 29, 2023 at 12:53 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-09-29 10:55, Fernando Giorgetti wrote:<br>
> Do you control the client application? If yes, then perhaps it can be<br>
> adjusted to support HTTP proxies? In other words, the client will send a<br>
> plain text HTTP CONNECT request to Squid and, upon receiving a 200<br>
> (Connection Established) response headers, will start using 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 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 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 process.<br>
<br>
If you have not tested an interception scenario, please do. If you 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 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 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 trying to<br>
> reach.<br>
> <br>
> Do you control the client application? If yes, then perhaps 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 a 200<br>
> (Connection Established) response headers, will start using 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 source code<br>
> modifications because a non-intercepting Squid https_port will want to<br>
> terminate TLS -- such a port does not support blindly tunneling traffic.<br>
> <br>
> <br>
> > or eventually<br>
> > redirect traffic to the real destination into Squid using a DNAT<br>
> rule.<br>
> <br>
> I am not a DNAT expert, but this sounds like interception to me. Bugs<br>
> notwithstanding, Squid supports blind tunneling of 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 not care<br>
> whether the intercepted traffic is TLS and will not peek at 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 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 send a<br>
> Squid-generated HTTP error response to the client. AFAIK, this bumping<br>
> and error sending attempt cannot be prevented in this case 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 HTTP error<br>
> response (by replacing the corresponding Squid error page contents with<br>
> a word "reset"). However, that feature was accidentally(?) 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 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">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>><br>
> > <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">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 it done?<br>
> ><br>
> > I am unable to confirm whether Squid can do what you want or<br>
> provide<br>
> > configuration recommendations because I do not yet know how<br>
> your Squid<br>
> > will receive traffic (e.g., an intercepting proxy or 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 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 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 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 at TLS<br>
> ClientHello,<br>
> > > without terminating TLS. Bugs notwithstanding, 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 Rousskov wrote:<br>
> > > ><br>
> > > > On 2023-09-28 11:31, Fernando Giorgetti wrote:<br>
> > > ><br>
> > > > > And what should I do to let Squid use 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 Giorgetti<br>
> wrote:<br>
> > > > > > Hi Matus, do you mean something like<br>
> a DNAT<br>
> > > (iptables) rule?<br>
> > > > > > If so, I would say, it should work as<br>
> well.<br>
> > > > > ><br>
> > > > > > But this is an environment I do not<br>
> control,<br>
> > and I have<br>
> > > > been told<br>
> > > > > to try<br>
> > > > > > using an existing squid 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 blindly<br>
> tunnel<br>
> > intercepted<br>
> > > > (at TCP port<br>
> > > > > X) TCP traffic to its intended destination:<br>
> > > > ><br>
> > > > > https_port X intercept ssl-bump ...<br>
> > > > > ssl_bump splice all<br>
> > > > ><br>
> > > > ><br>
> > > > > Without interception, then Squid can only<br>
> > tunnel stuff<br>
> > > inside<br>
> > > > HTTP<br>
> > > > > CONNECT tunnels (for HTTP CONNECT 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 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" 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 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 it is<br>
> possible<br>
> > to set up<br>
> > > > Squid to<br>
> > > > > perform<br>
> > > > > > >TLS passthrough to a 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>
> ><a href="https://www.haproxy.com/documentation/aloha/latest/security/tls/encryption-strategies/#tls-passthrough" rel="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 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 between TCP<br>
> > redirect and<br>
> > > this?<br>
> > > > > ><br>
> > > > > > --<br>
> > > > > > Depression is merely anger without<br>
> > enthusiasm.<br>
<br>
</blockquote></div>