Re: TLS v1.2 -only- deployments

Am 11.05.2017 um 14:18 schrieb Anatol Belski:

-----Original Message----- From: lists@rhsoft.net [mailto:lists@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:thruska@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"