PHP 7.2.0 Released

7 years ago by Remi Collet — view source — reply

unread

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

7 years ago by Hannes Magnusson — view source — reply

unread

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

7 years ago by Remi Collet — view source — reply

unread

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

7 years ago by lists@rhsoft.net — view source — reply

unread

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

7 years ago by Niklas Keller — view source — reply

unread

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

7 years ago by lists@rhsoft.net — view source — reply

unread

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

7 years ago by Sara Golemon — view source — reply

unread

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

7 years ago by lists@rhsoft.net — view source — reply

unread

Am 01.12.2017 um 22:49 schrieb Sara Golemon:

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

7 years ago by Walter Parker — view source — reply

unread

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

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

7 years ago by lists@rhsoft.net — view source — reply

unread

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

7 years ago by Sara Golemon — view source — reply

unread

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

7 years ago by lists@rhsoft.net — view source — reply

unread

Am 04.12.2017 um 18:36 schrieb Sara Golemon:

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)

7 years ago by lists@rhsoft.net — view source — reply

unread

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:

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)

7 years ago by Niklas Keller — view source — reply

unread

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

Just minor nitpicking to get the facts right: A client does never respect
the used cipher order of the server. A client offers a number of ciphers
and the server chooses one of those, either based on its own order
(preferred) or based on the client-preferred order.

If you know other programs doing it better, research how they do it and
propose a change to PHP please.

Regards, Niklas

7 years ago by Walter Parker — view source — reply

unread

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

Just minor nitpicking to get the facts right: A client does never respect
the used cipher order of the server. A client offers a number of ciphers
and the server chooses one of those, either based on its own order
(preferred) or based on the client-preferred order.

If you know other programs doing it better, research how they do it and
propose a change to PHP please.

Regards, Niklas

That's good news. Given that openssl 1.1.0 only shipped late last year, I
fail to see how this has been an failure in PHP for many years for not
using a recent feature in openssl.
Looking at the sources for ab.c, it appears to do things like PHP. The
protocol level is hard coded to one value (SSL_METHOD
*SSLv23_method(void);)
There is a command line override (-Z protocol) that allows the protocol
selection to be changed to TLS1, TLS1.1, TLS1.2, or TLS1+TLS1.1+TLS1.2.

Lists, could you please clarify what PHP should learn from how ab does TLS?

Walter

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

7 years ago by lists@rhsoft.net — view source — reply

unread

Am 04.12.2017 um 22:53 schrieb Walter Parker:

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

Just minor nitpicking to get the facts right: A client does never respect
the used cipher order of the server. A client offers a number of ciphers
and the server chooses one of those, either based on its own order
(preferred) or based on the client-preferred order.

If you know other programs doing it better, research how they do it and
propose a change to PHP please.

accepted, so PHP did only send a subset of the from openssl supported
ciphers to the server not containing the modern ones

That's good news. Given that openssl 1.1.0 only shipped late last year, I
fail to see how this has been an failure in PHP for many years for not
using a recent feature in openssl.
Looking at the sources for ab.c, it appears to do things like PHP. The
protocol level is hard coded to one value (SSL_METHOD
*SSLv23_method(void);)
There is a command line override (-Z protocol) that allows the protocol
selection to be changed to TLS1, TLS1.1, TLS1.2, or TLS1+TLS1.1+TLS1.2.

Lists, could you please clarify what PHP should learn from how ab does TLS?
as you can see in the ssllabs tests openssl 1.0.1 shipped years ago was
able to use ECDHE/ECDSA with AES-GCM which is the recommended cipher,
PHP until recent was only able to use "DHE-RSA-AES128-SHA", the first
part is slow and the second part SHA1 is deprecated long ago for TLS

PHP 7.1 even with openssl 1.1.x against MariaDB 10.2: ECDHE-RSA-AES128-SHA

PHP 7.2 on the same environment: ECDHE-RSA-AES128-GCM-SHA256
this was and is technically supported by openssl 1.0.x

ssl-cipher =
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA"

if you restrict mysqld to "ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256"
nothing before PHP 7.2.0 is able to connect at all

at the same time "ab" which is a small 50 KB binary supports ECDHE and
AES-GCM ciphers for years and is also using openssl - it pretty sure
gives a NULL as cipher to openssl which means openssl sends all it's
supported ciphers to the server and the server then prefers the best one
from his ordering due the handshake

finally that means without touching the code around openssl from the
moment on the openssl on the client side and the server supports and
perefers a new cipher it will get used without touch "ab" and my
question is why PHP is here completly differnt

7 years ago by Walter Parker — view source — reply

unread

Am 04.12.2017 um 22:53 schrieb Walter Parker:

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

Just minor nitpicking to get the facts right: A client does never respect
the used cipher order of the server. A client offers a number of ciphers
and the server chooses one of those, either based on its own order
(preferred) or based on the client-preferred order.

If you know other programs doing it better, research how they do it and
propose a change to PHP please.

accepted, so PHP did only send a subset of the from openssl supported
ciphers to the server not containing the modern ones

That's good news. Given that openssl 1.1.0 only shipped late last year, I

fail to see how this has been an failure in PHP for many years for not
using a recent feature in openssl.
Looking at the sources for ab.c, it appears to do things like PHP. The
protocol level is hard coded to one value (SSL_METHOD
*SSLv23_method(void);)
There is a command line override (-Z protocol) that allows the protocol
selection to be changed to TLS1, TLS1.1, TLS1.2, or TLS1+TLS1.1+TLS1.2.

Lists, could you please clarify what PHP should learn from how ab does
TLS?

as you can see in the ssllabs tests openssl 1.0.1 shipped years ago was
able to use ECDHE/ECDSA with AES-GCM which is the recommended cipher, PHP
until recent was only able to use "DHE-RSA-AES128-SHA", the first part is
slow and the second part SHA1 is deprecated long ago for TLS

PHP 7.1 even with openssl 1.1.x against MariaDB 10.2: ECDHE-RSA-AES128-SHA

PHP 7.2 on the same environment: ECDHE-RSA-AES128-GCM-SHA256
this was and is technically supported by openssl 1.0.x

ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RS
A-AES128-SHA"

if you restrict mysqld to "ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256"
nothing before PHP 7.2.0 is able to connect at all

at the same time "ab" which is a small 50 KB binary supports ECDHE and
AES-GCM ciphers for years and is also using openssl - it pretty sure gives
a NULL as cipher to openssl which means openssl sends all it's supported
ciphers to the server and the server then prefers the best one from his
ordering due the handshake

finally that means without touching the code around openssl from the
moment on the openssl on the client side and the server supports and
perefers a new cipher it will get used without touch "ab" and my question
is why PHP is here completly differnt

--

Oh, I see, this not about the actual change (the protocol version). This is
about when using PHP on the client side, it does not support all/enough of
the modern cipher suite list.

Now that we have identified the problem in question, this should help you
when you create your RFC to fix issues with the cipher suite list.

FYI, the client and server send lists of ciphers that they support to each
other, the server does an AND and picks the highest cipher in on the list.
If the client sends only NULL, then NULL is the only valid cipher. OpenSSL
has default list which includes weak ciphers (such as DES), so using the
default list is bad idea.

You keep using ab as your golden standard because it is small. I'd suggest
picking an application well known to be secure and not one based on the
fact that it is a small C program. I expect that ab gets the newer cipher
list by sending the large default list (which has both the strong items
with ECDHE & AES-GCM as well as DES and RC4). Server side, that would be a
major security issue.

Walter

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

7 years ago by lists@rhsoft.net — view source — reply

unread

Am 05.12.2017 um 01:19 schrieb Walter Parker:

Oh, I see, this not about the actual change (the protocol version). This
is about when using PHP on the client side, it does not support
all/enough of the modern cipher suite list.

Now that we have identified the problem in question, this should help
you when you create your RFC to fix issues with the cipher suite list.

FYI, the client and server send lists of ciphers that they support to
each other, the server does an AND and picks the highest cipher in on
the list. If the client sends only NULL, then NULL is the only valid
cipher. OpenSSL has default list which includes weak ciphers (such as
DES), so using the default list is bad idea

this is not true at all and that's why you use tools like
https://www.ssllabs.com/ssltest/ and SSLHonorCipherOrder as serveradmin
for many years if you care about TLS at all

also the default openssl cipherlist is not just random

as you can see it prefers the ECDSA AES-GCM followed by the RSA AES-GCM
and after the ECDHE it continues with other GCM ciphers na dthe DES/CBC
stuff is at a place in the list which never is selected these days

[harry@srv-rhsoft:~]$ openssl ciphers -v
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256)
Mac=AEAD
ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256)
Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128)
Mac=AEAD
ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128)
Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=Camellia(256) Mac=SHA384
ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA
Enc=Camellia(256) Mac=SHA384

ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
Mac=SHA256

ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128)
Mac=SHA256

ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=Camellia(128) Mac=SHA256

ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA
Enc=Camellia(128) Mac=SHA256

ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA1

ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1

ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(256)
Mac=AEAD
AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(128)
Mac=AEAD
AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
CAMELLIA256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(256)
Mac=SHA256
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
CAMELLIA128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(128)
Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES256-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(256)
Mac=AEAD
DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(128)
Mac=AEAD
DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256)
Mac=SHA256
DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256)
Mac=SHA256
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128)
Mac=SHA256
DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(128)
Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
DHE-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
DHE-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
PSK-AES256-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(256)
Mac=AEAD
PSK-AES256-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(256) Mac=AEAD
PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD
PSK-AES128-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(128)
Mac=AEAD
PSK-AES128-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(128) Mac=AEAD
PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
PSK-CAMELLIA256-SHA384 TLSv1 Kx=PSK Au=PSK Enc=Camellia(256)
Mac=SHA384
PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
PSK-CAMELLIA128-SHA256 TLSv1 Kx=PSK Au=PSK Enc=Camellia(128)
Mac=SHA256
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256)
Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-AES256-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(256)
Mac=AEAD
DHE-PSK-AES256-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(256) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128)
Mac=AEAD
DHE-PSK-AES128-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(128)
Mac=AEAD
DHE-PSK-AES128-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(128) Mac=AEAD
DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA384
DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA1
DHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(256)
Mac=SHA384
DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA256
DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1
DHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(128)
Mac=SHA256
DHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=3DES(168) Mac=SHA1
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256)
Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(256)
Mac=SHA384
ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128)
Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1
ECDHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(128)
Mac=SHA256
ECDHE-PSK-3DES-EDE-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=3DES(168) Mac=SHA1

7 years ago by Walter Parker — view source — reply

unread

Am 05.12.2017 um 01:19 schrieb Walter Parker:

Oh, I see, this not about the actual change (the protocol version). This
is about when using PHP on the client side, it does not support all/enough
of the modern cipher suite list.

Now that we have identified the problem in question, this should help you
when you create your RFC to fix issues with the cipher suite list.

FYI, the client and server send lists of ciphers that they support to
each other, the server does an AND and picks the highest cipher in on the
list. If the client sends only NULL, then NULL is the only valid cipher.
OpenSSL has default list which includes weak ciphers (such as DES), so
using the default list is bad idea

this is not true at all and that's why you use tools like
https://www.ssllabs.com/ssltest/ and SSLHonorCipherOrder as serveradmin
for many years if you care about TLS at all

also the default openssl cipherlist is not just random

as you can see it prefers the ECDSA AES-GCM followed by the RSA AES-GCM
and after the ECDHE it continues with other GCM ciphers na dthe DES/CBC
stuff is at a place in the list which never is selected these days

[harry@srv-rhsoft:~]$ openssl ciphers -v
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256)
Mac=AEAD
ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256)
Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128)
Mac=AEAD
ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128)
Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256)
Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=Camellia(256) Mac=SHA384
ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256)
Mac=SHA384

ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128)
Mac=SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=Camellia(128) Mac=SHA256

ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(128)
Mac=SHA256

ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1

ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256)
Mac=AEAD
AES256-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(256)
Mac=AEAD
AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256)
Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128)
Mac=AEAD
AES128-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(128)
Mac=AEAD
AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128)
Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256)
Mac=SHA256
CAMELLIA256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(256)
Mac=SHA256
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128)
Mac=SHA256
CAMELLIA128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(128)
Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256)
Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128)
Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES256-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(256)
Mac=AEAD
DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256)
Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(128)
Mac=AEAD
DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128)
Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256)
Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256)
Mac=SHA256
DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256)
Mac=SHA256
DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256)
Mac=SHA256
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128)
Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128)
Mac=SHA256
DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128)
Mac=SHA256
DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(128)
Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256)
Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256)
Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128)
Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128)
Mac=SHA1
DHE-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
DHE-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256)
Mac=AEAD
PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
PSK-AES256-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(256)
Mac=AEAD
PSK-AES256-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(256)
Mac=AEAD
PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128)
Mac=AEAD
PSK-AES128-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(128)
Mac=AEAD
PSK-AES128-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(128)
Mac=AEAD
PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
PSK-CAMELLIA256-SHA384 TLSv1 Kx=PSK Au=PSK Enc=Camellia(256)
Mac=SHA384
PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
PSK-CAMELLIA128-SHA256 TLSv1 Kx=PSK Au=PSK Enc=Camellia(128)
Mac=SHA256
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256)
Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-AES256-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(256)
Mac=AEAD
DHE-PSK-AES256-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(256)
Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128)
Mac=AEAD
DHE-PSK-AES128-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(128)
Mac=AEAD
DHE-PSK-AES128-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(128)
Mac=AEAD
DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(256)
Mac=SHA384
DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA1
DHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(256)
Mac=SHA384
DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128)
Mac=SHA256
DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1
DHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(128)
Mac=SHA256
DHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=3DES(168) Mac=SHA1
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256)
Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(256)
Mac=SHA384
ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128)
Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1
ECDHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(128)
Mac=SHA256
ECDHE-PSK-3DES-EDE-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=3DES(168) Mac=SHA1

--

Your link doesn't say what you think it does. Your follow up comments also
appear to have little relevance to the topic at hand.

Could someone please let me know if Lists ever get back on topic with
responses to the questions and statements made, rather than charging
sideways off the field?

Thanks!

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

7 years ago by lists@rhsoft.net — view source — reply

unread

Am 05.12.2017 um 06:52 schrieb Walter Parker:

On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net
mailto:lists@rhsoft.net <lists@rhsoft.net mailto:lists@rhsoft.net>
wrote:

Am 05.12.2017 um 01:19 schrieb Walter Parker:

    Oh, I see, this not about the actual change (the protocol
    version). This is about when using PHP on the client side, it
    does not support all/enough of the modern cipher suite list.

    Now that we have identified the problem in question, this should
    help you when you create your RFC to fix issues with the cipher
    suite list.

    FYI, the client and server send lists of ciphers that they
    support to each other, the server does an AND and picks the
    highest cipher in on the list. If the client sends only NULL,
    then `NULL` is the only valid cipher. OpenSSL has default list
    which includes weak ciphers (such as DES), so using the default
    list is bad idea

this is not true at all and that's why you use tools like
https://www.ssllabs.com/ssltest/ 
and SSLHonorCipherOrder as serveradmin for many years if you care
about TLS at all

also the default openssl cipherlist is not just random

as you can see it prefers the ECDSA AES-GCM followed by the RSA
AES-GCM and after the ECDHE it continues with other GCM ciphers na
dthe DES/CBC stuff is at a place in the list which never is selected
these days

Your link doesn't say what you think it does

which one?
https://www.ssllabs.com/ssltest/

sorry, but if you don't know what ssllab does and how it is used by
serveradmins to make sure clients using best possible encryption you are
hardly in the position making comments like "OpenSSL has default list
which includes weak ciphers (such as DES), so using the default list is
bad idea" and instead abusive responses you could have entered the url
of a TLS webserver

Your follow up comments
also appear to have little relevance to the topic at hand.

correct and the reason is that i needed to give you some basic education
how ciphers in the real world are negotiated

Could someone please let me know if Lists ever get back on topic with
responses to the questions and statements made, rather than charging
sideways off the field?
go and provocate someone else when you make clueless statements like
"OpenSSL has default list which includes weak ciphers (such as DES), so
using the default list is bad idea"

7 years ago by Walter Parker — view source — reply

unread

Am 05.12.2017 um 06:52 schrieb Walter Parker:
On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net mailto:lists@rhsoft.net
<lists@rhsoft.net mailto:lists@rhsoft.net> wrote:
Am 05.12.2017 um 01:19 schrieb Walter Parker:

    Oh, I see, this not about the actual change (the protocol
    version). This is about when using PHP on the client side, it
    does not support all/enough of the modern cipher suite list.

    Now that we have identified the problem in question, this should
    help you when you create your RFC to fix issues with the cipher
    suite list.

    FYI, the client and server send lists of ciphers that they
    support to each other, the server does an AND and picks the
    highest cipher in on the list. If the client sends only NULL,
    then `NULL` is the only valid cipher. OpenSSL has default list
    which includes weak ciphers (such as DES), so using the default
    list is bad idea

this is not true at all and that's why you use tools like
https://www.ssllabs.com/ssltest/     and SSLHonorCipherOrder as
serveradmin for many years if you care
about TLS at all
also the default openssl cipherlist is not just random

as you can see it prefers the ECDSA AES-GCM followed by the RSA
AES-GCM and after the ECDHE it continues with other GCM ciphers na
dthe DES/CBC stuff is at a place in the list which never is selected
these days
Your link doesn't say what you think it does
which one?
https://www.ssllabs.com/ssltest/

sorry, but if you don't know what ssllab does and how it is used by
serveradmins to make sure clients using best possible encryption you are
hardly in the position making comments like "OpenSSL has default list which
includes weak ciphers (such as DES), so using the default list is bad idea"
and instead abusive responses you could have entered the url of a TLS
webserver

Your follow up comments also appear to have little relevance to the topic

at hand.

correct and the reason is that i needed to give you some basic education
how ciphers in the real world are negotiated

Could someone please let me know if Lists ever get back on topic with

responses to the questions and statements made, rather than charging
sideways off the field?

go and provocate someone else when you make clueless statements like
"OpenSSL has default list which includes weak ciphers (such as DES), so
using the default list is bad idea"

--

Lists, I give you the same advice. I know and use SSL Labs, I been a
subscriber to Ivan's mailing list for years. Older versions of Openssl had
a default list of +ALL, -aNULL, -eNULL as the default list of ciphers.
Before DES was removed in the new versions of openssl, that means the list
included things like DES and RC4. That is why server admins always spelled
out long lists of ciphers, to guarantee that weak ciphers would not appear
on older installs. I found this information by reading the code bases
themselves, where did you find your information?

I'm done with you. You don't understand and worse you don't want to
understand but think you understand. You just admitted to that. Please stop
until you get proper training as someone else on this list might make the
same mistakes that you are.

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

7 years ago by lists@rhsoft.net — view source — reply

unread

Am 05.12.2017 um 17:45 schrieb Walter Parker:

Lists, I give you the same advice. I know and use SSL Labs, I been a
subscriber to Ivan's mailing list for years. Older versions of Openssl
had a default list of +ALL, -aNULL, -eNULL as the default list of
ciphers

yes

Before DES was removed in the new versions of openssl, that
means the list included things like DES and RC4

don't matter because no somehow recent client would have negotiated
DES/RC4 with a config like below even if the SSLCipherSuite would
contain RC4/DES at the end of the list

That is why server
admins always spelled out long lists of ciphers, to guarantee that weak
ciphers would not appear on older installs. I found this information by
reading the code bases themselves, where did you find your information?

frankly you are saying exactly the same as i did

the point is that for nearly a deacde servers take care of negotiated
ciphers and when tomorrow one of them like AES-CBC with several
vulerabilities in the past years becomes problematic like you even was
advised to prefer RC4 instead block-ciphers for the timewinodow of a
large amount unfixed clients you can as serveradmin migitate the problem

but only if the client is not PHP which thinks to outsmart client
openssl as well as servers configuration

this also makes initiatives like
https://fedoraproject.org/wiki/Changes/CryptoPolicy useless and
everything reacts faster than wait for the next PHP point release!

I'm done with you. You don't understand and worse you don't want to
understand but think you understand. You just admitted to that. Please
stop until you get proper training as someone else on this list might
make the same mistakes that you are
yes, please stop to repsond to any of my mails, especially stop offlist
mails

7 years ago by Walter Parker — view source — reply

unread

Deleted without reading...

Am 05.12.2017 um 17:45 schrieb Walter Parker:

Lists, I give you the same advice. I know and use SSL Labs, I been a
subscriber to Ivan's mailing list for years. Older versions of Openssl had
a default list of +ALL, -aNULL, -eNULL as the default list of ciphers

yes

Before DES was removed in the new versions of openssl, that means the list

included things like DES and RC4

don't matter because no somehow recent client would have negotiated
DES/RC4 with a config like below even if the SSLCipherSuite would contain
RC4/DES at the end of the list

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:ECDH
E-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

That is why server admins always spelled out long lists of ciphers, to

guarantee that weak ciphers would not appear on older installs. I found
this information by reading the code bases themselves, where did you find
your information?

frankly you are saying exactly the same as i did

the point is that for nearly a deacde servers take care of negotiated
ciphers and when tomorrow one of them like AES-CBC with several
vulerabilities in the past years becomes problematic like you even was
advised to prefer RC4 instead block-ciphers for the timewinodow of a large
amount unfixed clients you can as serveradmin migitate the problem

but only if the client is not PHP which thinks to outsmart client openssl
as well as servers configuration

this also makes initiatives like https://fedoraproject.org/wiki
/Changes/CryptoPolicy useless and everything reacts faster than wait for
the next PHP point release!

I'm done with you. You don't understand and worse you don't want to

understand but think you understand. You just admitted to that. Please stop
until you get proper training as someone else on this list might make the
same mistakes that you are

yes, please stop to repsond to any of my mails, especially stop offlist
mails

--

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

7 years ago by Sara Golemon — view source — reply

unread

Am 04.12.2017 um 18:36 schrieb Sara Golemon:

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

7 years ago by Jakub Zelenka — view source — reply

unread

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