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 mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
