Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99012 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78671 invoked from network); 11 May 2017 12:27:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 May 2017 12:27:02 -0000 Authentication-Results: pb1.pair.com smtp.mail=lists@rhsoft.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=lists@rhsoft.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender) X-PHP-List-Original-Sender: lists@rhsoft.net X-Host-Fingerprint: 91.118.73.15 mail.thelounge.net Received: from [91.118.73.15] ([91.118.73.15:25773] helo=mail.thelounge.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E3/50-11470-49854195 for ; Thu, 11 May 2017 08:27:01 -0400 Received: from srv-rhsoft.rhsoft.net (Authenticated sender: h.reindl@thelounge.net) by mail.thelounge.net (THELOUNGE MTA) with ESMTPSA id 3wNsmd27ZVzXMn for ; Thu, 11 May 2017 14:26:57 +0200 (CEST) To: "internals@lists.php.net" References: <702de8c0-146e-268f-edf8-d0ea900a87e0@cubiclesoft.com> <1b631ec7-1695-8bf8-8103-a0bd498ef4fc@rhsoft.net> Message-ID: <38e71434-a443-7368-dadd-330fc5c050f2@rhsoft.net> Date: Thu, 11 May 2017 14:26:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-CH Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] TLS v1.2 -only- deployments From: lists@rhsoft.net ("lists@rhsoft.net") 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 >>>> 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"