[squid-users] Squid as http to https forward proxy

[Alex Rousskov]

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 at lists.squid-cache.org> On Behalf Of Alex Rousskov
> Sent: Donnerstag, 4. Juli 2024 18:43
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] 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 at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users