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

[Fiehe, Christoph]

The caching feature is implemented by Apt-Cacher-NG, but the proxy only works sporadically. Squid seems to be a better choice. The remapping feature, for what I try to find a solution in Squid, is e.g. described at https://blog.packagecloud.io/using-apt-cacher-ng-with-ssl-tls/ in section "Caching objects.


>-----Ursprüngliche Nachricht-----
>Von: squid-users <squid-users-bounces at lists.squid-cache.org> Im Auftrag von Fiehe,
>Christoph
>Gesendet: Mittwoch, 10. Juli 2024 22:58
>An: squid-users at lists.squid-cache.org
>Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>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.
>
>_______________________________________________
>squid-users mailing list
>squid-users at lists.squid-cache.org
>https://lists.squid-cache.org/listinfo/squid-users