[squid-users] Rewriting HTTP to HTTPS for generic package proxy

[Fiehe, Christoph]

No problem. I am just trying to find something that helps to narrow down the problem. What I want to achieve is, that a client can use HTTP in the LAN, so that Squid can cache distribution packages without making use of SSL intercepting when repos are only accessible via HTTPS. In that case the secure connection must start at the proxy and end on the target server with or without any upstream proxies in betweem. When the proxy has received the payload, it can cache it and send it back to the client via plain HTTP. When a new request for this package arrives, the server can just return the resource from the cache.

We have the following setup:

client -> downstream proxy -> upstream proxy -> https://download.docker.com

Now let us assume the client wants to retrieve the following resource http://download.docker.com/linux/ubuntu/dists/jammy/InRelease from the upstream proxy.

The client initiates a HTTP GET request and sends it to the downstream proxy. Now, the URL gets rewritten. It indicates to use a HTTPS connection instead in order to talk to the target server, in our case the result is https://download.docker.com/linux/ubuntu/dists/jammy/InRelease. Now comes the critical point: From my understanding – it may be wrong of course - the downstream server now has to send a CONNECT request to the upstream server to advise him to establish a secure connection to the target server. After creation, the downstream proxy can retrieve the resource and send it back to the client via plain HTTP.

I suppose, that the GnuTLS occurs because of a missing SSL handshake between downstream proxy and download.docker.com.

Do I get something wrong?

Regards,
Christoph


>-----Ursprüngliche Nachricht-----
>Von: Alex Rousskov <rousskov at measurement-factory.com>
>Gesendet: Mittwoch, 10. Juli 2024 22:15
>An: squid-users at lists.squid-cache.org
>Cc: Fiehe, Christoph <c.fiehe at eurodata.de>
>Betreff: AW: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>On 2024-07-10 15:31, Fiehe, Christoph wrote:
>> The problem is that the proxy just forwards the client GET request to the upstream proxy
>
>Why does sending a GET request to the upstream proxy represent a problem
>in your use case? I cannot find anything in your prior messages on this
>thread that would preclude sending a GET request to the upstream proxy.
>
>
>> but in that case a CONNECT is required.
>
>Why?
>
>Please do not interpret my response as implying that this "must send
>CONNECT" requirement is wrong (or correct). At this point, I am just
>trying to understand what problem(s) you are trying to solve beyond the
>one you have originally described.
>
>
>Thank you,
>
>Alex.