openssl: bump minimum OpenSSL version to 3.0.0

[vszakats]

It also means that all supported OpenSSL versions and forks support
TLSv1.3 after this patch.

It reduces openssl.c size by more than 10%, or 400 LOC.

Ref: #18822

---

• align with deprecation plan and bump minimum to 3.0.0.
• old-linux relies on 1.0.2 support → try moving to GnuTLS, also needs fixing GnuTLS backend for that old (but supported) version → gnutls: fix building with older supported GnuTLS versions #18335
• Slackware 15.0 (in CI) requires 1.1.0. → disable SSL
• MS-DOS DJGPP also requires 1.0.2. It's an option to drop it completely or build without TLS. → GHA/non-native: drop MS-DOS jobs, requires OpenSSL 1.0.2 #18338
• bump to 3?
• fix typo in OpenSSL 1.1.1 check. (early data) → openssl: drop redundant version check #18333
• stop using OpenSSL 1.1.0 in AppVeyor CI → appveyor: drop testing with OpenSSL 1.1.0 #18341
• rebase on openssl: add and use HAVE_BORINGSSL_LIKE internal macro #18358 openssl: drop more legacy cruft #18359 openssl: add and use HAVE_OPENSSL3 internal macro #18360
• rebase on openssl: drop redundant HAVE_OPENSSL_VERSION macro #18367, drop pre-OpenSSL 3 non-fork logic.
• rebase on openssl: merge two #if blocks #18370.

[pps83]

is there a way to make easy local changes for those who prefer to stay with latest 1.1.1w? Any particular reason 1.1.1w misses something that's needed after this pr?

[bagder]

is there a way to make easy local changes for those who prefer to stay with latest 1.1.1w? Any particular reason 1.1.1w misses something that's needed after this pr?

We deliberately took away support for all OpenSSL versions before version 3 because OpenSSL themselves don't provide updates for those versions anymore, unless you are a paying customer of theirs.

If you are using the free OpenSSL version, version 1.x.x is now a security risk.

If you are paying OpenSSL for support for version 1 and thus not vulnerable, then I am happy to offer you a version of curl with support for OpenSSL 1.x - available with a support contract.

So, to get OpenSSL 1.x support:

1. get a support contract
2. revert the 69c89bf commit and fix the fallout (there might be a little more to it as well, but that's the major part)
3. stay on 8.17.0 and backport all (current and future) security patches to that version

[pps83]

OpenSSL version, version 1.x.x is now a security risk

imo anything other than 1.1.1 is a trainwreck afaik. Also, using all those 3+ versions increases all my binaries way too much for no apparent reason.
Only amazon's openssl fork seem to be free from openssl 3 curse, but I haven't tried to see if also explodes my binaries in size.

[bagder]

I tend to agree, but the v3 issues are OpenSSL's and the decision to drop v1 is also OpenSSL's.

[tumatanquang]

I tend to agree, but the v3 issues are OpenSSL's and the decision to drop v1 is also OpenSSL's.

So, does forcing the use of OpenSSL 3.0 or later actually fix any security issues or improve the performance of curl? Or does it just:

It reduces openssl.c size by more than 10%, or 400 LOC.

Clearly, the performance issues with OpenSSL 3.0 are nothing new or secret; HAProxy has already published a very detailed report: The State of SSL Stacks.
Mandating the use of OpenSSL 3.0 simply because OpenSSL has stopped supporting OpenSSL 1.1.1, instead of helping curl improve performance or fix security problems, is clearly a bad idea. The claim of reduces openssl.c size by more than 10%, or 400 LOC might not even improve curl's performance by 10%, but using OpenSSL 3.0 will inevitably tie the performance issues of OpenSSL 3.0 to curl, resulting in a performance decrease of at least 30%, similar to OpenSSL 3.0.

I hope you will conduct testing instead of blindly forcing upgrades, similar to how OpenSSL "not conducting testing itself due to a lack of hardware" (quoted from the report).

[dfandrich]

I hope you will conduct testing instead of blindly forcing upgrades, similar to how OpenSSL "not conducting testing itself due to a lack of hardware" (quoted from the report).

Are you volunteering to maintain the OpenSSL 1.x code in curl?

[bagder]

The OpenSSL project does not ship security updates for v1 anymore, so sticking to that version will be insecure. That's a primary reason.

[pps83]

The OpenSSL project does not ship security updates for v1 anymore,

... a very detailed report: The State of SSL Stacks.

After reading that report seems that openssl is a trainwreck project. That's probably the reason why there are a few major forks now maintained (libre, boring, aws). In my case I use libcurl for tiny small part (to make a few requests) and now I cannot update libcurl because my code will use whatever version of openssl is used. This seems like a common case imo

Basically, openssl is part of project already, and will not be changed just because of libcurl thinks some version is insecure.
Probably the most likely path forward is to revert this change in a fork and hope future changes won't break the fork :)

[tumatanquang]

The OpenSSL project does not ship security updates for v1 anymore, so sticking to that version will be insecure. That's a primary reason.

This is incorrect; not only OpenSSL 1.0.2, but also OpenSSL 1.1.1 still receives security updates (but that's premium support): OpenSSL Release Announcement for 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19, 1.1.1ze and 1.0.2zn.

Generally, even without maintenance, curl should only be forced to use OpenSSL 3.0 if it has at least one of the following:

• OpenSSL 3.0 improves curl's performance: Definitely not, as OpenSSL 3.0 itself is the biggest performance bottleneck.
• OpenSSL 1.1.1 causes security vulnerabilities for curl: No evidence of this.
• curl is forced to depend on OpenSSL 3.0, such as needing to use functions, code, etc. that are unique to OpenSSL 3.0, to improve/fix something: No, all we get is:

It reduces openssl.c size by more than 10%, or 400 LOC.
_{P/S: I apologize for repeatedly mentioning the commitment message, but it's just too "funny".}

At least for now, there is no compelling reason for curl to force the use of OpenSSL 3.0. Without a specific benefit, commit 69c89bf is a premature step.

[tumatanquang]

Are you volunteering to maintain the OpenSSL 1.x code in curl?

As of curl version 8.17.0, curl hasn't had any conflicts with OpenSSL 1.x, right? If there are no benefits, improvements, or conflicts, then what reason is there to rush to force curl to use OpenSSL 3.0?

[tumatanquang]

After reading that report seems that openssl is a trainwreck project. That's probably the reason why there are a few major forks now maintained (libre, boring, aws). In my case I use libcurl for tiny small part (to make a few requests) and now I cannot update libcurl because my code will use whatever version of openssl is used. This seems like a common case imo

Basically, openssl is part of project already, and will not be changed just because of libcurl thinks some version is insecure. Probably the most likely path forward is to revert this change in a fork and hope future changes won't break the fork :)

I'm using OpenSSL 1.1.1 to compile Apache httpd, which is a required part of the process as stated on the homepage:

Apache HTTP Server version 2.4.43 or newer is required in order to operate a TLS 1.3 web server with OpenSSL 1.1.1.

But in reality, according to the Complete ChangeLog for 2.4, it is still fully compatible and can be built using OpenSSL 1.0.x.

(Although there is no concrete evidence,) I think one of the leading reasons why projects (especially large ones) hesitate to upgrade to OpenSSL 3.0 is due to two main reasons: The lack of specific benefits (such as performance) / impacts (such as security) and the poor performance of OpenSSL 3.0.

[pps83]

(Although there is no concrete evidence,) I think one of the leading reasons why projects (especially large ones) hesitate to upgrade to OpenSSL 3.0 is due to two main reasons: The lack of specific benefits (such as performance) / impacts (such as security) and the poor performance of OpenSSL 3.0.

well, so far I only have reasons not to switch to ossl3 even if it matches 1.1.1 perf wise: suddenly, all my builds (I use static openssl) are much bigger with whatever new things they added and it seems like I cannot remove that junk. That's based on my personal projects where I don't want to have huge fat builds for no reason for small utils

As of curl version 8.17.0, curl hasn't had any conflicts with OpenSSL 1.x, right? If there are no benefits, improvements, or conflicts, then what reason is there to rush to force curl to use OpenSSL 3.0?

I'm not sure exactly what issue curl had with old one, but my guess is it's about http3/qic stuff. Afaik there was lots of work related to that in openssl3 and most of the work in curl seems to be happening in http3 (sorry if I'm wrong, just my casual opinion).

[pps83]

This is incorrect; not only OpenSSL 1.0.2, but also OpenSSL 1.1.1 still receives security updates (but that's premium support): OpenSSL Release Announcement for 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19, 1.1.1ze and 1.0.2zn.

wow, 1.1.1ze mentioned but they don't want to even publish it on their site wtf. I'm still stuck on 1.1.1w :)
Seems like they went from 1.1.1z to 1.1.1za ... 1.1.1ze. I guess I can take these from github.

EDIT: doesn't seem like it's on github. Weird, imo it's an extra effort not to tag that 1.1.1ze and not push to public repo. Crazy

[vszakats]

@tumatanquang:

The size reductions are stats I found interesting and included in the
message. It isn't the reason for this change. That said, it's 400+ lines
(and more via other PRs) of thick conditional code, with 3+ distinct
codepaths and alternate behavior. Each needing build- and runtests,
local tests with local builds, and a zoo of differences to actively
track to throughout maintenance and code updates.

It wasn't a coincidence that they worked previously, but the result of
effort and time contributed by humans.

Fact is, OpenSSL solely supports specific versions of v3+, without
a paid contract: https://openssl-library.org/roadmap/index.html

According to the page you linked:
https://openssl-library.org/post/2026-01-27-release-announcement/, the
OpenSSL 1.1.0 series is no longer receiving even paid support, 1.0.2
received around 20 patches since its last open source release, and 1.1.1
received 8, fixing 7 vulnerabilities in just the latest batch. These
patches are not open source, nor available to test or use for open
source and most other projects. Also meaning they are all vulnerable if
using the latest public releases.

curl supports a list of other TLS-backends, including 3 forks. None
suffering from the performance bottlenecks introduced by OpenSSL v3 and
all actively supported by those projects and curl alike. If your
use-case forces you to use OpenSSL anyway, and/or your use-case is
hitting these bottlenecks, you may consider reaching out to curl
commercial support for help: https://curl.se/support.html

For the state of OpenSSL and its forks, this page offers more links and
information: https://github.com/curl/curl/wiki/OpenSSL-forks

To remove bloat from OpenSSL 3, this talk gave some hints I've found
interesting: https://www.youtube.com/watch?v=Cv-43gJJFIs&t=300. Also
applied some of them to curl-for-win via curl/curl-for-win@1bb71ac.

[pps83]

To remove bloat from OpenSSL 3, this talk gave some hints I've found
interesting: https://www.youtube.com/watch?v=Cv-43gJJFIs&t=300.

From a quick look imo these guys intentionally create APIs that make it impossible to make small builds:

it would be AES_256_CBS instead of a string "AES-256-CBS" if it was made correctly imo.

For this reason you need to pass that giant list of options at build time to disable all the junk that gets pulled in due to such API design:

all that is ok for a single all-included build of openssl that's installed once system wide. Not so great if you use static build for some tiny thing.

For the state of OpenSSL and its forks, this page offers more links and information: https://github.com/curl/curl/wiki/OpenSSL-forks

from that list aws looks something I should switch to imo

[dfandrich]

> Are you volunteering to maintain the OpenSSL 1.x code in curl? As of curl version 8.17.0, curl hasn't had any conflicts with OpenSSL 1.x, right? If there are no benefits, improvements, or conflicts, then what reason is there to rush to force curl to use OpenSSL 3.0?

Lack of conflicts is only a tiny part of an excuse to support something. Keeping support around means more convoluted code that affects anyone trying to work and understand the source. It also means more effort in testing and chasing flaky tests that inevitably result. And to what effort? The only people who benefit are either running insecure software (which we actively discourage), spending effort in backporting security fixes themselves (and could do the same for curl), or are paying for extended support. I don't known which category you're in, but you're not volunteering to help to maintain that support in curl yet you expect us to do it for you, for free, something that, as far as we can tell, only helps you and your curl-using device/product/application and nobody else. At the same time, this would make our own work in maintaining curl for everyone else that much more difficult. That doesn't make much sense to me.

[pps83]

this page offers more links and information: https://github.com/curl/curl/wiki/OpenSSL-forks

Does curl work with aws-lc? it supports only ossl-3, but aws-lc is 1.1 based API. Do they identify as openssl-3, or curl won't work with them either?

[tumatanquang]

Does curl work with aws-lc? it supports only ossl-3, but aws-lc is 1.1 based API. Do they identify as openssl-3, or curl won't work with them either?

I tried building curl 8.18.0 with aws-lc, and it compiled normally. Curl seems to be hardcoded for openssl.
OpenSSL has many forks, but unfortunately, none of them support/work with the Apache HTTP Server, including aws-lc.

[tumatanquang]

To remove bloat from OpenSSL 3, this talk gave some hints I've found interesting: https://www.youtube.com/watch?v=Cv-43gJJFIs&t=300. Also applied some of them to curl-for-win via curl/curl-for-win@1bb71ac.

As many other researchers/feedback have shown, size is only a small part of the problem; it's not even as important as the fact that OpenSSL 3 uses more resources than OpenSSL 1.1.1 for the same operation. The main problem with OpenSSL 3 is performance.

Of course, with some simple/single-threaded operational checks, the performance degradation won't be obvious.

While both curl and OpenSSL are optional dependencies when compiling Apache, OpenSSL is more important and mandatory for using SSL/TLS.

For now, I will stick with curl 8.17.0 for compatibility with OpenSSL 1.1.1. There's no reason for me to "snag myself" (switch to OpenSSL 3) only to pay extra for something that was "originally free" (besides paying extra for OpenSSL premium support, now I need to pay even more for curl premium support - if I want to use OpenSSL 1.1.1 on the latest curl version, or pay extra to expand my server to meet the performance "expansion" of OpenSSL 3).

In short, the balance between cost, support, security, and performance is a "difficult" problem, but currently, for me, curl security < cost + support + performance. Curl 8.17.0 currently has no serious security vulnerabilities, while OpenSSL's premium support has addressed all security vulnerabilities.

[vszakats]

this page offers more links and information: https://github.com/curl/curl/wiki/OpenSSL-forks

Does curl work with aws-lc? it supports only ossl-3, but aws-lc is 1.1 based API. Do they identify as openssl-3, or curl won't work with them either?

AWS-LC works, yes. It identifies as AWS-LC:

curl 8.19.0-DEV (x86_64-pc-linux-gnu) libcurl/8.19.0-DEV AWS-LC/1.67.0 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2
Release-Date: [unreleased], security patched: test-patch
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt mqtts pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli ECH HSTS HTTPS-proxy HTTPSRR IDN IPv6 Largefile libz NTLM PSL SSL threadsafe UnixSockets zstd

https://github.com/curl/curl/actions/runs/22185835526/job/64159205992#step:44:32