What to do about OpenSSL? #96

Closed
paragonie-scott opened this Issue Mar 16, 2016 · 16 comments

Projects

None yet

6 participants

@paragonie-scott
Member

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
narfbg commented Mar 16, 2016

Kill it.

@paragonie-scott paragonie-scott referenced this issue in ramsey/uuid Mar 16, 2016
Closed

Uuid:uuid4() collisions #80

@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
Member

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

@narfbg
narfbg commented Mar 16, 2016

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
Member

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
ramsey commented Mar 16, 2016

@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
Member

@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
Member

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 :trollface:

@ramsey
ramsey commented Mar 16, 2016

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

Well, obviously! ;-)

@paragonie-scott
Member

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

@xabbuh xabbuh referenced this issue Mar 17, 2016
Closed

1.3 release #97

@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.

@narfbg narfbg referenced this issue Mar 18, 2016
@paragonie-scott paragonie-scott Prepare for 1.3
* Remove OpenSSL from available RNGs, due to overwhelming security concerns
1c435ec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment