There may be plenty of oldcode around
It's easy to forget that the world is more than desktop users running the latest release and (relatively) new hardware.
A deprecation warning at compile makes sense. So would changing symbol names or forcing explicit action at compile to get the old protocols. -DCURL_INCLUDE_INSECURE_TLS , set CURL_USE_INSECURE_TLS_VERSION.
However, I'm more worried about the many embedded devices with un-upgradable firmware. Disabling or behind the scenes switching to an unsupported protocol bricks such devices. For example, I have perfectly good (and expensive) UPSs that fall in that category. Replacing (and recycling) batteries every decade or so is both cheaper and better for the environment. E-waste is a real problem. There are many other examples in everything from home appliances to industrial controls. In the latter case, there are often no viable replacements, and the costs of replacing the associated machinery can be unlimited.
The security issues with TLS 1.0/2 in these environments are typically addressed at a firewall/VLAN level.
While it's shameful that vendors abandon their products, curl's choices will not make any difference to them - except maybe force some people to spend money on new hardware. Or stop updating libcurl, which "solves" the local device problem, but exposes the user when the same libcurl is also used to talk to the open web.
So by all means, make it difficult to access insecure protocols, change the default at compile, force some explicit action to acknowledge the risks. But bricking hardware by making it impossible to access them will not make you any friends....
Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM's views, if any, on the matters discussed. On 11-Jul-25 02:07, Christian Schmitz via curl-library wrote:
On 10. Jul 2025, at 23:23, Daniel Stenberg via curl-library<curl-library@lists.haxx.se> wrote: Right, For all reasons, see RFC 8996 =>https://datatracker.ietf.org/doc/html/rfc8996 2. We give everyone six more months to adapt, protest or similar and then in March 2026 we make libcurl return error if asked to use anything lower than 1.2There may be plenty of old code around, that explicitly puts in CURL_SSLVERSION_TLSv1_0 or CURL_SSLVERSION_TLSv1_1. >From a time where we had SSL v3 as default and we wanted to get better TLS 1.0 or 1.1. I would suggest to allow it, output a warning in the debug log "TLS 1.0 no longer available, using TLS 1.3 instead." and switch to TLS 1.3. If some old code requests CURL_SSLVERSION_TLSv1_0 or CURL_SSLVERSION_TLSv1_1, you handle it like CURL_SSLVERSION_TLSv1 and use 1.3 with 1.2 as fallback. Greetings Christian — See you at the EngageU conference 9th to 11th November 2025 in Antwerpen, Belgium https://engageu.eu/
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
