A TLS Forward-Proxy Listener in Squid 6.13

Squid 6.13 can accept forward-proxy requests over TLS when built with GnuTLS or OpenSSL. This protects the client-to-proxy link without intercepting the HTTPS destination's separate session.

1. Obtain a certificate for the hostname clients will use to reach Squid. Restrict its private key to the service identities that need it.
2. Add a TLS listener with your assigned address and real certificate paths:

https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Keep the client allowlist and destination restrictions and the authentication policy. The listener does not grant access. It also leaves an existing http_port active; remove or restrict that older listener if all client connections must use TLS. No accelerator, interception or certificate-generation mode is required.

Parse the configuration before reloading the intended service. A parser check validates structure and certificate loading, not network reachability. After a successful reload, request through the TLS endpoint from an allowed client:

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

Use the actual proxy hostname and approved CA file. A publicly trusted proxy certificate may need no custom bundle. --proxy-cacert configures proxy trust and leaves destination verification separate; retain both checks.

Inspect the actual listener and certificate name, then test a controlled denied source as well. Successful parsing alone cannot establish client trust or the access boundary.