System libraries in MacOS: openssl, libressl - error on download.file()/curl_download()/htrr::GET()

[pbchl]

On MacOS Monterey, I am running into an SSL error when using download.file() on the czso.cz domain. This is probably caused by the version of LibreSSL shipped with Monterey. The same occurs when using {curl} and {httr}.

The error I get is

Error in open.connection(3L, "rb") : 
  error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length

Reprexes are documented in a github issue on the repo of an affected package.

Web browsers have no problem with the domain, and the issue also occurs when using curl in the zsh shell, so it it caused by a system library. Using HTTP instead of HTTPS does not help.

From what I can tell, this only occurs on a few domains, but unfortunately the one I am dealing with is a whole country's statistics provider, and I maintain a package that depends on downloading data from it. This has also manifested in CRAN checks of packages depending on this host.

Elsewhere, people ran into the SSL issue on other domains, e.g. here in R or in the homebrew CI system on Github.

I have reported to both Apple and the admin of the domain (though the domain seems fine when tested on ssllabs.com).

The underlying issue is that R relies on the system-provided SSL library, which Apple does not in fact recommend linking to dynamically:

• We discourage folks from using the OpenSSL dynamic libraries that are built in to macOS because binary compatibility concerns prevent us from updating them. You can watch WWDC 2011 Session 212 Next-Generation Cryptographic Services for more details on this.
• If you feel the need to use OpenSSL (for example, if it has features that are missing from our APIs, or you’re using some other library that depends on OpenSSL), you should feel free to compile your own version of the code into your app. You can statically or dynamically link this; it’s really up to you.
• Likewise for the various forks of OpenSSL.

This underlying issue has been discussed on R-devel in 2020, in the context of a slightly different SSL issue, but specifically with respect to OpenSSL/LibreSSL on MacOS. The suggestion was raised to compile R with statically linked OpenSSL:

I.e., there is a case to be made that we might want to link openSSL rather than LibreSSL.

Given (1) we are seeing this again, (2) Apple is unlikely to fix this given the scarcity of the issue, and (3) it seems Apple recommends against dynamically linking to libraries it ships:

1. is there a way around this without having the user install a different version of OpenSSL and jumping through the various hoops of getting the right version onto PATH etc.?
2. what would be the way forward to prevent this happing in R? Is r-devel/r-help the only place to suggest this change?

[tbp]

I have been struggling with this issue for the past couple of days. I found one work around.
https://groups.google.com/g/r-sig-mac/c/is0-QPaTjx8
By setting the environment variable for cURL SSL backend to "secure-transport" prior to loading packages seems to do the trick.
Just add the code below at the top of your script.

Sys.setenv(CURL_SSL_BACKEND="secure-transport")