Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82147
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
Date: Sun, 8 Feb 2015 11:15:14 -0500
Message-ID: <CAH8MpnkZCnvdHE5yC_kgo8cisHULegjwndMZWdvTPOYrm9io3A@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>, fsb@thefsb.dot.org
Content-Type: multipart/alternative; boundary=047d7bdc14387bc15c050e95f5b4
Subject: Re: Security changes in PHP 7
From: rdlowrey@php.net (Daniel Lowrey)

--047d7bdc14387bc15c050e95f5b4
Content-Type: text/plain; charset=UTF-8

On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster <fsb@thefsb.org> wrote:


> 3. Will the OpenSSL ext remain as it currently stands?

There has been talk of replacing it with a more generic implementation that
can swap out the underlying components so we aren't dependent upon a single
library. The crypto extension in pecl is working on such an approach, but
AFAIK it's not yet stable. That said, ext/openssl already delegates to
Windows API functions to provide equivalent functionality as needed, so
this is already happening to some extent. Additionally, for better or worse
ext/openssl is tightly integrated into the current streams implementation
when crypto is required (i.e. the ssl stream wrapper). Any new solution
would need to provide equivalent functionality.

> 4. What does openssl_random_pseudo_bytes() really do in PHP?

It's less about what it does in PHP and more about what it does in the
openssl lib itself with the exception being Windows environments.

### In Windows

This function delegates to CryptGenRandom() which uses the general
system-wide RNG. It *is* possible for an application to add its own data to
the further randomize the internal seed, however, the current
openssl_random_pseudo_bytes() does not expose this capability to userland.

### Elsewhere

Openssl transparently seeds its entropy pool. Once the pool has been seeded
with enough data it will always have sufficient data to ensure an
unpredictable byte sequence is returned. So it now becomes a matter of
whether or not it has enough entropy at the time of your call to
openssl_random_pseudo_bytes().

Openssl actually exposes two separate APIs for this case, so let me explain
what each does:

- RAND_bytes()

Always return an error if there is insufficient data in the pool to ensure
unpredictability.

- RAND_pseudo_bytes()

Always return bytes, even if the entropy pool has not been sufficiently
seeded.

Currently PHP's openssl_random_pseudo_bytes() uses the latter function and
allows users to pass a by-reference $crypto_strong out parameter to
determine if the result is cryptographically strong. This is fine if you
know all of the above and have read the manual for this function. However,
it may be desirable to add a new openssl_rand_bytes() function that uses
RAND_bytes() under the hood to make it less likely for someone to
accidentally use insufficiently random output. I don't think there would be
an analog to this functionality in Windows as the documentation for
CryptGenRandom() makes no mention of when/if this API can return a sequence
of bytes that is not cryptographically secure. So, a new
openssl_random_bytes() might only amount to an alias of the existing
openssl_random_pseudo_bytes() function in this environment. Please provide
feedback if you think a new function should be added as this is a
relatively straightforward thing to do.

I would also like to propose a new optional $additionalSeed string
parameter that could be passed from userland to include in the entropy pool
since both the underlying Windows and Openssl APIs support this
functionality.

> "Feature Freeze" for PHP 7 is coming soon. I, for one, would value a
> summary of what's happening in PHP 7 with respect to security topics
> like but not limited to these.

FYI I still plan to add both client-side and server-side support for OCSP
verification in encrypted streams. The other thing I plan to do is add
support for the (relatively new) TLSALPN extension in encrypted
client/server streams. This extension is required to establish encrypted
connections using the forthcoming h2 (HTTP/2.0) protocol.

--047d7bdc14387bc15c050e95f5b4--