Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Time to deprecate TLS 1.0 and 1.1 ?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Fri, 11 Jul 2025 05:52:41 -0400
> 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_at_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.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/
>
>
>
Received on 2025-07-11
Date: Fri, 11 Jul 2025 05:52:41 -0400
> 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_at_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.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
- application/pgp-signature attachment: OpenPGP digital signature