Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99009 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63482 invoked from network); 11 May 2017 11:24:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 May 2017 11:24:38 -0000 Authentication-Results: pb1.pair.com header.from=lists@rhsoft.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lists@rhsoft.net; spf=pass; 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:21203] helo=mail.thelounge.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B8/63-13385-4F944195 for ; Thu, 11 May 2017 07:24:37 -0400 Received: from srv-rhsoft.rhsoft.net (Authenticated sender: h.reindl@thelounge.net) by mail.thelounge.net (THELOUNGE MTA) with ESMTPSA id 3wNrNc3y1rzXKg for ; Thu, 11 May 2017 13:24:32 +0200 (CEST) To: internals@lists.php.net References: <702de8c0-146e-268f-edf8-d0ea900a87e0@cubiclesoft.com> Message-ID: <1b631ec7-1695-8bf8-8103-a0bd498ef4fc@rhsoft.net> Date: Thu, 11 May 2017 13:24:32 +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 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-tls >> >> 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 yesm boiut what *really* annoys me is that "tls://" don't just default to the most secure connection *both* sides support 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