[squid-users] How to do transparent rewrite with https requests?

[Alex Rousskov]

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.