Hi, > I'd really prefer if this RFC targeted current patch branches. I see > minimal BC impact from the change (issues may only arise when communicating > with broken TLS implementations), while *not* making the change is effectively > a BC break as more servers stop supporting TLS 1.0. >
> For the lifetime of the 7.0 and 7.1 releases, it appears much more > likely > to me that there will be more servers not supporting TLS 1.0 than servers > supporting only TLS 1.0 *and* having a broken version negotiation > implementation. > Nikita, IMHO there's too much uncertainty. It's not, that TLS 1.2 and co is not supported at all. Basically, it is an app responsibility and issues that which we should not try to fix. Real world is not going easy with the changes of this kind. There are still and will be both that change rapidly and those that stay longer. The linked doc from the original thread https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls, originally posted 2015, talks about "extending the migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS". Well, ... The issue I see to proceed this way into stable is, that the reliable stats are missing and unlikely to get. The only info for now is the original report, that *some* servers switched to TLS 1.2 only, and that there are policy changes in payment card industry which recommends an upgrade already for two years. From another point, I spoke to some arbitrary companies and individuals I could reach, where the situation is not different from "moving slow". Fe a company with up to 10-20 employs still has to support old encryption protocols, because a switch would mean they would have to throw away a half of their current hardware. It can ofc go different depending on the industry branch, where to see is even sectors like payment things go quite sluggish. Not telling it's a good situation, but kinda usual. We didn't have a policy about default TLS versions till now, so a change like that might be unexpected, depending on what OpenSSL wants to do under the hood. Perhaps, regarding such a policy, we could say, that any PHP.next whatsoever should support the latest available TLS version by default. An app can always use an explicit TLS scheme if required, or it can upgrade PHP. > > Same here, but Anatol suggested releasing this with PHP 7.2 first and if > nobody > complains, backport it to PHP 7.1 and 7.0. > Well, it was said before the patch was changed to touch ssl:// as well. In the current approach, yes for 7.2 for sure. Otherwise, at least 7.0 is already nearly half its lifetime old, so a controversial change like this is probably too late without a good reason. Niklas, I'd have yet a question about the RFC - it only deals with stream wrappers, but there are indeed some other places at least in soap and mysqlnd. Don't you think, the RFC and implementation should recapitulate those? Regards Anatol
