Am 11.05.2017 um 14:18 schrieb Anatol Belski:
-----Original Message-----
From: li...@rhsoft.net [mailto:li...@rhsoft.net]
Sent: Thursday, May 11, 2017 1:25 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] TLS v1.2 -only- deployments
Am 11.05.2017 um 13:08 schrieb Anatol Belski:
-----Original Message-----
From: Thomas Hruska [mailto:thru...@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development <internals@lists.php.net>
Subject: [PHP-DEV] TLS v1.2 -only- deployments
Over the past two weeks, I've observed quite a bit of PHP 7+ userland
code breaking due to remote hosts switching to a TLS 1.2 only policy.
For various specific reasons, I strongly suspect that PCI DSS 3.1
implementations or compliance audits against that spec have something
to do with the changes that I'm seeing:
https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tl
s
In just the last two weeks, I've seen completely unrelated servers of
various vendors go offline for an upgrade. When they come back up a
short bit later, they are suddenly configured for TLS 1.2 only.
Running a Qualys SSL labs test confirms the changes. It's a rather
specific change to encounter in such a short period of time.
PHP userland code (e.g. stream_socket_client()) is unable to connect
to such hosts via "tls://" host strings. The string has to be
updated to use the version- specific string "tlsv1.2://" before the connecting
code starts working again.
I think in any case, especially if apps are branch specific, explicit
TSL 1.2 is probably the best way, like anything explicit in security
yes but what *really* annoys me is that "tls://" don't just default to the most
secure connection *both* sides support
Yes, that's the current implementation. If there can be a better
implementation, perhaps it were worth it to pursue.
shouldn't "tls://" just handover the handshake stuff to openssl?
what do you do in a few years - change again userland php-code to "tlsv1.3://" -
franly that don't belong in any PHP script at all because PHP is nothing else
than i
client here and a random developer sould not need to know ahything about that
low level things
For things like payments - certainly, the explicit highest security goes over
any automatic negotiation. Standards don't change every day and a maintained
app should follow the changes in the industry. Fe the particular doc there
suggest an explicit migration path for the branch specific apps, explicitly
mentioning to prefer TSL 1.2. On the other hand, for general purposes, one
would want to keep the supported range as wide as possible
it's fine that you can write "tlsv1.2://", "tlsv1.3://" explicit where
it makes sense but you should not need to do so and just be able to say
"tls://" and except that the underlying ssl library does the best
possible handshake
the current implementation makes "SSLHonorCipherOrder" and
"SSLCipherSuite" with a ordering to pass ssllabs on the serversie
pointless when a stupid client just uses TLS1.0
maybe the underlying reason is the same that mysqli for encrypted
database connections is using "DHE-RSA-AES128-SHA" while /etc/my.cnf on
the database server has "ssl-cipher =
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:RSA-AES256-SHA"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
