Re: Time to deprecate TLS 1.0 and 1.1 ?

Timothe Litt via curl-library <[email protected]> Fri, 11 Jul 2025 05:52:41 -0400
Newsgroups	gmane.comp.web.curl.library
Message-ID	<[email protected]>
> 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<[email protected]> 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.2
> There 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/
>
>
>

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
OpenPGP_signature.asc (application/pgp-signature, 495 B)