[Rd] r-project.org SSL certificate issues

Wed Aug 19 19:35:22 CEST 2020

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]]