2025-12-18

Author: squidadm

squid-users/2025-December.txt

@@ -946,3 +946,222 @@ Warning: I wish NOT to receive e-mail advertising to this address.
 Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
 I wonder how much deeper the ocean would be without sponges.
 
+From yves.martin at elca.ch  Thu Dec 18 14:39:43 2025
+From: yves.martin at elca.ch (Yves MARTIN)
+Date: Thu, 18 Dec 2025 14:39:43 +0000
+Subject: [squid-users] How to do transparent rewrite with https requests?
+In-Reply-To: <GVAP278MB000597CE77AB7A15B49DE4F8EE64A@GVAP278MB0005.CHEP278.PROD.OUTLOOK.COM>
+References: <GVAP278MB000597CE77AB7A15B49DE4F8EE64A@GVAP278MB0005.CHEP278.PROD.OUTLOOK.COM>
+Message-ID: <GVAP278MB0005AFBC6F08E5F2EFC4F20DEEA8A@GVAP278MB0005.CHEP278.PROD.OUTLOOK.COM>
+
+Hello,
+
+ 
+
+Thanks to your answer Alex,
+https://ml-archives.squid-cache.org/squid-users/2025-May/027560.html
+
+our team is running a Squid with HTTPS transparent interception and requests
+rewrite to cache services since months.
+
+ 
+
+With recent OpenSSL v3 introduction in distributions like Debian 13, Python
+3 requests or httpx modules (and probably soon more https client) now
+complains about missing AKID in squid mimic certificate with [SSL:
+CERTIFICATE_VERIFY_FAILED] certificate verify failed: Missing Authority Key
+Identifier.
+
+ 
+
+We are investigating by adding logging to src/ssl/gadgets.cc and probably
+the ssl_bump sequence configured (step1/bump step2/stare step3/bump)
+prevents certificate generation to include these extensions.
+
+ 
+
+Does this hypothesis sound plausible?
+
+Is there a way to work-around this new issue thanks to configuration, or
+patching?
+
+ 
+
+Thank you in advance for your help
+
+Best regards,
+
+Yves
+
+ 
+
+ 
+
+From: Yves MARTIN 
+Sent: Tuesday, May 27, 2025 4:37 PM
+To: squid-users at lists.squid-cache.org
+Subject: How to do transparent rewrite with https requests?
+
+ 
+
+Hello,
+
+ 
+
+My team expects to transparently rewrite requests through squid, replacing
+original URL/hostname by another target URL/host.
+
+ 
+
+Main objective is to redirect original HTTPS requests triggered by "docker
+pull alpine" to a local mirrored registry without obvious information in
+user client that the obtained image comes from mirror: original image
+location is preserved, no specific proxy or mirror configuration in docker
+client/daemon to set.
+
+ 
+
+To do so, we have used squid-urlrewrite and it works well for HTTP request,
+even if rewrite targets HTTPS URL.
+
+But when original request is HTTPS, connection still goes to original
+URL/hostname IP address
+https://github.com/rchunping/squid-urlrewrite/issues/3
+
+According to debug logs, the original request hostname is resolved to IP
+early and kept in internal context after squid-urlrewrite is invoked.
+
+ 
+
+Do you have recommendations how to implement such a rewrite? Any idea how to
+improve/fix current squid behavior?
+
+ 
+
+Thank you in advance for your help
+
+Best regards,
+
+Yves
+
+ 
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20251218/958ba867/attachment.htm>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: smime.p7s
+Type: application/pkcs7-signature
+Size: 6737 bytes
+Desc: not available
+URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20251218/958ba867/attachment.bin>
+
+From rousskov at measurement-factory.com  Thu Dec 18 16:36:38 2025
+From: rousskov at measurement-factory.com (Alex Rousskov)
+Date: Thu, 18 Dec 2025 11:36:38 -0500
+Subject: [squid-users] How to do transparent rewrite with https requests?
+In-Reply-To: <GVAP278MB0005AFBC6F08E5F2EFC4F20DEEA8A@GVAP278MB0005.CHEP278.PROD.OUTLOOK.COM>
+References: <GVAP278MB000597CE77AB7A15B49DE4F8EE64A@GVAP278MB0005.CHEP278.PROD.OUTLOOK.COM>
+ <GVAP278MB0005AFBC6F08E5F2EFC4F20DEEA8A@GVAP278MB0005.CHEP278.PROD.OUTLOOK.COM>
+Message-ID: <[email protected]>
+
+On 2025-12-18 09:39, Yves MARTIN wrote:
+
+> our team is running a Squid with HTTPS transparent interception and 
+> requests rewrite to cache services since months.
+> 
+> With recent OpenSSL v3 introduction in distributions like Debian 13, 
+> Python 3 requests or httpx modules (and probably soon more https client) 
+> now complains about missing AKID in squid mimic certificate with [SSL: 
+> CERTIFICATE_VERIFY_FAILED] certificate verify failed: Missing Authority 
+> Key Identifier.
+> 
+> We are investigating by adding logging to src/ssl/gadgets.cc and 
+> probably the ssl_bump sequence configured (step1/bump step2/stare 
+> step3/bump) prevents certificate generation to include these extensions.
+> 
+> Does this hypothesis sound plausible?
+
+AFAICT, your ssl_bump configuration (i.e. "step1/bump step2/stare 
+step3/bump") contains unreachable rules; your Squid does not do what you 
+think it does. I tried to explain below, but for more information about 
+ssl_bump processing, please see
+https://wiki.squid-cache.org/Features/SslPeekAndSplice
+
+
+Bugs notwithstanding, when dealing with a successful transaction, the 
+following configuration should _prevent_ Squid from mimicking any server 
+certificate properties because, in this particular case, Squid should 
+generate a fake server certificate _before_ talking to the server:
+
+     ssl_bump bump step1
+     # game over: the "bump" action is final and
+     # other ssl_bump rules/steps should be ignored
+
+
+> Is there a way to work-around this new issue thanks to configuration, or 
+> patching?
+
+For the fake certificate to mimic the server certificate, including 
+server certificate AKID property, Squid must see the server certificate 
+before generating the fake certificate. To see the server certificate 
+before generating the fake certificate, Squid must not bump the client 
+at step1 or step2; Squid must proceed all the way to step3 where Squid 
+receives server certificate.
+
+Bugs notwithstanding, the corresponding configuration is:
+
+     ssl_bump stare all
+
+... which may be spelled out as ...
+
+     ssl_bump stare step1
+     ssl_bump stare step2
+     ssl_bump bump step3
+
+
+That configuration (both succinct and spelled out variants) may be 
+incompatible with your other needs (as hinted in the exchange quoted 
+below). Pick your poison.
+
+
+HTH,
+
+Alex.
+
+
+> On 2025-05-27 12:19, Alex Rousskov wrote:
+>> On 2025-05-27 10:37, Yves MARTIN wrote:
+>> 
+>>> My team expects to transparently rewrite requests through squid, 
+>>> replacing original URL/hostname by another target URL/host.
+>>>
+>>> Main objective is to redirect original HTTPS requests triggered by 
+>>> ?docker pull alpine? to a local mirrored registry without obvious 
+>>> information in user client that the obtained image comes from mirror: 
+>>> original image location is preserved, no specific proxy or mirror 
+>>> configuration in docker client/daemon to set.
+>>>
+>>> To do so, we have used squid-urlrewrite and it works well for HTTP 
+>>> request, even if rewrite targets HTTPS URL.
+>>>
+>>> But when original request is HTTPS, connection still goes to original 
+>>> URL/hostname IP address 
+>>> https://github.com/rchunping/squid-urlrewrite/issues/3
+>>> According to debug logs, the original request hostname is resolved to 
+>>> IP early and kept in internal context after squid-urlrewrite is invoked.
+>> 
+>> In most cases, when bumping connections from a TLS client to Squid and 
+>> from Squid to TLS server, Squid "pins" (i.e. remembers) the 
+>> Squid-to-server connection and then (re)uses that pinned connection for 
+>> all requests received on the client-to-Squid connection.
+>> 
+>> I have not checked, but speculate that rewriting request target does not 
+>> trigger opening a new Squid-to-server TLS connection and re-pinning.
+>> 
+>> IIRC, a Squid that is configured to bump during SslBump step1 does not 
+>> pin. Such a configuration is rarely usable on a modern internet, but YMMV.
+
+
+

squid-users/2025-December/027725.html

@@ -13,7 +13,7 @@
    </style>
    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
    <LINK REL="Previous"  HREF="027724.html">
-   
+   <LINK REL="Next"  HREF="027726.html">
  </HEAD>
  <BODY BGCOLOR="#ffffff">
    <H1>[squid-users] squid stopped working after kernel update and reboot</H1>
@@ -25,7 +25,8 @@ <H1>[squid-users] squid stopped working after kernel update and reboot</H1>
     <P><UL>
         <LI>Previous message (by thread): <A HREF="027724.html">[squid-users] squid stopped working after kernel update and reboot
 </A></li>
-        
+        <LI>Next message (by thread): <A HREF="027726.html">[squid-users] How to do transparent rewrite with https requests?
+</A></li>
          <LI> <B>Messages sorted by:</B> 
               <a href="date.html#27725">[ date ]</a>
               <a href="thread.html#27725">[ thread ]</a>
@@ -72,13 +73,15 @@ <H1>[squid-users] squid stopped working after kernel update and reboot</H1>
 I wonder how much deeper the ocean would be without sponges.
 </PRE>
 
+
 <!--endarticle-->
     <HR>
     <P><UL>
         <!--threads-->
 	<LI>Previous message (by thread): <A HREF="027724.html">[squid-users] squid stopped working after kernel update and reboot
 </A></li>
-	
+	<LI>Next message (by thread): <A HREF="027726.html">[squid-users] How to do transparent rewrite with https requests?
+</A></li>
          <LI> <B>Messages sorted by:</B> 
               <a href="date.html#27725">[ date ]</a>
               <a href="thread.html#27725">[ thread ]</a>