RCurl can only use obsolete transport security
arencambre opened this issue · comments
This is related to #37 but more general.
If you connect to a site that doesn't permit obsolete transport security, you will get an error. By "obsolete transport security", I mean any transport-security protocol other than TLS 1.2 or 1.3 (more info).
The error can reliably be reproduced with this trivial example, such as RCurl::getURL("http://www.arencambre.com/").
The below sites will produce an error. They are verified at https://gf.dev/tls-scanner as not supporting anything lower than TLS 1.2:
Hi
The issue here is the underlying version of libcurl that is being used with the RCurl package on your machine.
When I check each of these URLs, there is no issue.
So, as usual, you'll have to indicate the configuration of your machine, i.e. the output of each
sessionInfo()
curlVersion()
libcurlVersion()
Are you using Windows?
Thank you, @duncantl . The output of those commands is here: output.txt. I am on Windows 10, fully patched, fully updated.
I do see that curlVersion() says it's using cURL 7.40.0, from 2015, which uses OpenSSL 1.0.0. Wow. But libcurl is using 7.64.1, a more recent release,
I found R\win-library\4.0\RCurl\libs\x64\RCurl.dll and R\win-library\4.0\RCurl\libs\i386\RCurl.dll before opening this issue, but those DLLs don't have version info embedded in them, at least not in a standard way that is visible to Windows Explorer:
(It's not your fault! A decision of cURL's maker.)
How do I find where curl.exe is coming from? Maybe I simply swap that out with a newer one? If I go to my command prompt, I have a curl.exe in the path, but it's 7.55.1.
I reinstalled from bare metal and still get the same error. Here's a new output of the commands you requested: output (bare metal).txt
Which curl.exe does RCurl use?
As a double check, the curl.exe in my Windows path is at c:\windows\system32. It loads pages just fine. For example: >curl --get https://www.arencambre.com/ pulls the page fine.
I do have an .Renviron file in my Documents directory, and it has one line: PATH="${RTOOLS40_HOME}\usr\bin;${PATH}". That added path belongs to C:\rtools40\usr\bin, which also has a curl.exe. That curl.exe also works fine.
There is no curl.exe anywhere in my R library files. Based on my searches, I can only guess you are using the RCurl.dll that is included with the RCurl library?
I ran Process Monitor and filtered it to only report on paths that include curl, then I ran getURL() from a fresh copy of R. It looks like the curl logic comes from RCurl.dll. Therefore, you are likely including an obsolete version of curl in that DLL.
The log from Process Monitor: Logfile.CSV.txt (the file is actually a CSV; Github doesn't allow those extensions)
Would be great to see this fixed. We use SPARQL which depends on this library.
I found what seems to be a one off compile here that seems to have a later version of OpenSSL that supports TLS
http://www.omegahat.net/R/bin/windows/contrib/3.5.1/
@duncantl can whatever was done here be put into CRAN for Windows?
UNIX & macOS are not impacted by this issue
Hi
The issue here is the underlying version of libcurl that is being used with the RCurl package on your machine.
When I check each of these URLs, there is no issue.
So, as usual, you'll have to indicate the configuration of your machine, i.e. the output of eachsessionInfo()
curlVersion()
libcurlVersion()
Are you using Windows?
Yes, this problem is only encountered with those who are using Windows.
Here are the configurations of troubled machine:
curVersion()
$age
[1] 3
$version
[1] "7.40.0"
$vesion_num
[1] 468992
$host
[1] "x86_64-pc-win32"
$features
ssl libz ntlm asynchdns spnego largefile idn sspi
4 8 16 128 256 512 1024 2048
$ssl_version
[1] "OpenSSL/1.0.0o"
$ssl_version_num
[1] 0
$libz_version
[1] "1.2.8"
$protocols
[1] "dict" "file" "ftp" "ftps" "gopher" "http" "https" "imap" "imaps" "ldap" "pop3" "pop3s"
[13] "rtmp" "rtsp" "scp" "sftp" "smtp" "smtps" "telnet" "tftp"
$ares
[1] ""
$ares_num
[1] 0
$libidn
[1] ""
libcurlVersion()
[1] "7.59.0"
attr(,"ssl_version")
[1] "OpenSSL/1.0.2n (WinSSL)"
attr(,"libssh_version")
[1] "libssh2/1.8.0"
attr(,"protocols")
[1] "dict" "file" "ftp" "ftps" "gopher" "http" "https" "imap" "imaps" "ldap" "ldaps" "pop3"
[13] "pop3s" "rtsp" "scp" "sftp" "smtp" "smtps" "telnet" "tftp"
BTW, the underlining RCurl version is 1.98-1.2.
I encountered this issue today. To workaround it I replaced RCurl.dll with the version in the zip file that @obkhan linked.