Hello, thanks a lot for the fast responses. 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". 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. 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? Could the Squid configuration directive "http_port" in combination with the mode "accel" be used to support that use case? Maybe Alex' last statement is the solution: << 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 >> Regards, Juergen Internal -----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
