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.urba...@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 <pda...@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.urba...@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.bengts...@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.ga...@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.ga...@gmail.com> >>>>> wrote: >>>>>> >>>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <csardi.ga...@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@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>>> ______________________________________________ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >>> ______________________________________________ >>> R-devel@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....@cbs.dk Priv: pda...@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....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
