go to bug id or search bugs for
STREAM_CRYPTO_METHOD_SSLv23_CLIENT has been the recommended option to use since forever and has - up until 5.6 - included TLS.
As of PHP5.6, this is no longer the case and is in fact explictly removed from supported mechanisms in PHP 5.6 - without any notifications to anyone.
Add a Patch
Add a Pull Request
The following patch has been added/updated:
Patch Name: sslv23.patch
https://github.com/php/php-src/commit/10bc5fd4c4c8e1dd57bd911b086e9872a56300a0 changed STREAM_CRYPTO_METHOD_SSLv23_CLIENT back to include TLS methods, fixing the reason for this bug being opened, but unfortunately goes further than the diff proposed here.
STREAM_CRYPTO_METHOD_TLS_CLIENT was also changed back to allowing TLSv1.0 only (no v1.1/v1.2). This is a very commonly used method (it's found in various places in the PHP source tree itself, also piwik, librenms, roundcube, davical, owncloud, selfoss, statusnet, zendframework, and Net-IMAP, Net-Sieve, Net-SMTP in PEAR) and as such it really should be supporting modern crypto rather than restricting to TLSv1.0.
That commit does also add a STREAM_CRYPTO_METHOD_TLS_ANY_CLIENT to the enum, but it's useless as it's not exposed to the parser in ext/standard/file.c, and even if it was, nobody would use it in their code - they're either using METHOD_SSLv23 (older code, and newer code that knows that this will give them the full range of methods), or they're using METHOD_TLS and expecting it to give them a suitable TLS version, same as OpenSSL's TLS_(server_|client_|)method.
The only reason for restricting to TLSv1.0 is for connecting to legacy systems that have broken negotiation, or for testing which exact versions of TLS are supported by a host; but these are very uncommon use cases and things needing these could use METHOD_TLSv1_0 explicitly.
Already fixed a long time ago (in 5.6.7) … closing.