>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? My suspicion was or is, that Squid is just forwarding the unencrypted data form the http client to the https server. How can I check this when generating the Squid logs with "debug_options ALL, 9" Regards, Juergen << 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
