The only solution I was currently able to get working, was to make use of an Apache server installed locally beside Squid. It acts as a reverse proxy and gets queried by Squid when the client requests an external resource via HTTP, but that resource must be accessed transparently for the client via HTTPS using an upstream proxy. The Apache is able to initiate the required CONNECT request to the upstream proxy and to fetch that resource from the specified source via the established tunnel. I do not like the solution. It would be nice to get rid of the Apache, but I have not found a way to use URL rewriting in combination with Squid's reverse proxy capabilities to fetch that resource in case of HTTPS via a CONNECT to the upstream proxy. If someone has a better idea to achieve that behavior, please do not hesitate to send a response. This is just an experimental configuration and should not be used in production: jesred.rules: regex ^(http://download\.docker\.com.*)$ http://localhost:9090?uri=\1 vhost.conf: Listen 9090 <VirtualHost 127.0.0.1:9090> ServerName localhost ServerAlias 127.0.0.1 ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLProxyEngine On ProxyRemoteMatch ^(?!.*internaldomain\.com).*$ http://<PROXY-FQDN>:<PROXY-PORT> RewriteCond %{QUERY_STRING} uri=https?:\/\/([^&]*)$ RewriteRule ^ https://%1 [P,L] </VirtualHost> squid.conf: http_port 8000 visible_hostname pkg-proxy cache_peer <PROXY-FQDN> parent <PROXY-PORT> 0 no-query default always_direct allow to_localhost never_direct allow all http_access allow all cache deny all url_rewrite_children 3 startup=0 idle=1 concurrency=1 url_rewrite_program /usr/lib/squid/jesred Regards, Christoph >-----Ursprüngliche Nachricht----- >Von: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> Im Auftrag von Alex Rousskov >Gesendet: Freitag, 12. Juli 2024 00:11 >An: squid-users@xxxxxxxxxxxxxxxxxxxxx >Betreff: Re: Rewriting HTTP to HTTPS for generic package proxy > >On 2024-07-11 17:03, Amos Jeffries wrote: >> On 11/07/24 00:49, Alex Rousskov wrote: >>> On 2024-07-09 18:25, Fiehe, Christoph wrote: >>> >>>> I hope that somebody has an idea, what I am doing wrong. >>> >>> AFAICT from the debugging log, it is your parent proxy that returns an >>> ERR_SECURE_CONNECT_FAIL error page in response to a seemingly valid >>> "HEAD https://..."; request. Can you ask their admin to investigate? >>> You may also recommend that they upgrade from Squid v4 that has many >>> known security vulnerabiities. >>> >>> If parent is uncooperative, you can try to reproduce the problem by >>> temporary installing your own parent Squid instance and configuring >>> your child Squid to use that instead. >>> >>> HTH, >>> >>> Alex. >>> P.S. Unlike Amos, I do not see serious conceptual problems with >>> rewriting request target scheme (as a temporary compatibility >>> measure). It may not always work, for various reasons, but it does not >>> necessarily make things worse (and may make things better). > > >> To which I refer you to: > >None of the weaknesses below are applicable to request target scheme >rewriting (assuming both proxies in question are implemented/configured >correctly, of course). Specific non-applicability reasons are given >below for each weakness URL: > >> https://cwe.mitre.org/data/definitions/311.html > >The above "The product does not encrypt sensitive or critical >information before storage or transmission" case is not applicable: All >connections can be encrypted as needed after the scheme rewrite. > > >> https://cwe.mitre.org/data/definitions/312.html > >The above "The product stores sensitive information in cleartext within >a resource that might be accessible to another control sphere." case is >not applicable: Squid does not store information in such an accessible >resource. > > >> https://cwe.mitre.org/data/definitions/319.html > >The above "The product transmits sensitive or security-critical data in >cleartext in a communication channel that can be sniffed by unauthorized >actors." case is not applicable: All connections can be encrypted as >needed after the scheme rewrite. > >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
