On 2024-07-05 09:16, Wagner, Juergen03 wrote:
Actually we want to be able to connect to any remote server.
So we are not looking for a solution with a "single true origin server".
Thank you for clarifying that.
My current understanding from your response is, that a simple
url-rewrite only, as we tried, is not working to forward http
requests form a client to any https server.
FWIW, I do not know why URL scheme rewriting does not work in your use
case. In principle, bugs notwithstanding, I would expect URL scheme
rewriting to work. In my original response, I was focusing on avoiding
rewrites for a case where they should not be needed because they should
not be needed (in that use case) and because they did not work (in your
specific tests), but _not_ because they should not work in principle or
on some fundamental level.
Just to be clear, is the usage of Squid as a forward http proxy for a
client while using https for external communication possible without
any Squid code changes?
That particular question covers several different scenarios. Your use
case is one of them. The answer for your specific use case is unknown
(to me) -- I would expect URL scheme rewrites to work but they do not in
your test. I do not know why.
Alex: At some point, depending on the use case, it will be easier to
enhance Squid to encrypt plain HTTP requests
That comment still applies. However, if you would prefer to avoid (or at
least reduce) Squid code modifications, it may be useful to triage why
scheme rewrites do not work in your tests. In other words, why Squid
generates a "Bad Gateway" error when the rewriter changes request URL
scheme from "http" to "https". Sharing a pointer to compressed cache.log
collected with debug_options set to ALL,9 while reproducing the problem
with a single test transaction may be the best next step.
HTH,
Alex.
-----Original Message-----
From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Alex Rousskov
Sent: Donnerstag, 4. Juli 2024 18:43
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Squid as http to https forward proxy
CAUTION: This is an external email. Do not click or open any attachments unless you recognize the sender and know that the content is safe. (http://links.conti.de/mailcheck)
On 2024-07-04 12:36, Alex Rousskov wrote:
On 2024-07-04 10:58, Matus UHLAR - fantomas wrote:
On 2024-07-04 09:20, Wagner, Juergen03 wrote:
we are evaluating Squid to be used as a http to https forward proxy.
So Squid would need to support the following setup:
http (client) ----> Squid ---> https ( server )
Could someone please confirm if the given setup is in principle
possible with Squid?
If yes, which configuration needs to be done?
On 04.07.24 10:36, Alex Rousskov wrote:
Yes, Squid should be able to forward plain text HTTP requests to
a secure server. Use cache_peer directive with "tls" and "originserver"
flags. Here is an untested sketch:
# routing all traffic to one HTTPS origin server
cache_peer 127.0.0.1 parent 443 0 tls originserver \
name=MySecureOrigin \
no-query no-digest
cache_peer_access MySecureOrigin allow all
always_direct deny all
never_direct allow all
nonhierarchical_direct off
Afaik this means that it is not possible with any remote server,
because all servers you want to access this way must be explicitly
set up in squid.conf, correct?
I assumed (possibly incorrectly) that Juergen was asking about a
single "true origin server" (e.g., example.com). The above example was
written with a single "true origin server" in mind. However, exactly
the same Squid configuration may work to forward traffic to a reverse
proxy (running at 127.0.0.1 on port 443) that "represents"
multiple/different "true origin servers".
That reverse proxy will need to shovel TLS bytes received from Squid
to the right "true origin server", but I am guessing that it can do
that based on TLS SNI supplied by Squid. Some Squid code modifications
may be necessary to make this work correctly with persistent
Squid-to-peer connections and such, but nothing major AFAICT (and they
can be turned off using server_persistent_connections if they are in the way).
AFAICT, with either SslBump or some Squid code modifications, that
reverse proxy can be a Squid proxy. With even more Squid enhancements,
that reverse proxy can also become an https_port on the same Squid
proxy instance where the http_port receives plain HTTP requests!
At some point, depending on the use case, it will be easier to enhance Squid to encrypt plain HTTP requests without using this TLS cache_peer hack, of course.
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
