Am 01.12.2017 um 22:49 schrieb Sara Golemon:
On Fri, Dec 1, 2017 at 11:52 AM, li...@rhsoft.net <li...@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
