Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
> On Jun 7, 2019, at 7:24 PM, Kurt Roeckx wrote: > > That's all very nice, but nobody is going to run that. They also don't have to upgrade their kernel, or deploy new versions of OpenSSL. If platform release engineers don't deploy core services that ensure reliably CSPRNG seeding, then their platform is less secure at boot. This is their choice. Users can vote with their feet for more secure O/S distributions. Secure CSPRNG seeding is a platform responsibility, OpenSSL then runs secure PRNGs seeded from the platform. There's only so much we can reasonably do. The rest has to happen outside of OpenSSL, as a pre-requisite. And yes, fallback on RDSEED/RDRAND + TPM (real or virtual) + whatever is available, but ideally not in libcrypto, but rather a service that that seeds the system at boot. Those other mechanisms are often either not fully trusted in isolation, not always available, or too expensive at every process start. The logic to identify which are available, and how many are enough, ... is best extracted to run separately at boot, with the library using either getentropy() or read /dev/urandom (older kernels). -- Viktor.
VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
This vote has been closed, it passed 5 votes to 2 with no abstentions. Up for discussion is the text of the next vote. I’m proposing this: Topic: The OpenSSL 3.0.0 release will include mitigation for the low entropy on boot and first boot problems. Comment: PR#9084 removed such mitigation due to the negative side effects. I’ll make this formal in a day or so, so if anyone wants to suggest alternative wording, that’s the time line. The vote text is the “topic” line, the comment is explanatory only. Note: I’m not mentioning the mechanism used, that still needs to be decided on. This is just saying that 3.0.0 *will* have some mechanism. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 07:04:57PM -0400, Viktor Dukhovni wrote: > On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote: > > > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote: > > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > > > > > > > For older kernels you install rng-tools that feeds the hwrng in > > > > the kernel. > > > > > > Which works for me, and is pretty much the point I'm trying to make. > > > Then, read /dev/random once early at boot, and do nothing special > > > libcrypto (safely use /dev/urandom). > > > > The only thing rng-tools will actually solve is the starvation > > issue. No service will depend on it, since they don't have any > > relationship with it. Nor can you wait for it, it's not because > > it's started that it has initialized the kernel. I think I've also > > seen reports that it got started too late, actually after a > > services that wants to ask the kernel for random numbers. > > Then a different service can be developed that does block just once > at boot, and tries to obtain entropy from a configurable set of > sources (to avoid or reduce unbounded delay, and mix in more > independent sources). That's all very nice, but nobody is going to run that. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote: > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote: > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > > > > > For older kernels you install rng-tools that feeds the hwrng in > > > the kernel. > > > > Which works for me, and is pretty much the point I'm trying to make. > > Then, read /dev/random once early at boot, and do nothing special > > libcrypto (safely use /dev/urandom). > > The only thing rng-tools will actually solve is the starvation > issue. No service will depend on it, since they don't have any > relationship with it. Nor can you wait for it, it's not because > it's started that it has initialized the kernel. I think I've also > seen reports that it got started too late, actually after a > services that wants to ask the kernel for random numbers. Then a different service can be developed that does block just once at boot, and tries to obtain entropy from a configurable set of sources (to avoid or reduce unbounded delay, and mix in more independent sources). -- Viktor.
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote: > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > > > For older kernels you install rng-tools that feeds the hwrng in > > the kernel. > > Which works for me, and is pretty much the point I'm trying to make. > Then, read /dev/random once early at boot, and do nothing special > libcrypto (safely use /dev/urandom). The only thing rng-tools will actually solve is the starvation issue. No service will depend on it, since they don't have any relationship with it. Nor can you wait for it, it's not because it's started that it has initialized the kernel. I think I've also seen reports that it got started too late, actually after a services that wants to ask the kernel for random numbers. An other solution might be that we enable rdrand/rdseed by default as entropy source, after getentropy() and before /dev/urandom. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 07:01:30PM +, Salz, Rich wrote: > > >The kernel actually already does this in recent versions, if > configured to do it. > > "The" kernel. Which one is that? Which operating system? > > Modern Linux is fine. Is that all we care about? This whole discussion has only been about Linux, we only define DEVRANDOM_WAIT on Linux. I think all other OSs have a sane /dev/urandom, but I'm not sure about NetBSD. > 1.1.1c made Solaris (and possibly others) more secure. I would be > disappointed if 1.1.1d took that away and tried to rationalize that "it's not > my job." *YOU'RE A CRYPTOGRAPHIC LIBRARY* Do you have a reference that Solaris allows reading from /dev/urandom before it's been initialized? Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
> On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > For older kernels you install rng-tools that feeds the hwrng in > the kernel. Which works for me, and is pretty much the point I'm trying to make. Then, read /dev/random once early at boot, and do nothing special libcrypto (safely use /dev/urandom). -- Viktor.
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 03:08:24PM -0400, Viktor Dukhovni wrote: > > On Jun 7, 2019, at 2:41 PM, Kurt Roeckx wrote: > > > >> This is not the sort of thing to bolt into the kernel, but is not > >> unreasonable for systemd and the like. > > > > The kernel actually already does this in recent versions, if > > configured to do it. > > We're talking about what to do with for older kernels. For older kernels you install rng-tools that feeds the hwrng in the kernel. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
> On Jun 7, 2019, at 2:41 PM, Kurt Roeckx wrote: > >> This is not the sort of thing to bolt into the kernel, but is not >> unreasonable for systemd and the like. > > The kernel actually already does this in recent versions, if > configured to do it. We're talking about what to do with for older kernels, and in cases when the kernel cannot promptly obtain sufficient entropy without external sources. The kernel's job is to mix in entropy from natural activity. Boot-time acquisition of non-trivial entropy by other means falls outside the kernel, and may be needed when the kernel cannot obtain sufficient entropy on its own in a timely manner. -- Viktor.
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 02:31:54PM -0400, Viktor Dukhovni wrote: > > That's a different issue. What I was suggesting was a service that > waits for seeding to be ready. So that other services can depend > on that service, with that service using various sources to adequately > seed the kernel RNG, with configurable additional sources beyond the > save file, possibly with a non-zero entropy estimate. Thus, for example, > a virtual machine or container might make use of an interface to get a > a trusted seed from the host hypervisor/OS. Or a physical host might > trust its TPM, ... > > This is not the sort of thing to bolt into the kernel, but is not > unreasonable for systemd and the like. The kernel actually already does this in recent versions, if configured to do it. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre > wrote: > >> The init system would >> need to create this kind of service, and then all software not using >> getentropy()/getrandom() would need to depend on that service. It > > FWIW: systemd already has a service for saving and restoring a random seed. > If I understood Tomas correctly, the saved seed is added to the random pool, > but without crediting any entropy to it (which sounds reasonable to me). That's a different issue. What I was suggesting was a service that waits for seeding to be ready. So that other services can depend on that service, with that service using various sources to adequately seed the kernel RNG, with configurable additional sources beyond the save file, possibly with a non-zero entropy estimate. Thus, for example, a virtual machine or container might make use of an interface to get a a trusted seed from the host hypervisor/OS. Or a physical host might trust its TPM, ... This is not the sort of thing to bolt into the kernel, but is not unreasonable for systemd and the like. Applications can then use getentropy() and not even block at boot time, if the system collects entropy at boot automatically and without excessive delay. The job of improving the source quality and eliminating avoidable delay is then (correctly IMHO) the responsibility of the platform's init system. As for what to do on older platforms, ... add an entropy gathering service to the system start up configuration, and make applications that need early seed material depend on that service. Perhaps the OpenSSL project can curate some examples of such service configurations/scripts. The simplest might be just DEVRANDOM_WAIT as a service that runs at boot, and only reports "ready" once /dev/random is ready. After that applications can just use /dev/urandom with some confidence of adequate seeding. -- Viktor.
AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
> The reason I think nothing will change is that the problem is > already solved, use getentropy()/getrandom(). I agree completely. > The init system would > need to create this kind of service, and then all software not using > getentropy()/getrandom() would need to depend on that service. It FWIW: systemd already has a service for saving and restoring a random seed. If I understood Tomas correctly, the saved seed is added to the random pool, but without crediting any entropy to it (which sounds reasonable to me). https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html Matthias
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 01:28:30PM -0400, Viktor Dukhovni wrote: > > I think that having the RNG behaviour capriciously different on > different systems based on the whims of whoever built the library > for that system is not a good idea. OpenSSL should provide an RNG > that does not block "unexpectedly", indefinitely, and unpredictably. > > Where "unexpectedly", means except possibly early at boot time, but > ideally waiting for boot-time entropoy is something that systemd > and the like take care of, and application start scripts can just > register a dependency on some sort of "entropy" service, whose > successful initialization is sufficient to ensure adequately secure > non-blocking seeding of applications via one of getentropy(), > getrandom(), /dev/urandom... > > That is, I'd expect most of the work for ensuring adequate entropy > to happen outside libcrypto, except for perhaps enabling some > additional sources that may be available on various systems. It seems unlikely that anything related to this will ever change, but we can always ask. The reason I think nothing will change is that the problem is already solved, use getentropy()/getrandom(). The init system would need to create this kind of service, and then all software not using getentropy()/getrandom() would need to depend on that service. It would be eaier to just switch that software to use getentropy()/getrandom(). Changing the init system, means that this will only work for new versions of an OS. But on those new versions we already use getentropy()/getrandom(). What we want to support is people that use an old OS, but run a new version of OpenSSL on it. That is, people that do not use the OS provided OpenSSL version. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote: > > From the point of view of distribution maintainer of OpenSSL I would > say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had > no real problems for us. Introducing DEVRANDOM_WAIT didn't cause any change for us, because we use getentropy(), and a recent kernel. But even systems that use getentropy() with an older kernel can have a large delay after boot. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 11:09:45AM +0200, Matthias St. Pierre wrote: > See the discussion on openssl-users: > > https://mta.openssl.org/pipermail/openssl-users/2019-May/010585.html > https://mta.openssl.org/pipermail/openssl-users/2019-May/010593.html > https://mta.openssl.org/pipermail/openssl-users/2019-May/010595.html > > If desired, I can provide an alternative (competing) pull request which > makes the DEVRANDOM_WAIT feature configurable in a proper and > reasonable way. The default will be whatever the OMC decides. I think that having the RNG behaviour capriciously different on different systems based on the whims of whoever built the library for that system is not a good idea. OpenSSL should provide an RNG that does not block "unexpectedly", indefinitely, and unpredictably. Where "unexpectedly", means except possibly early at boot time, but ideally waiting for boot-time entropoy is something that systemd and the like take care of, and application start scripts can just register a dependency on some sort of "entropy" service, whose successful initialization is sufficient to ensure adequately secure non-blocking seeding of applications via one of getentropy(), getrandom(), /dev/urandom... That is, I'd expect most of the work for ensuring adequate entropy to happen outside libcrypto, except for perhaps enabling some additional sources that may be available on various systems. -- Viktor.
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, 2019-06-07 at 10:18 +0200, Tomas Mraz wrote: > On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote: > > > > Viktor replied: > > > > > I just want to make sure we don't lock ourselves in to a single > > > potentially clumsy solution in the library. Various strategies > > > may be appropriate depending on the platform, and ultimately the > > > cooperation of the system administrator to enable the required > > > mechanisms. > > > > > > Potential additional sources for initial entropy on systems > > > without getrandom(2) might include: > > > > > > RDSEED/RDRAND > > > TPM (or Virtualized TPM which is sometimes better!) > > > RNG state saved across reboots. > > > ... > > > > > > This requires knowledge of various platforms, and potential > > > help from the platform vendors. It might, for example, make > > > sense to delegate initial seeding to systemd on platforms > > > that use systemd, and work with the systemd maintainers to > > > provide a set of sensible entropy sources for initial boot. > > > > > > Exposing a decent RNG to virtual guests and containers is > > > would be another area of focus. > > From the point of view of distribution maintainer of OpenSSL I would > say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT > had > no real problems for us. And to clarify myself - we have no problem with the DEVRANDOM_WAIT introduction either as the -DDEVRANDOM=/dev/urandom works nicely for us. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
