Possible to figure out if CURL is using SSL (FreeBSD 13.5-RELEASE-p11 & curl-8.17.0)

Aknot

Aknot

Curl 8.18 seems to have dropped support for OpenSSL versions below 3.x.

Code: 
checking for OpenSSL >= v3... configure: error: OpenSSL 3.0.0 or upper required.

Is there a way to figure out if CURL is using the SSL option on our system, running FreeBSD 13.5-RELEASE-p11?
We have tried the lsof command: lsof -i :443 | grep libcurl but that doesn't give us something.

Our server is running latest latest Magento on Apache with MariaDB among othe things.

Thanks,
 
By default, version 13.x depend on WolfSSL instead of OpenSSL.

ftp/curl/Makefile
OPTIONS_DEFAULT_13= WOLFSSL

Initially, it was modified to depend on gnutls, but as usual, it was a matter of commit, revert, commit.
 
fyi,
Code: 
ldd /usr/local/bin/curl | grep -i ssl
    libssl.so.17 => /usr/local/lib/libssl.so.17 (0x39a21bc54000)
root@myfreebsd:~ # pkg which /usr/local/lib/libssl.so.17
/usr/local/lib/libssl.so.17 was installed by package openssl35-3.5.5
 
Thanks everyone!

I'm an "end user" and not sure what to do here.

We're on the FreeBSD 13.x "built in" OpenSSL, since I was told that installing a newer OpenSSL versions from ports, could cause problems, and I don't like problems.

I tried to switch to gnutls by running make config, but getting this instead:

Code: 
====> You cannot select multiple options from the SSL radio
=====> Only one of these must be defined: GNUTLS OPENSSL
*** Error code 1
...

I'm guessing I'm stuck on curl-8.17.0 😕
 
Aknot said:
We have tried the lsof command: lsof -i :443 | grep libcurl but that doesn't give us something.
Click to expand...
What gave you the idea to run that command? It doesn't make very much sense to me, as curl does not usually listen itself on any port.

We would use curl -V to show the compilation options:
Code: 
π curl -V
curl 8.4.0 (amd64-portbld-freebsd13.2) libcurl/8.4.0 OpenSSL/1.1.1t zlib/1.2.13 libpsl/0.21.2 (+libidn2/2.3.4) libssh2/1.11.0 nghttp2/1.58.0
Release-Date: 2023-10-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets
 
atax1a said:
What gave you the idea to run that command? It doesn't make very much sense to me, as curl does not usually listen itself on any port.
[/code]
Click to expand...
I tried to find a way to see if curl was using the OpenSSL option in my system.
I'm might need to move to FreeBSD 15.x sooner than I hoped for.

Thanks,
 
Alain De Vos said:
I have in make.conf:
DEFAULT_VERSIONS+=ssl=openssl35
Click to expand...
This is probably one of your better, if not the best, solution. However, this will affect other port builds.

Given that FreeBSD 13 retires at the next month upgrading to FreeBSD 14 or 15 would be a better, and in the long run, a more secure option. I have a number of customers/clients still running old unsupported Linux. I've heard all the "reasons" to run old unsupported software. Not a good idea. It's time to upgrade.
 
Aknot said:
Thanks everyone!

I'm an "end user" and not sure what to do here.

We're on the FreeBSD 13.x "built in" OpenSSL, since I was told that installing a newer OpenSSL versions from ports, could cause problems, and I don't like problems.

I tried to switch to gnutls by running make config, but getting this instead:

Code: 
====> You cannot select multiple options from the SSL radio
=====> Only one of these must be defined: GNUTLS OPENSSL
*** Error code 1
...

I'm guessing I'm stuck on curl-8.17.0 😕
Click to expand...
You'll potentially be mixing OpenSSL from base and ports, if you have ports that incorrectly links with both for some reason (and indirectly from dependencies) you may up end with compilation and/or runtime issues. In theory this shouldn't be an issue but its rarely tested with the full tree to my knowledge. In many cases using a different library be it GnuTLS, Mbed TLS or wolfSSL is usually fine but there may be some differences in functionality of consumers in the final library / binary compared to OpenSSL due to other libraries being less popular and therefore not having the same featureset implemented even if the library/ies may support all required features. Some applications may also only supports a specific library.
Rough estimates using grep shows the following usage by default and/or only supported library in tree:
~1100 base / OpenSSL (probably more)
~130 GnuTLS
~10 Mbed TLS
~< 5 wolfSSL if you count flavours/variants

Charlie_
You also forgot to mention that it's now broken on 13.5 (i386) using default options (WolfSSL)
 
Last edited:
The short and most simple fix on is to use GnuTLS as far as curl is concerned (especially if you're on i386 given the above), going with compatible options and curl's own unit tests it's the most compatible alternative. I doubt you'll notice a difference on your box(es).
In worst case there's payed support available from curl devs if you really need legacy OpenSSL support.

There are some "quirks" or in this case less obvious conflictions with the ports option management in some cases.

Edit: You probably have libssh2 support enabled which causes an endless loop. I don't know why this is disabled as it works fine with GnuTLS as backend and libssh2 (which links to the old version of OpenSSL)

Code: 
curl --insecure scp://127.0.0.1/home/diizzy/testfile.zip -u diizzy --output testfile.zip
Enter host password for user 'diizzy':
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
100  69039 100  69039   0      0 798.3k      0                              0
100  69039 100  69039   0      0 796.9k      0                              0

curl --insecure sftp://127.0.0.1/home/diizzy/testfile.zip -u diizzy --output testfile2.zip
Enter host password for user 'diizzy':
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
100  69039 100  69039   0      0 522.8k      0                              0
100  69039 100  69039   0      0 521.9k      0                              0

curl --version
curl 8.19.0 (FreeBSD) libcurl/8.19.0 GnuTLS/3.8.12 zlib/1.3.1 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.68.0
Release-Date: 2026-03-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt mqtts pop3 pop3s rtsp scp sftp smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM PSL SSL SSLS-EXPORT threadsafe TLS-SRP UnixSockets zstd

uname -a
FreeBSD fooi386 13.5-RELEASE FreeBSD 13.5-RELEASE releng/13.5-n259162-882b9f3f2218 GENERIC i386

If you want (scp/sftp) libssh2 support you need remove this line https://cgit.freebsd.org/ports/tree/ftp/curl/Makefile#n81 (at least) or you could also revert the tree if you're using git (as if writing this works fine but may be unsuitable later on as depdencies might be updated)
Code: 
cd /usr/ports
git reset --hard HEAD daabb39144929a8e8498b5f33c157e5173857fee
Install curl
Go back up to recent version of tree
Code: 
git pull --ff-only
 
diizzy said:
Edit: You probably have libssh2 support enabled which causes an endless loop. I don't know why this is disabled as it works fine with GnuTLS as backend and libssh2 (which links to the old version of OpenSSL)
Click to expand...
Thanks for all your input and energy on this, much appreciated! 🤝
 
You must log in or register to reply here.
Back
Top