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 at 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 at 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 at 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 at 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 at 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 at gmail.com> wrote: >>>>>> >>>>>> On Sat, May 30, 2020 at 11:32 PM G?bor Cs?rdi <csardi.gabor at 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 at r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >>> ______________________________________________ >>> R-devel at 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 at cbs.dk Priv: PDalgd at 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 at cbs.dk Priv: PDalgd at gmail.com
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 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com> > wrote: > >>>>>> > >>>>>> On Sat, May 30, 2020 at 11:32 PM G?bor Cs?rdi < > csardi.gabor at 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 at r-project.org mailing list > >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>> > >>>> ______________________________________________ > >>>> R-devel at r-project.org mailing list > >>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>> > >>> > >>> ______________________________________________ > >>> R-devel at 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 at cbs.dk Priv: PDalgd at 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 at cbs.dk Priv: PDalgd at gmail.com > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com> > > wrote: > > >>>>>> > > >>>>>> On Sat, May 30, 2020 at 11:32 PM G?bor Cs?rdi < > > csardi.gabor at 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 at r-project.org mailing list > > >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel > > >>>> > > >>>> ______________________________________________ > > >>>> R-devel at r-project.org mailing list > > >>>> https://stat.ethz.ch/mailman/listinfo/r-devel > > >>>> > > >>> > > >>> ______________________________________________ > > >>> R-devel at 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 at cbs.dk Priv: PDalgd at 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 at cbs.dk Priv: PDalgd at gmail.com > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]