On 2024-07-05 10:15, Wagner, Juergen03 wrote:
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.
Do you expect that by just changing the URL scheme from http to https Squid is doing the encryption and decryption of the data?
Yes, I do expect Squid to honor the new URL scheme. Honoring rewriter
instructions is natural, but there is more to the story here: Bugs
notwithstanding, Squid is already capable for receiving a plain text
"GET https://..."; request on http_port and doing the encryption when
talking to the requested TLS origin server. What your rewriter is doing
feels very similar to that GET-https use case!
My suspicion was or is, that Squid is just forwarding the unencrypted data form the http client to the https server.
IMO, that would be a Squid bug in this case.
How can I check this when generating the Squid logs with "debug_options ALL,9"
You should not. Debugging logs are for Squid developers. Me or others
will check if you share the logs. Share privately if needed and/or use
fake/temporary keys/passwords/etc. to avoid leaking something sensitive.
There are a few relevant hints at
https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
HTH,
Alex.
<<
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.
Internal
-----Original Message-----
From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Freitag, 5. Juli 2024 15:52
To: Wagner, Juergen03 <juergen.3.wagner@xxxxxxxxxxxxxxxxxxxxxxxxxxx>; 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-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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
