Everything

php

PHP 7.2.0 Released

php.internals

Remi Collet

8 years ago

The PHP development team announces the immediate availability of PHP
7.2.0. This release marks the second feature update to the PHP 7 series.

PHP 7.2.0 comes with numerous improvements and new features such as

- Convert numeric keys in object/array casts
- Counting of non-countable objects
- Object typehint
- HashContext as Object
- Argon2 in password hash
- Improve TLS constants to sane values
- Mcrypt extension removed
- New sodium extension

For source downloads of PHP 7.2.0 please visit our downloads page
Windows binaries can be found on the PHP for Windows site. The list of
changes is recorded in the ChangeLog.

The migration guide is available in the PHP Manual. Please consult it
for the detailed list of new features and backward incompatible changes.


Release Announcement: http://php.net/releases/7_2_0.php
Downloads:            http://www.php.net/downloads
Windows downloads:    http://windows.php.net/download
Changelog:            http://www.php.net/ChangeLog-7.php#7.2.0
Migration guide:      http://php.net/manual/en/migration72.php


Many thanks to all the contributors and supporters!

Sara Golemon, Remi Collet

Hannes Magnusson

8 years ago

> - Improve TLS constants to sane values

This worries me a lot. Last time someone thought it was a good idea they
introduced security vulnerability for all apps that used them.

Do you have a link to this commit ?

-Hannes

Remi Collet

8 years ago

Le 30/11/2017 à 17:41, Hannes Magnusson a écrit :

> Do you have a link to this commit ?

Simply following the link from the release notes...

https://wiki.php.net/rfc/improved-tls-constants

Remi

lists@rhsoft.net

8 years ago

Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:

>> - Improve TLS constants to sane values
>
> This worries me a lot. Last time someone thought it was a good idea they
> introduced security vulnerability for all apps that used them.

that PHP now instead of ECDHE-RSA-AES128-SHA uses
ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
the crypto library alone at all?

at least it got better with 7.2

Niklas Keller

8 years ago

lists@rhsoft.net <lists@rhsoft.net> schrieb am Fr., 1. Dez. 2017, 17:13:

>
>
> Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
> >> - Improve TLS constants to sane values
> >
> > This worries me a lot. Last time someone thought it was a good idea they
> > introduced security vulnerability for all apps that used them.
>
> that PHP now instead of ECDHE-RSA-AES128-SHA uses
> ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
> openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
> the crypto library alone at all?
>
> at least it got better with 7.2
>

We only changed the defaults in 7.2, it was possible to use the same
features before, except for the security level.

Regards, Niklas

lists@rhsoft.net

8 years ago

Am 01.12.2017 um 17:44 schrieb Niklas Keller:

> lists@rhsoft.net <mailto:lists@rhsoft.net> <lists@rhsoft.net
> <mailto:lists@rhsoft.net>> schrieb am Fr., 1. Dez. 2017, 17:13:
>
>
>
>     Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
>      >> - Improve TLS constants to sane values
>      >
>      > This worries me a lot. Last time someone thought it was a good
>     idea they
>      > introduced security vulnerability for all apps that used them.
>
>     that PHP now instead of ECDHE-RSA-AES128-SHA uses
>     ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
>     openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
>     the crypto library alone at all?
>
>     at least it got better with 7.2
>
> We only changed the defaults in 7.2, it was possible to use the same
> features before, except for the security level

yes and since nobody ever sould override the defaults in application
code for obvious reasons that's the problem, you shouldn't mangle with
openssl defaults in general and let openssl do the handshake which will
end in the server side perferred cipher and so in the most secure

what PHP does is making encryption weaker as it hsould be

above i talk about encrypted connection to mysqld

and *no* if our only cipher on the server is ECDHE-RSA-AES128-GCM-SHA256
anything before PHP 7.2 won't connect at all

Sara Golemon

8 years ago

On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:

> yes and since nobody ever sould override the defaults in application code
> for obvious reasons that's the problem, you shouldn't mangle with openssl
> defaults in general and let openssl do the handshake which will end in the
> server side perferred cipher and so in the most secure
>
> what PHP does is making encryption weaker as it hsould be
>

Um.  Did you look at the diff in question?

The old default was tls 1.0 only, the new default is tls 1.0, 1.1, or 1.2.
The new default allows OpenSSL to negotiate for a preferred method
where it couldn't before.
The change literally does the opposite of what you're talking about.

-Sara

lists@rhsoft.net

8 years ago

Am 01.12.2017 um 22:49 schrieb Sara Golemon:

> On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:
>> yes and since nobody ever sould override the defaults in application code
>> for obvious reasons that's the problem, you shouldn't mangle with openssl
>> defaults in general and let openssl do the handshake which will end in the
>> server side perferred cipher and so in the most secure
>>
>> what PHP does is making encryption weaker as it should be
>>
> Um.  Did you look at the diff in question?
>
> The old default was tls 1.0 only, the new default is tls 1.0, 1.1, or 1.2.
> The new default allows OpenSSL to negotiate for a preferred method
> where it couldn't before.
> The change literally does the opposite of what you're talking about

for *now* and then when TLS 1.3 is out, the openssl on the system
supports TLS 1.3 PHP will hang on TLS1.2 as it did with TLS1.0?

the main question is why does PHP need to to *anything* here instead
hand the TLS handshake completly over to openssl? in that case even PHP5
could perfer TLS1.2 ciphers against a sevrer that orders them on top
without touch any line of PHP's code

"the opposite of what you're talking about" is plain wrong when you look
at my first response
_________________________

Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:

>> - Improve TLS constants to sane values
>
> This worries me a lot. Last time someone thought it was a good

idea they

> introduced security vulnerability for all apps that used them.

that PHP now instead of ECDHE-RSA-AES128-SHA uses
ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
the crypto library alone at all?

at least it got better with 7.2

Walter Parker

8 years ago

On Fri, Dec 1, 2017 at 3:35 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:

>
>
> Am 01.12.2017 um 22:49 schrieb Sara Golemon:
>
>> On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <lists@rhsoft.net>
>> wrote:
>>
>>> yes and since nobody ever sould override the defaults in application code
>>> for obvious reasons that's the problem, you shouldn't mangle with openssl
>>> defaults in general and let openssl do the handshake which will end in
>>> the
>>> server side perferred cipher and so in the most secure
>>>
>>> what PHP does is making encryption weaker as it should be
>>>
>>> Um.  Did you look at the diff in question?
>>
>> The old default was tls 1.0 only, the new default is tls 1.0, 1.1, or 1.2.
>> The new default allows OpenSSL to negotiate for a preferred method
>> where it couldn't before.
>> The change literally does the opposite of what you're talking about
>>
>
> for *now* and then when TLS 1.3 is out, the openssl on the system supports
> TLS 1.3 PHP will hang on TLS1.2 as it did with TLS1.0?
>
> the main question is why does PHP need to to *anything* here instead hand
> the TLS handshake completly over to openssl? in that case even PHP5 could
> perfer TLS1.2 ciphers against a sevrer that orders them on top without
> touch any line of PHP's code
>
> "the opposite of what you're talking about" is plain wrong when you look
> at my first response
> _________________________
>
>     Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
>      >> - Improve TLS constants to sane values
>      >
>      > This worries me a lot. Last time someone thought it was a good
>     idea they
>      > introduced security vulnerability for all apps that used them.
>
>     that PHP now instead of ECDHE-RSA-AES128-SHA uses
>     ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
>     openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
>     the crypto library alone at all?
>
>     at least it got better with 7.2
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Lists, I fail to see how Sara was wrong and you are right.
In the old PHP, it was TLS 1.0
In the new PHP. it is TLS 1.2, TLS1.1, TLS1.3

When TLS1.3 comes out, old PHP will use only TLS1.0. <- This doesn't work
today for many sites
The new PHP will support TLS1.2, TLS 1.1, TLS 1.0 <- Still stronger that
the older version (required for many sites today)
When the openssl version that comes out to support the IETF final release
of TLS1.3 comes out in a few years, the openssl updates will be easier to
apply to the newest code base.

How many older PHP (5.X) systems will upgrade to (or even be able to
upgrade) to the newest openssl library?

As built right now, none of those would get TLS1.3 out of the box.

If you want the version selection moved completely to openssl, you should
write an RFC for that.

The current idea (where TLS1.3 is added to the list of defaults once the
software is release) vs an undefined system where it is handled magically
at a lower level doesn't appear to be more secure.


Walter

--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

lists@rhsoft.net

8 years ago

Am 02.12.2017 um 02:08 schrieb Walter Parker:

> Lists, I fail to see how Sara was wrong and you are right.
> In the old PHP, it was TLS 1.0

bad enough

> In the new PHP. it is TLS 1.2, TLS1.1, TLS1.3

you surely meant 1.0 instead 1.3 here

> When TLS1.3 comes out, old PHP will use only TLS1.0. <- This doesn't work
> today for many sites

it should'nt have been used for *many* years

> The new PHP will support TLS1.2, TLS 1.1, TLS 1.0 <- Still stronger that
> the older version (required for many sites today)

yeah, but why do i need PHP 7.2 for get such basics right which openssl
and every other software on the system supports out-of-the-box for many
years?

> When the openssl version that comes out to support the IETF final release
> of TLS1.3 comes out in a few years, the openssl updates will be easier to
> apply to the newest code base.

and that's plain wrong - period

> How many older PHP (5.X) systems will upgrade to (or even be able to
> upgrade) to the newest openssl library?

they could have been used TLS1.2 years before PHP 7.2 was even
considered withgout that wrong design of how to hanlde TLS handshakes

> As built right now, none of those would get TLS1.3 out of the box.

beause nobody learnt from the past mistakes

> If you want the version selection moved completely to openssl, you should
> write an RFC for that.

that should have been common sense by doing the changes we are talking about

> The current idea (where TLS1.3 is added to the list of defaults once the
> software is release) vs an undefined system where it is handled magically
> at a lower level doesn't appear to be more secure

surely, openssl's job is to handle encryption and handsahkes, PHP failed
in this area proveable and has no bunsiness at all in that context

Sara Golemon

8 years ago

On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:

> the main question is why does PHP need to to *anything* here instead hand
> the TLS handshake completly over to openssl? in that case even PHP5 could
> perfer TLS1.2 ciphers against a sevrer that orders them on top without touch
> any line of PHP's code
>

Because the SSL API in OpenSSL that PHP uses doesn't let you say:
"Just give me the best method you can".

SSL_CTX *SSL_CTX_new(const SSL_METHOD *method);
const SSL_METHOD *SSLv23_method(void);
const SSL_METHOD *SSLv23_server_method(void);
const SSL_METHOD *SSLv23_client_method(void);
const SSL_METHOD *TLSv1_2_method(void);
const SSL_METHOD *TLSv1_2_server_method(void);
const SSL_METHOD *TLSv1_2_client_method(void);
const SSL_METHOD *TLSv1_1_method(void);
const SSL_METHOD *TLSv1_1_server_method(void);
const SSL_METHOD *TLSv1_1_client_method(void);
const SSL_METHOD *TLSv1_method(void);
const SSL_METHOD *TLSv1_server_method(void);
const SSL_METHOD *TLSv1_client_method(void);
#ifndef OPENSSL_NO_SSL3_METHOD
const SSL_METHOD *SSLv3_method(void);
const SSL_METHOD *SSLv3_server_method(void);
const SSL_METHOD *SSLv3_client_method(void);
#endif
#ifndef OPENSSL_NO_SSL2
const SSL_METHOD *SSLv2_method(void);
const SSL_METHOD *SSLv2_server_method(void);
const SSL_METHOD *SSLv2_client_method(void);
#endif

There may be another SSL API that does, but that's more than just "set
the value to any and be done with it".

Pull requests welcome,
-Sara

lists@rhsoft.net

8 years ago

Am 04.12.2017 um 18:36 schrieb Sara Golemon:

> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:
>> the main question is why does PHP need to to *anything* here instead hand
>> the TLS handshake completly over to openssl? in that case even PHP5 could
>> perfer TLS1.2 ciphers against a sevrer that orders them on top without touch
>> any line of PHP's code
>>
> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
> "Just give me the best method you can"
>
> There may be another SSL API that does, but that's more than just "set
> the value to any and be done with it"

and how does other software like the apache benchmark tool "ab" this for
as long as i can think which is also linked against openssl?

[harry@srv-rhsoft:~]$ ab -c 1 -n 1 https://localhost/
This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient).....done

Server Software:
Server Hostname:        localhost
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-AES128-GCM-SHA256,256,128
TLS Server Name:        localhost
______________________

[harry@srv-rhsoft:~]$ ldd /usr/bin/ab
linux-vdso.so.1 (0x00007ffd015cc000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fb83e962000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fb83e4d7000)
libaprutil-1.so.0 => /lib64/libaprutil-1.so.0 (0x00007fb83ed96000)
libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007fb83ed5a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb83e2b8000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb83dfa2000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb83dbcd000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb83d9b6000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb83d7b2000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fb83d5ad000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb83d377000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fb83d144000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb83ebce000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fb83cf15000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007fb83cd12000)

lists@rhsoft.net

8 years ago

and to be clear here:

a client when connecting to a server configured like below has to
respect the cipher order of the server while
https://www.ssllabs.com/ssltest/ exists for years to give dministrators
of the server some help and which clients are using which cipher

[harry@srv-rhsoft:~]$ openssl s_client -connect localhost:443
-servername localhost
.............
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher    : ECDHE-ECDSA-AES128-GCM-SHA256
________________________________________

Handshake Simulation for servers with ECDSA/RSA dual stack:
OpenSSL 1.0.1l  R        EC 256 (SHA256)       TLS 1.2
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
OpenSSL 1.0.2e  R        EC 256 (SHA256)       TLS 1.2
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
________________________________________

in case the server has only a RSA certificate:
OpenSSL 1.0.1l  R		RSA 2048 (SHA256)   	TLS 1.2
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
OpenSSL 1.0.2e  R		RSA 2048 (SHA256)   	TLS 1.2
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
________________________________________

SSLHonorCipherOrder On
SSLCipherSuite
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA


Am 04.12.2017 um 19:18 schrieb lists@rhsoft.net:

Sara Golemon

8 years ago

On Mon, Dec 4, 2017 at 1:18 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:

> Am 04.12.2017 um 18:36 schrieb Sara Golemon:
>> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:
>>>
>>> the main question is why does PHP need to to *anything* here instead hand
>>> the TLS handshake completly over to openssl? in that case even PHP5 could
>>> perfer TLS1.2 ciphers against a sevrer that orders them on top without
>>> touch
>>> any line of PHP's code
>>>
>> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
>> "Just give me the best method you can"
>>
>> There may be another SSL API that does, but that's more than just "set
>> the value to any and be done with it"
>
>
> and how does other software like the apache benchmark tool "ab" this for as
> long as i can think which is also linked against openssl?
>

You quoted this, but I don't think you understood it.
"""
There may be another SSL API that does, but that's more than just "set
the value to any and be done with it".

Pull requests welcome,
"""

I don't doubt that it's possible to do, but it's not as trivial as
"Just make the ANY constant really mean ANY".
If you have a solution, offer it.
Until then, it's going to wait until someone else has the time and
inclination to do so.

-Sara

Jakub Zelenka

8 years ago

On Mon, Dec 4, 2017 at 5:36 PM, Sara Golemon <pollita@php.net> wrote:

> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:
> > the main question is why does PHP need to to *anything* here instead hand
> > the TLS handshake completly over to openssl? in that case even PHP5 could
> > perfer TLS1.2 ciphers against a sevrer that orders them on top without
> touch
> > any line of PHP's code
> >
> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
> "Just give me the best method you can".
>
> SSL_CTX *SSL_CTX_new(const SSL_METHOD *method);
>  const SSL_METHOD *SSLv23_method(void);
>  const SSL_METHOD *SSLv23_server_method(void);
>  const SSL_METHOD *SSLv23_client_method(void);
>  const SSL_METHOD *TLSv1_2_method(void);
>  const SSL_METHOD *TLSv1_2_server_method(void);
>  const SSL_METHOD *TLSv1_2_client_method(void);
>  const SSL_METHOD *TLSv1_1_method(void);
>  const SSL_METHOD *TLSv1_1_server_method(void);
>  const SSL_METHOD *TLSv1_1_client_method(void);
>  const SSL_METHOD *TLSv1_method(void);
>  const SSL_METHOD *TLSv1_server_method(void);
>  const SSL_METHOD *TLSv1_client_method(void);
>  #ifndef OPENSSL_NO_SSL3_METHOD
>  const SSL_METHOD *SSLv3_method(void);
>  const SSL_METHOD *SSLv3_server_method(void);
>  const SSL_METHOD *SSLv3_client_method(void);
>  #endif
>  #ifndef OPENSSL_NO_SSL2
>  const SSL_METHOD *SSLv2_method(void);
>  const SSL_METHOD *SSLv2_server_method(void);
>  const SSL_METHOD *SSLv2_client_method(void);
>  #endif
>
> There may be another SSL API that does, but that's more than just "set
> the value to any and be done with it".
>

Yep there is SSL_CTX_set_min_proto_version
and SSL_CTX_set_max_proto_version in OpenSSL 1.1.0+ which is the preferred
way how to set the protocol. The version specific method are all now
deprecated and should not be used. I have got it on my TODO list so
hopefully will find time to implement it. It would be ideal to just
introduce min and max protocol version context options for tls and possibly
ssl (which is tls alias now) streams. It is of course backportable to 1.0.1
and 1.0.2 using SSL_OP_NO_* which is how it is basically working now but
for 1.1.0+ it will use more flexible min and max. I think it would also
make sense to deprecate tlsv* and sslv* streams but don't feel so strongly
about it.

The c part implementation is not too difficult but we should probably
improve and extend the version tests (that are really slow atm.) so it
might take a bit. Anyway I really hope to have it in 7.3.

Cheers

Jakub