What to do about OpenSSL?

[paragonie-scott]

• It's not fork safe
• In most versions of PHP, it lies about being secure
• And today I learned that OpenSSL, by default (i.e. unchangable from PHP land) uses MD5 as a CSPRNG (thanks @atoponce)

I'm stuck between several possible avenues:

• Release a new version (v1.3.0 or most likely v2.0.0) that doesn't rely on OpenSSL at all
• Create an OpenSSL-free fork, called secure_random
• Possibly in either case allow LibreSSL/BoringSSL but definitely not OpenSSL

I'm interested in everyone's opinions here. The status quo is simply unacceptable.

[narfbg]

Kill it.

[ivantcholakov]

v2.0.0 that doesn't rely on OpenSSL at all seems to be the best choice.

[GrahamCampbell]

👍 For killing it in a 2.0.0 release.

[GrahamCampbell]

Though, actually, given the seriousness, I'm inclined to say that actually a 1.3.0 is a better bet to ensure this gets widely deployed, quickly.

[paragonie-scott]

http://semver.org/ dictates a major version increment with an incompatible API change, which removing support for OpenSSL almost certainly is

[narfbg]

This is not an API change.

In fact, the public API (and semver.org does always say "public API") is tied to PHP 7.0.0's, so you almost by definition can't break SemVer compatibility.

[GrahamCampbell]

That's true (ish), which is why my first comment was for 2.0.0, but on reflection, I think 1.3.0 is better, despite semver for the reasons I said already. Most applications are restricting the version to 1.x for this package.

I agree with @narfbg in terms of saying this isn't actually a break. Only the internal API has changed.

[paragonie-scott]

Right. And the area where the issue is most likely going to occur is in WordPress, which already catches the Exception and falls back to what they used previously.

Unless anyone objects I'm going to roll out 1.3.0 without OpenSSL.

[ivantcholakov]

No objection about 1.3.0 from me.

[ramsey]

@paragonie-scott, I'm curious about your thoughts on a better CSPRNG to use in PHP, given your RFC (currently in voting phase) to kill mcrypt and our concerns with OpenSSL. Is there a better library we should eventually move into the PHP core that provides the same (yet more secure) functionality (i.e. LibreSSL, libsodium, etc.)?

[paragonie-scott]

@ramsey Yes, for a CSPRNG, it's called random_bytes() and it's part of the PHP 7 core. The current random_bytes() implementation in 7.0 is almost a verbatim copy of libsodium's randombytes_buf(). They're morally equivalent for the sake of most discussions.

The water is muddy here: mcrypt_create_iv() is the only ext/mcrypt function that's sanely implemented. On the flipside, openssl_random_pseudo_bytes() is the only ext/openssl function that's insanely implemented.

CSPRNG aside, libsodium (which random_compat prefers if it's available) is highly regarded by cryptography/security experts. I have another RFC to add libsodium to PHP in 7.1, pending some changes after 1.0.3 of the PHP extension (which will sync up with 1.0.9 of the library) is finished.

[paragonie-scott]

To clarify, the post-1.0.3 changes are API related but functionally zero: Instead of \Sodium\function_here() it will be accessed via sodium_function_here(). A congruent change will be made to the constants.

[GrahamCampbell]

Right. And the area where the issue is most likely going to occur is in WordPress

Can't say I'm that bothered

[ramsey]

Yes, for a CSPRNG, it's called random_bytes() and it's part of the PHP 7 core.

Well, obviously! ;-)

[paragonie-scott]

1c435ec removes OpenSSL. I'll tag/sign a release on Friday.

[AshleyPinner]

Just to weigh in here, while I agree that the other reasons are good ones to remove it, OpenSSL doesn't actually use MD5 for the RAND calls. It's not much better, but by default in 1.0.1 it seems to be using SHA1 (Unless you explicitly build it to use MD5... or less...).

A quick check of the compile options (Use openssl version -a to see them all) should tell you if you're using a version compiled with explicit USE_MD5_RAND or not. CentOS 7 & 6, Ubuntu 14.04 seem not to define it, and I'd love to know if any OpenSSL 1.0.x builds define it.

[kaystrobach]

will there be an 1.4.x tag which is not listed on sensio labs (e.g. with openssl disabled?)

[paragonie-scott]

That's what v2.x is.

[andrerom]

@paragonie-scott Is it correct to say this is not affecting PHP 5.6.24 and higher?

Asking in regards to the listing on security-advisories

[kaystrobach]

@paragonie-scott - thanks just created an pull request in neos/flow 3.3 to switch to v2 ... thanks a lot

[paragonie-scott]

@andrerom I believe so. However, the decision to trust a userspace PRNG rather than the kernel's CSPRNG was a mistake that we will never repeat.

[andrerom]

Clear, I was more thinking a 1.5 release bumping php requirements would allow security advisories to avoid blindly marking whole 1.x branch as insecure, when in fact it depends.

[paragonie-scott]

Honestly, just upgrade to v2.x. Other than the OpenSSL drop, there are no other significant changes.

[kaystrobach]

I just did it for 2 projects, works like a charm - thanks a lot.

[paragonie-scott]

Awesome! If anyone else stumbles over this, I've just updated the readme to use headers instead of bold text so you can link folks directly to the relevant section: https://github.com/paragonie/random_compat/blob/master/README.md#version-conflict-with-other-php-project