Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99015
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain librelamp.com designates 45.79.96.192 as permitted sender)
To: internals@lists.php.net
References: <702de8c0-146e-268f-edf8-d0ea900a87e0@cubiclesoft.com>
 <VI1PR02MB1054AA17A954A35AE746B90ABAED0@VI1PR02MB1054.eurprd02.prod.outlook.com>
Message-ID: <f4b7d4fc-906e-eeb9-b149-c8d5ac035b7f@librelamp.com>
Date: Thu, 11 May 2017 07:05:26 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <VI1PR02MB1054AA17A954A35AE746B90ABAED0@VI1PR02MB1054.eurprd02.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] TLS v1.2 -only- deployments
From: alice@librelamp.com (Alice Wonder)

On 05/11/2017 04:08 AM, Anatol Belski wrote:
> Hi Thomas,
>
>> -----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-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.
>>
> What were interesting is to know some exact servers you mention to verify, if it were possible to call them by name. In general, probably having some reliable stats on the matter were not bad. Particularly with the reason you suspect - so if the changes are driven by the payment branch, they probably should be respected by both apps and servers. If some server providers do changes suddenly, thus breaching customer apps, we need to evaluate the extent of the breach. Fe stats linked by the Qualys labs itself tell there are still over 90% of of about 140 000 servers supporting TLS 1.0. OFC. Though, there are some billions of servers around the globe, so not sure how the stats are representative. 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.
>
> Regards
>
> Anatol
>

I won't list them here because they are not the kind of sites 
appropriate for a list, but I am doing this with servers I admin.

My current policy is that with every cert that expires (I generate new 
keys/certs yearly), when I bring the new cert into service, it is TLS 
1.2 only. And with an extremely limited list of allowed ciphers.

TLS 1.0 is old and at this point, the only browsers that do not support 
TLS 1.2 with the limited ciphers I allow are browsers that are no longer 
even getting security updates from their vendors.

As such there is no point in continued support of them, and supporting 
deprecated clients is dangerous.