[Rd] r-project.org SSL certificate issues

Bob Rudis bob @end|ng |rom rud@|@
Wed Aug 19 20:34:01 CEST 2020 

Translation subdomain is also expired.

https://rud.is/r-project-cert-status/

> On Aug 19, 2020, at 13:35, Toby Hocking <tdhock5 using gmail.com> wrote:
> 
> Hi win-builder certificate expired on Aug 15. My student on the other side
> of the world is also seeing this problem so I think it needs to be fixed...
>> download.file("https://win-builder.r-project.org", "/tmp/wb.html")
> trying URL 'https://win-builder.r-project.org'
> Error in download.file("https://win-builder.r-project.org", "/tmp/wb.html")
> :
>  cannot open URL 'https://win-builder.r-project.org'
> In addition: Warning message:
> In download.file("https://win-builder.r-project.org", "/tmp/wb.html") :
>  URL 'https://win-builder.r-project.org/': status was 'Peer certificate
> cannot be authenticated with given CA certificates'
>> 
> 
> On Wed, Jun 10, 2020 at 2:40 AM Gábor Csárdi <csardi.gabor using gmail.com> wrote:
> 
>> My (also not expert) understanding is that there is nothing insecure about
>> alternative certificate chains at all. All browsers and macOS's built in
>> SSL library (secure transport) support them properly. OpenSSL and LibreSSL
>> were/are simply broken. This was not such a big issue so far, but now that
>> some old long lived certificates are expiring, it is increasingly an issue.
>> 
>> FWIW it is possible to build libcurl on macOS without any external SSL
>> library, so OpenSSL and LibreSSL are not needed at all. (Unfortunately the
>> libcurl build that comes with most (all?) macOS versions does use
>> LibreSSL.) The R installer could link to such a static libcurl library on
>> macOS, and that would solve the issue for macOS. Whether it should, that's
>> another question.
>> 
>> Gabor
>> 
>> On Wed, Jun 10, 2020 at 9:56 AM peter dalgaard <pdalgd using gmail.com> wrote:
>> 
>>> As I said, there is stuff that I don't understand in here.... (including
>>> why browsers apparently do trust alternative chains)
>>> 
>>> -pd
>>> 
>>>> On 10 Jun 2020, at 01:53 , Simon Urbanek <simon.urbanek using R-project.org>
>>> wrote:
>>>> 
>>>> You are making a very strong assumption that finding an alternative
>>> chain of trust is safe. I'd argue it's not - it means that an adversary
>>> could manipulate the chain in a way to trust it instead of the declared
>>> chain and thus subverting it. In fact switching to OpenSSL would create a
>>> serious security hole here - in particular since it installs a separate
>>> trust store which it is far more easily attacked and subverted. By your
>>> argument we should disable all SSL checks as that produces error with
>>> incorrectly configured servers so not performing checks is better. It is
>>> true that R is likely not used for sensitive transactions, but I would
>>> rather it warned me about situations where the communication may be
>>> compromised instead of just silently going along.
>>>> 
>>>> Cheers,
>>>> Simon
>>>> 
>>>> 
>>>> 
>>>>> On Jun 10, 2020, at 11:39 AM, peter dalgaard <pdalgd using gmail.com>
>> wrote:
>>>>> 
>>>>> Yes and no... At least as I understand it (Disclaimer: There are
>> things
>>> I am pretty sure that I don't understand properly, somewhere in the
>> Bermuda
>>> triangle beween CA bundles, TLS protocols, and Server-side settings),
>> there
>>> are two sided to this:
>>>>> 
>>>>> One is that various *.r-project.org servers got hit by a fumble where
>>> a higher-up certificate in the chain of trust expired before the *.
>>> r-project.org one. This was fixed by changing the certificate chain on
>>> each server.
>>>>> 
>>>>> The other side is that this situation hit Mac users harder than
>> others,
>>> because Apple's LibreSSL doesn't have the same feature that openSSL has
>> to
>>> detect a secondary chain of trust when the primary one expired. This was
>>> not unique to R - svn also failed from the command line - but it did
>> affect
>>> download.file() inside R.
>>>>> 
>>>>> The upshot is that there might be 3rd party servers with a similar
>>> certificate setup which have not been updated like *.r-project.org. This
>>> is not too unlikely since web browsers do not have trouble accessing
>> them,
>>> and the whole matter may go undetected. For such servers, download.file()
>>> would still fail.
>>>>> 
>>>>> I.e., there is a case to be made that we might want to link openSSL
>>> rather than LibreSSL.  On the other hand, I gather that newer versions of
>>> LibreSSL contain the relevant protocol upgrade, so maybe one can just
>> wait
>>> for Apple to update it. Or maybe we do want to link R against openSSL,
>> but
>>> almost certainly not for a hotfix release.
>>>>> 
>>>>> Best
>>>>> -pd
>>>>> 
>>>>>> On 10 Jun 2020, at 00:50 , Simon Urbanek <simon.urbanek using R-project.org
>>> 
>>> wrote:
>>>>>> 
>>>>>> To be clear, this not an issue in the libraries nor R, the
>>> certificates on the server were simply wrong. So, no, this has nothing to
>>> do with R.
>>>>>> 
>>>>>> Cheers,
>>>>>> Simon
>>>>>> 
>>>>>> 
>>>>>>> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson <
>>> henrik.bengtsson using gmail.com> wrote:
>>>>>>> 
>>>>>>> Was this resolved upstream or is this something that R should/could
>>>>>>> fix? If the latter, could this also go into the "emergency release"
>> R
>>>>>>> 4.0.2 that is scheduled for 2020-06-22?
>>>>>>> 
>>>>>>> My $.02
>>>>>>> 
>>>>>>> /Henrik
>>>>>>> 
>>>>>>> 
>>>>>>> On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi <
>> csardi.gabor using gmail.com>
>>> wrote:
>>>>>>>> 
>>>>>>>> Btw. it would be also possible to create a macOS R installer that
>>>>>>>> embeds a static or dynamic libcurl with Secure Transport, instead
>> of
>>>>>>>> the Apple default LibreSSL.
>>>>>>>> 
>>>>>>>> This might be too late for R 4.0.1, I don't know.
>>>>>>>> 
>>>>>>>> Gabor
>>>>>>>> 
>>>>>>>> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi <
>> csardi.gabor using gmail.com>
>>> wrote:
>>>>>>>>> 
>>>>>>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <
>>> csardi.gabor using gmail.com> wrote:
>>>>>>>>> [...]
>>>>>>>>>> Btw. why does this affect openssl? That root cert was published
>> in
>>>>>>>>>> 2010, surely openssl should know about it? Maybe libcurl /
>> openssl
>>>>>>>>>> only uses the chain provided by the server? Without trying to use
>>> an
>>>>>>>>>> alternate chain?
>>>>>>>>> 
>>>>>>>>> Yes, indeed it seems that old OpenSSL versions cannot handle
>>>>>>>>> alternative certificate chains. This has been fixed in OpenSSL in
>>>>>>>>> 2015, so modern Linux systems should be fine. However, macOS uses
>>>>>>>>> LibreSSL, and LibreSSL never fixed this issue. E.g.
>>>>>>>>> https://github.com/libressl-portable/portable/issues/595
>>>>>>>>> 
>>>>>>>>> r-project.org can be updated to send the new root certificate,
>>> which
>>>>>>>>> will solve most of our problems, but we'll probably have issues
>> with
>>>>>>>>> other web sites that'll update slower or never.
>>>>>>>>> 
>>>>>>>>> FWIW I built macOS binaries for the curl package, using a static
>>>>>>>>> libcurl and macOS Secure Transport, so these binaries does not
>> have
>>>>>>>>> this issue.
>>>>>>>>> 
>>>>>>>>> They are at https://files.r-hub.io/curl-macos-static and they can
>>> be
>>>>>>>>> installed with
>>>>>>>>> install.packages("curl", repos =
>>>>>>>>> "https://files.r-hub.io/curl-macos-static", type = "binary")
>>>>>>>>> 
>>>>>>>>> They support R 3.2 and up, including R 4.1, and should work on all
>>>>>>>>> macOS versions that the given R release supports.
>>>>>>>>> 
>>>>>>>>> Gabor
>>>>>>>> 
>>>>>>>> ______________________________________________
>>>>>>>> R-devel using r-project.org mailing list
>>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>> 
>>>>>>> ______________________________________________
>>>>>>> R-devel using r-project.org mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>> 
>>>>>> 
>>>>>> ______________________________________________
>>>>>> R-devel using r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> 
>>>>> --
>>>>> Peter Dalgaard, Professor,
>>>>> Center for Statistics, Copenhagen Business School
>>>>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>>>>> Phone: (+45)38153501
>>>>> Office: A 4.23
>>>>> Email: pd.mes using cbs.dk  Priv: PDalgd using gmail.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> --
>>> Peter Dalgaard, Professor,
>>> Center for Statistics, Copenhagen Business School
>>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>>> Phone: (+45)38153501
>>> Office: A 4.23
>>> Email: pd.mes using cbs.dk  Priv: PDalgd using gmail.com
>>> 
>>> ______________________________________________
>>> R-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>> 
>>        [[alternative HTML version deleted]]
>> 
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list