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@xxxxxxxxxxxxxxxxxxxxx> Im Auftrag von Fiehe, >Christoph >Gesendet: Mittwoch, 10. Juli 2024 22:58 >An: squid-users@xxxxxxxxxxxxxxxxxxxxx >Betreff: Re: 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@xxxxxxxxxxxxxxxxxxxxxxx> >>Gesendet: Mittwoch, 10. Juli 2024 22:15 >>An: squid-users@xxxxxxxxxxxxxxxxxxxxx >>Cc: Fiehe, Christoph <c.fiehe@xxxxxxxxxxx> >>Betreff: AW: 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@xxxxxxxxxxxxxxxxxxxxx >https://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
