Audit curl 8.22 TLS-SRP Removal in HTTPS Proxy Pipelines

#webdev

curl 8.22.0-rc3 is now available. The current manual marks the TLS-SRP options as deprecated and without functionality from 8.22.0. HTTPS proxy users should check for:

--proxy-tlsauthtype
--proxy-tlsuser
--proxy-tlspassword

Also search for the destination equivalents and libcurl options. This is not the removal of HTTPS proxies or ordinary HTTP proxy authentication; it is a compatibility change for TLS-SRP.

Inventory generated commands

Searching shell scripts is not enough. Inspect:

CI/CD variables and templates;
container entrypoints;
SDK and wrapper configuration;
job schedulers and runbooks;
dormant fallback paths;
generated command diagnostics.

Classify each match as active, generated, dormant, documentation-only, or false positive. Do not echo secret values into scan results.

Keep the three layers separate

HTTPS proxy certificate verification
        !=
TLS-SRP authentication to the proxy
        !=
HTTP proxy authentication (407 / Proxy-Authorization)

Removing TLS-SRP must not disable certificate or hostname checks. A successful HTTP authentication exchange does not prove the TLS-SRP layer still functions.

Capture a versioned baseline

For one authorized request, record:

{
  "curl_version": "deployed-version",
  "tls_backend": "backend-and-version",
  "proxy_route": "staging-eu",
  "address_family": "IPv4",
  "proxy_certificate_verified": true,
  "tls_version": "observed-version",
  "proxy_407_seen": true,
  "http_proxy_auth": "observed-method",
  "direct_fallback": false,
  "result": "expected-response-class"
}

Keep credentials out of the evidence record. Use a secret-manager reference or an incident-specific fingerprint.

Test rc3 in isolation

Release candidates are for testing, not production. Use a disposable container or staging worker and record its build features.

Run this matrix:

Case	Expected result
Valid certificate + valid credential	Uses the proxy and succeeds
Invalid credential	Fails authentication
Untrusted certificate	Fails TLS validation
Hostname mismatch	Fails closed
Proxy unavailable	Times out without direct retry
IPv4 and IPv6	Both follow the intended proxy policy

Do not stop at the positive case. A deliberately wrong credential that succeeds is stronger evidence of a bad test than a healthy route.

Migrate by intent

Proxy identity: retain strict TLS certificate and hostname validation.
Client authentication: use a proxy-authentication method supported by both sides, with credentials injected from a secret manager.
Mutual TLS requirement: configure client certificates explicitly according to the proxy policy.
No supported replacement: isolate the workload and use a reviewed, time-bounded exception while the owner implements an exit plan.

Do not use --insecure as a migration step. Do not enable direct fallback. Do not suppress an authentication error without proving the new path.

After curl 8.22.0 is formally released, repeat the matrix against the signed final build. RC results are useful preparation, not the production acceptance record.

Disclosure: I work with 98IP, a proxy service. This is a vendor-neutral engineering workflow. More proxy testing resources: https://en.98ip.com/?k=dev

DEV Community