curl 8.22 Preview: Audit HTTPS Proxy TLS-SRP Before It Stops Working

curl 8.22.0 reached its third release candidate on 26 August 2026, with the final release scheduled for 2 September. The current curl manual already marks the TLS-SRP command-line options as deprecated and without functionality from 8.22.0. For HTTPS proxy workflows, the affected options include --proxy-tlsauthtype, --proxy-tlsuser, and --proxy-tlspassword.

This is a narrow compatibility change, not the removal of HTTPS proxy support and not the removal of ordinary HTTP proxy authentication. Teams using certificate-validated HTTPS proxies, Basic, Digest, Negotiate, or another supported proxy-authentication method should not assume they are affected. The risk is concentrated in configurations that explicitly request TLS-SRP, hide those options inside wrappers, or rely on a build-time feature that operators no longer remember.

What is changing

TLS-SRP is a TLS authentication mechanism based on a username and password. In curl, it could be selected for a destination TLS connection with --tlsauthtype SRP or for the TLS connection to an HTTPS proxy with --proxy-tlsauthtype SRP. The corresponding user and password options supplied the SRP credentials.

curl's project announcement explained that TLS-SRP does not work with TLS 1.3 or QUIC and is virtually unused. In the 8.22 documentation, the related options remain visible so old configurations can be identified, but they are documented as having no functionality from 8.22.0.

That distinction matters operationally. A script may still parse successfully while the intended authentication behavior no longer occurs. A migration test must therefore prove the connection path and authentication outcome, not merely confirm that the process started.

Do not confuse three authentication layers

An HTTPS proxy connection can involve separate controls:

Removing TLS-SRP does not mean disabling certificate verification. Continue verifying the proxy certificate and hostname. It also does not mean that --proxy-user or supported --proxy-auth methods disappear. Keep each layer explicit in the migration record so a working HTTP authentication test is not mistaken for proof that the old TLS-SRP path survived.

Find affected configurations before upgrading

Search source repositories, deployment templates, CI variables, container entrypoints, job schedulers, runbooks, and generated commands for both command-line and libcurl names.

Start with these CLI terms:

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

Then inspect libcurl code for the equivalent TLS authentication options. Do not print matched passwords into CI logs. Report only the file, configuration owner, environment, option name, and a secret reference identifier.

Classify every match:

• Active: executed in current production, staging, or scheduled workloads.
• Generated: produced by a wrapper or SDK even if not visible in the final runbook.
• Dormant: retained in an image, sample, or fallback path that can still be activated.
• Documentation only: appears in prose or tests and cannot affect a connection.
• False positive: the term is present but is not a curl or libcurl setting.

An inventory is incomplete until an owner confirms whether the affected route is still required.

Establish the current baseline

Before changing curl, reproduce one authorized request with the currently deployed version and the exact proxy path. Capture:

• curl and libcurl versions;
• TLS backend and its version;
• proxy scheme, hostname label, port, and requested region;
• resolved proxy address and IP family;
• proxy certificate subject, issuer, validity window, and verification result;
• negotiated TLS version and cipher;
• whether a 407 challenge occurred and which HTTP proxy-authentication method was selected;
• final response class, exit code, total time, and UTC timestamp.

Redact credentials and tokens. Store a salted fingerprint or secret-manager reference when you need to prove that the same test identity was used.

Run the baseline through an environment you control. A successful request to an unrelated public target does not prove that the enterprise HTTPS proxy, authentication policy, and certificate trust path are correct.

Test the 8.22 release candidate safely

The curl project states that release candidates are for testing, not production. Use rc3 in an isolated build, disposable container, or staging worker.

1. Verify the archive or package through your approved software-supply process.
2. Record the build features and TLS backend; do not assume the test binary matches production.
3. Run the old configuration unchanged and capture the actual connection behavior.
4. Remove the TLS-SRP options and run the intended replacement configuration.
5. Test a correct credential, an incorrect credential, an untrusted proxy certificate, a hostname mismatch, and a direct-connection control.
6. Compare the proxy-resolved address, TLS negotiation, 407 flow, exit IP, response class, and timings with the baseline.
7. Confirm that no wrapper silently retries without the proxy after a failure.

The negative tests are essential. If a deliberately wrong proxy credential still succeeds, the request may have bypassed authentication, reused a cached connection, inherited another credential, or connected directly.

Choose the replacement by requirement

Do not replace TLS-SRP with a random curl flag. Ask what the old configuration was intended to accomplish.

If the requirement is to verify the HTTPS proxy, use normal TLS certificate and hostname validation with an approved trust store. If client-certificate authentication is required, configure it explicitly according to the proxy's supported policy.

If the requirement is to authenticate at the HTTP proxy layer, use a proxy authentication method supported by both curl and the proxy, delivered through a secret manager rather than a command visible in process listings.

If the requirement is to protect a credential from interception, HTTPS transport to the proxy and strict certificate validation remain necessary. Authentication method selection does not replace transport verification.

If the service truly depends on TLS-SRP and has no supported replacement, do not ship an unreviewed workaround. Document the dependency, isolate the affected workload, engage the proxy or application owner, and keep the currently supported curl version only under an approved, time-bounded exception with compensating controls.

Build an acceptance matrix

Use separate pass criteria for security and routing:

Record a packet-free evidence summary when full packet capture would expose customer data. Verbose curl output may contain headers and connection details, so sanitize it before sharing.

Deployment and rollback

Promote the change by workload group rather than replacing every curl binary simultaneously. Start with synthetic probes, then low-risk traffic, then a controlled percentage of production.

Define rollback signals before deployment: proxy connection failures, certificate errors, unexpected 407 rates, direct-route detections, exit-region drift, or material latency regression. The rollback package must include the previous binary or image digest and the previous configuration, without restoring an expired secret.

After final curl 8.22.0 is released, repeat the tests against the signed production release. Release-candidate results reduce risk but do not replace final-version acceptance.

For related checks, use the 98IP guides on diagnosing proxy 407 authentication failures, sanitizing proxy diagnostic archives, and testing curl IPv6 scope behavior.

Migration checklist

• [ ] Search completed for all six CLI TLS-SRP options and equivalent libcurl settings.
• [ ] Active, generated, dormant, documentation-only, and false-positive matches classified.
• [ ] Current curl version, TLS backend, proxy route, and authentication baseline recorded.
• [ ] Release candidate tested only in an isolated environment.
• [ ] Correct and incorrect credentials both produced the expected result.
• [ ] Certificate, hostname, timeout, IPv4, IPv6, and direct-fallback controls passed.
• [ ] Replacement matches the original requirement instead of merely suppressing an error.
• [ ] Credentials and verbose logs were redacted.
• [ ] Canary, rollback thresholds, owner, and exception expiry are documented.
• [ ] Final 8.22.0 build will be retested after release.

FAQ

Does curl 8.22 remove HTTPS proxy support?

No. The announced change removes TLS-SRP support. HTTPS proxy transport, certificate validation, and supported HTTP proxy-authentication methods are separate capabilities.

Will curl necessarily fail when an obsolete TLS-SRP option is present?

Do not rely on a parse failure. The current manual describes the options as deprecated and without functionality from 8.22.0. Verify actual connection and negative-test behavior.

Is rc3 safe for production?

The curl project explicitly says release candidates are for testing and verification, not production use. Retest with the final signed release.

Can we keep the old curl version indefinitely?

That creates a growing maintenance and security liability. Use a time-bounded exception only when no replacement exists, assign an owner, and track an exit plan.

Compliance note

Test only proxies, credentials, destinations, and networks you are authorized to use. Keep secrets out of command history and process listings, minimize diagnostic data, restrict access, and document retention. A compatibility migration must not weaken certificate validation, enable direct fallback, or conceal an authentication failure.

Research note: curl announced 8.22.0-rc3 on 26 August 2026 and schedules the final release for 2 September 2026. The current curl manual documents the TLS-SRP options as deprecated and non-functional from 8.22.0. External research locations are retained only in the internal operations record.