TLS: drop support for TLS-SRP

The options will simply do nothing.

Closes #21965
This commit is contained in:
Daniel Stenberg 2026-07-04 12:19:47 +02:00
parent d169ad68fa
commit 69ac867f98
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
63 changed files with 133 additions and 932 deletions

View file

@ -55,9 +55,7 @@ Examples:
Different configurations produce different keys which is what curl needs when
handling SSL session tickets.
One important thing: peer keys do not contain confidential information. If you
configure a client certificate or SRP authentication with username/password,
these are not part of the peer key.
One important thing: peer keys do not contain confidential information.
Peer keys carry the hostnames you use curl for. They *do* leak the privacy of
your communication. We recommend to *not* persist peer keys for this reason.
@ -76,10 +74,9 @@ its own peer_key and calls into the cache. The cache then looks for a ticket
with exactly this peer_key. Peer keys between proxy SSL filters and SSL
filters talking through a tunnel differ, as they talk to different peers.
If the connection filter wants to use a client certificate or SRP
authentication, the cache checks those as well. If the cache peer carries
client cert or SRP auth, the connection filter must have those with the same
values (and vice versa).
If the connection filter wants to use a client certificate, the cache checks
those as well. If the cache peer carries client certs, the connection filter
must have those with the same values (and vice versa).
On a match, the connection filter gets the session ticket and feeds that to
the TLS implementation which, on accepting it, tries to resume it for a