DEPRECATE.md: TLS libraries without 1.3 support

[bagder]

Brought to the curl-library list on March 7, 2024. Discussed since then. No particular objections have been heard except the worry that apple device people might miss Secure Transport.

Once #13539 merges, we need to update the text.

[jan2000]

Hmm, I missed that. So it seems this no longer applies to mbedTLS and other have already raised concerns regarding Secure Transport, so let me object here for BearSSL.

BearSSL is (in my interpretation) a project that is focused on correctness over features. As a result of that it has a very low number of updates, I don't see that as a weakness or a sign of trouble per ce. To the contrary, combined with its low memory footprint, high portability and liberal license it makes BearSSL an option when developing for legacy/embedded systems that the other libraries do not compare to.

Though it would be very nice if Thomas would ever finish his planned work on TLS 1.3, I don't see what would be gained when libcurl drops support for this stable, carefully crafted SSL library that can provide perfectly fine TLSv1.2 connections just because it does not support TLS 1.3 yet.

I think that dropping support for a SSL backend only for the reason that it does not support TLS 1.3 only makes sense once TLS 1.2 is known to be broken. At moment of writing there is no sign of that.

However, there are known problems with older versions of TLS and certain ciphers. So if I might suggest, I think curl and internet users would benefit more if libcurl raised the security of its default SSL settings for all backends. With that I mean: by default require minimal TLS 1.2 and restrict the cipher suites to a set of known secure ciphers (hence my contributions regarding that).

[jay]

I missed that e-mail thread. I don't think we should drop TLS libraries just because they don't support TLS 1.3. I see a different problem which is users trying to build against old versions of TLS libraries that don't support TLS 1.3 even though the current version does. They are stuck on the old library version for whatever reason. For example, we probably have some users building libcurl against very old versions of OpenSSL. Or let's say the patch to use TLS 1.3 with mbedtls is accepted. Then what about those users with older mbedtls? It just seems too restrictive to me.

[bagder]

Since this is in effect two specific libraries we talk about I will address them individually

BearSSL

Basically not used. We never hear anyone with problems building with it nor using it or anything. It is a strong indication that this is used extremely rarely. For embedded use cases, we already support two libraries that are much more "on their toes": wolfSSL and mbedTLS.

I can repeat what I have said before: I don't believe you can write a network related library that is actually in use in the wild by multiple users, and not do a single bugfix/commit in over year and still have happy users. The latest BearSSL commit was done in February 2023. I advice people to avoid BearSSL because of this fact alone. Even if the author is a genius. There's not even a public bug tracker for this library.

Removing support for BearSSL is thus not likely to hurt many curl users. If any at all. But we also give them/him another year to adapt to these requirements.

Secure Transport

A library that has been deprecated by Apple themselves since several years back. Apple build their curl with libressl since years back. It seems unwise to recommend users to go with this solution.

From what I hear, people still use Secure Transport primarily for two reasons:

1. to use the native CA store on apple devices
2. to avoid having to use a third party dependency

The first item I am convinced could be fixed by just adding code. Either to curl, in similar vein to how we support the Windows native CA store, or by the TLS library.

The second one we can't fix unless we add support for their replacement library the "Network framework", but lots of people already linked with other TLS libraries even on the iOS family of devices simply because they need modern TLS features. Proving that it can be done so it's not a technical limitation.

I'm not saying someone can't add support for the network framework, but from what I have seen it seems like a library that is too high level, does not expose/provide socket access, uses threads and might be tricky to use: not a clean fit.

Ultimately, we push our users to better solutions by telling them to avoid Secure Transport.

require minimal TLS 1.2 and restrict the cipher suites

I am totally in favor of discussing and pushing for this. It is however a separate issue.

stuck on old library versions

Jay mentions old library versions above. I think that's a separate issue and I think we conflate the issues by mixing that topic into this thread.

I will not be afraid of taking the discussion of "pulling up the ladder" behind us to make it harder for users to shoot themselves in the foot by building curl with ancient and insecure TLS library versions. But again, that's a separate issue. Such users are also likely to use a ten year old curl release, and we can't prevent anyone from doing that.

we can help users do better

When we have lots of good alternatives, I think we can help users by tightening the ship and to gradually increase the requirements of which set of alternatives we support. To help our users to select good backends. When we slowly raise the bar for participating in team curl, all users of curl benefit.

[xquery]

+1 to dropping bear ssl (though it might be a useful test target, unclear).

+1 to preferring 1.3 TLS and consider deprecation of less then 1.3 at some later point ... by 'preference' I mean make it a preferred option when running ./configure and at runtime (perhaps an OPT/flag that is default set for 'enforce 1.3 TLS')

[MonkeybreadSoftware]

I build Openssl + SecureTransport and OpenSSL + Windows SecureChannel.

I just moved secure transport down the list in vtls to have curl prefer openSSL.
#13547

[danielgustafsson]

What if we turn this around and ask: What features do non-TLS 1.3 libraries bring which make them valuable for users? If we can identify such features then maybe the community can implement these such that they become available when using TLS 1.3 libraries. For SecureTransport it's being able to use credentials from the system Keychain, but what else is there?

[MonkeybreadSoftware]

1. Have a way to build curl without bringing additional dependencies. That is why we build slim curl versions, that use Windows Secure Channel and MacOS SecureTransport. Without 3 MB of OpenSSL libraries.
2. Get certificates from keychain and windows key storage. CURL could have a fallback to load these if no CA file is provided and use them for certificate verification.
3. And of course laziness: Build scripts have been setup a long time ago to build curl and someone would need to change them to use different TLS provider.

[Neustradamus]

To follow this important PR!

[regalialong]

To follow this important PR!

@Neustradamus FYI, Github offers a subscribe button in the sidebar if you want to follow issues:

This is nicer since it avoids cluttering up the issue with redundant cc comments.
I know I'm doing the same thing but I figured I might bright it up since Neu also commented on 13539

[Neustradamus]

@regalialong: I know but I do not received emails if I do not publish a comment.

[jan2000]

BearSSL

I can repeat what I have said before: I don't believe you can write a network related library that is actually in use in the wild by multiple users, and not do a single bugfix/commit in over year and still have happy users. The latest BearSSL commit was done in February 2023. I advice people to avoid BearSSL because of this fact alone. Even if the author is a genius. There's not even a public bug tracker for this library.

This is all under the assumption that few updates is an indication that there is something wrong. I would not dare to argue that a code base (that has any complexity) can be perfect, but is unimaginable that something can be carefully crafted and thus just needs very few fixes?

Basically not used. We never hear anyone with problems building with it nor using it or anything. It is a strong indication that this is used extremely rarely. For embedded use cases, we already support two libraries that are much more "on their toes": wolfSSL and mbedTLS.

Removing support for BearSSL is thus not likely to hurt many curl users. If any at all. But we also give them/him another year to adapt to these requirements.

I would indeed think that usage of BearSSL is more of a niche thing and is not providing TLS for libcurl/cli on many platforms (distro/os), if at all.

But for a developer working on embedded/legacy platforms who wants to use libcurl to make secure http requests it can be a good option. Looking at its low memory footprint, high portability and liberal license it may be for many cases the favourable option, if not the only.

While I can see one could put warning signs around BearSSL because of its low usage, I don't see why BearSSL needs to be removed, just because it does not support TLSv1.3 (yet). Is there anything broken with it? Is it a maintenance burden? Is it holding libcurl back in any way? What is actually gained by removing it?

[danielgustafsson]

I can repeat what I have said before: I don't believe you can write a network related library that is actually in use in the wild by multiple users, and not do a single bugfix/commit in over year and still have happy users. The latest BearSSL commit was done in February 2023. I advice people to avoid BearSSL because of this fact alone. Even if the author is a genius. There's not even a public bug tracker for this library.

This is all under the assumption that few updates is an indication that there is something wrong.

It's not removed only because it's potentially flawed and/or not maintained, but because the best TLS version it supports was standardized in 2008 and has multiple cipher vulnerabilities.

I would not dare to argue that a code base (that has any complexity) can be perfect, but is unimaginable that something can be carefully crafted and thus just needs very few fixes?

The burden of proof does not lie with those theorizing that a TLS library is likely to never achieve being bug-free, but those who claim otherwise. BearSSL 0.6, the latest version, is according to their own website "beta quality software" and their website has claimed that since 2019 (and possibly longer, I stopped looking at archive.org there). Let's stop pretending this is the ultimate pinnacle of perfect C code.

But for a developer working on embedded/legacy platforms who wants to use libcurl to make secure http requests it can be a good option.

If so then it would be good if those developers said so, rather than us guessing they exist. They have for sure been silent for a long time so far.

[bagder]

but is it unimaginable that something can be carefully crafted and thus just needs very few fixes?

Zero commits from February 2023 until now is not merely a very few fixes. It is literally no fixes at all for fifteen months. For a "beta" software.

Yes, it actually is unimaginable. It is totally not believable.

It is much more likely to be exactly what it looks like: a software component that is not maintained. Dropped. Abandoned. The fact that they don't have TLS 1.3 support is an additional indicator of this, since the world has to a high degree transitioned while BearSSL has not.

And that's fine. People can do what they want with their own open source projects, but we have no obligation to keep the support for them in curl.

[ecnepsnai]

I fully support removing SecureTransport from future curl versions, despite the fact that I am currently using this exact combination. I will be moving to using libssl instead.

Certificate validation can still be achieved without using deprecated frameworks, so there's no reason to keep supporting this legacy library. Especially, as Daniel has shown, Apple themselves have moved on.

[hovercats]

Id just like to add that there is people using BearSSL with curl. Oasis Linux uses bearssl as its main ssl/tls implementation (however, its a WIP. see oasislinux/oasis#14).

However, I do agree that its.. suboptimal that bearssl does not support tls-1.3. Ive already encountered websites which either breaks on some domains, or outright blocks non tls-1.3 connections. (Repology being one).

for what its worth, this is atleast another voice for bearssl support in libcurl.

[danielgustafsson]

Anyone distribution who wish to cling to software of the past can maintain a local patch to add BearSSL support back in, it will be trivial given the archicture of libcurl.

[bagder]

@hovercats you then have a whole year to:

1. fix BearSSL or
2. make someone else fix BearSSL or
3. switch to another TLS backend or
4. decide to patch-add support once removed or
5. stick to an older libcurl version or
6. do something else

...