Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][VOTE] Improved SSL / TLS constants »

[RFC][VOTE] Improved SSL / TLS constants

php.internals

Niklas Keller

9 years ago
Morning, I hereby open the vote on the "Improved SSL / TLS constants" RFC. This RFC proposes to change PHP's TLS constants to sane values. This change has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This RFCs favors better security instead of backwards compatibility with version intolerant and out of date servers. You can find the full RFC here: https://wiki.php.net/rfc/improved-tls-constants Regards, Niklas

lists@rhsoft.net

9 years ago
Am 29.05.2017 um 09:48 schrieb Niklas Keller:
> Morning, > > I hereby open the vote on the "Improved SSL / TLS constants" RFC. > > This RFC proposes to change PHP's TLS constants to sane values. This change > has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This > RFCs favors better security instead of backwards compatibility with version > intolerant and out of date servers. > > You can find the full RFC here: > https://wiki.php.net/rfc/improved-tls-constants
Make tls:// default to TLSv1.0 + TLSv1.1 + TLSv1.2 this is nice for a limited timeframe but the wrong approach to begin with - it is *not* the business of PHP at all until *explicit* requested from the uselrand code to interfer with *anything* in context of the TLS handshake it's the job of the underlying openssl library, how it is built and shipped by the distribution becaus ethey you support implicit TLS1.3 and a future TLS1.4, don't weaken things like https://fedoraproject.org/wiki/Changes/CryptoPolicy and respect san econfigured servers which are regulary checked with https://www.ssllabs.com/ssltest/

Niklas Keller

9 years ago
2017-05-29 10:18 GMT+02:00 lists@rhsoft.net <lists@rhsoft.net>:
> > > Am 29.05.2017 um 09:48 schrieb Niklas Keller: > >> Morning, >> >> I hereby open the vote on the "Improved SSL / TLS constants" RFC. >> >> This RFC proposes to change PHP's TLS constants to sane values. This >> change >> has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This >> RFCs favors better security instead of backwards compatibility with >> version >> intolerant and out of date servers. >> >> You can find the full RFC here: >> https://wiki.php.net/rfc/improved-tls-constants >> > > Make tls:// default to TLSv1.0 + TLSv1.1 + TLSv1.2 > > this is nice for a limited timeframe but the wrong approach to begin with > - it is *not* the business of PHP at all until *explicit* requested from > the uselrand code to interfer with *anything* in context of the TLS > handshake > > it's the job of the underlying openssl library, how it is built and > shipped by the distribution becaus ethey you support implicit TLS1.3 and a > future TLS1.4, don't weaken things like https://fedoraproject.org/wiki > /Changes/CryptoPolicy and respect san econfigured servers which are > regulary checked with https://www.ssllabs.com/ssltest/
Unfortunately, the underlying OpenSSL library fails providing sane defaults. There are plans to switch to another mechanism supporting a `min_version` and `max_version` instead, but this is not a thing yet. Regards, Niklas

Jakub Zelenka

9 years ago
On Mon, May 29, 2017 at 9:18 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:
> > > Am 29.05.2017 um 09:48 schrieb Niklas Keller: > >> Morning, >> >> I hereby open the vote on the "Improved SSL / TLS constants" RFC. >> >> This RFC proposes to change PHP's TLS constants to sane values. This >> change >> has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This >> RFCs favors better security instead of backwards compatibility with >> version >> intolerant and out of date servers. >> >> You can find the full RFC here: >> https://wiki.php.net/rfc/improved-tls-constants >> > > Make tls:// default to TLSv1.0 + TLSv1.1 + TLSv1.2 > > this is nice for a limited timeframe but the wrong approach to begin with > - it is *not* the business of PHP at all until *explicit* requested from > the uselrand code to interfer with *anything* in context of the TLS > handshake > > it's the job of the underlying openssl library, how it is built and > shipped by the distribution becaus ethey you support implicit TLS1.3 and a > future TLS1.4, don't weaken things like https://fedoraproject.org/wiki > /Changes/CryptoPolicy and respect san econfigured servers which are > regulary checked with https://www.ssllabs.com/ssltest/ > >
Once the TLS 1.3 support is added, it will be in it as well. I think we should stay away from setting specific protocols and go just for min and max which is the way that OpenSSL is going though. Cheers Jakub

Nikita Popov

9 years ago
On Mon, May 29, 2017 at 9:48 AM, Niklas Keller <me@kelunik.com> wrote:
> Morning, > > I hereby open the vote on the "Improved SSL / TLS constants" RFC. > > This RFC proposes to change PHP's TLS constants to sane values. This change > has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This > RFCs favors better security instead of backwards compatibility with version > intolerant and out of date servers. > > You can find the full RFC here: > https://wiki.php.net/rfc/improved-tls-constants > > Regards, Niklas >
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

Niklas Keller

9 years ago
2017-05-29 12:56 GMT+02:00 Nikita Popov <nikita.ppv@gmail.com>:
> On Mon, May 29, 2017 at 9:48 AM, Niklas Keller <me@kelunik.com> wrote: > >> Morning, >> >> I hereby open the vote on the "Improved SSL / TLS constants" RFC. >> >> This RFC proposes to change PHP's TLS constants to sane values. This >> change >> has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This >> RFCs favors better security instead of backwards compatibility with >> version >> intolerant and out of date servers. >> >> You can find the full RFC here: >> https://wiki.php.net/rfc/improved-tls-constants >> >> Regards, Niklas >> > > 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. >
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. Regards, Niklas

Anatoliy Belsky

9 years ago
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

Jakub Zelenka

9 years ago
On Mon, May 29, 2017 at 7:59 PM, Anatol Belski <ab@php.net> wrote:
> 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. > >
I agree with Anatol. I don't think we should backport those changes. Especially for the tls:// changes that have a real BC (yes there are server that hang when 1.2 is negotiated and I have experienced it). That said I think it's good for 7.2! Regards Jakub

Niklas Keller

9 years ago
Hey Anatol,
> 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? >
Do you have a link to those places? Regards, Niklas

Anatoliy Belsky

9 years ago
Hi Niklas,
> -----Original Message----- > From: Niklas Keller [mailto:me@kelunik.com] > Sent: Monday, May 29, 2017 10:14 PM > To: Anatol Belski <ab@php.net> > Cc: Nikita Popov <nikita.ppv@gmail.com>; PHP Internals > <internals@lists.php.net> > Subject: Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants > > Hey Anatol, > > > 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? >
Yep, here you are https://github.com/php/php-src/blob/master/ext/soap/php_http.c#L305 https://github.com/php/php-src/blob/master/ext/mysqlnd/mysqlnd_net.c#L974 Basically it is the same story, as the old definitions are used, which the RFC aims to replace. It might be consistent to have the behavior synced, or at least to evaluate it. And, there might yet some places, not expecting much but just to be aware. Regards Anatol

Niklas Keller

9 years ago
2017-05-29 22:29 GMT+02:00 Anatol Belski <ab@php.net>:
> Hi Niklas, > > > -----Original Message----- > > From: Niklas Keller [mailto:me@kelunik.com] > > Sent: Monday, May 29, 2017 10:14 PM > > To: Anatol Belski <ab@php.net> > > Cc: Nikita Popov <nikita.ppv@gmail.com>; PHP Internals > > <internals@lists.php.net> > > Subject: Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants > > > > Hey Anatol, > > > > > > 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? > > > Yep, here you are > > https://github.com/php/php-src/blob/master/ext/soap/php_http.c#L305 > https://github.com/php/php-src/blob/master/ext/mysqlnd/mysqlnd_net.c#L974 > > Basically it is the same story, as the old definitions are used, which the > RFC aims to replace. It might be consistent to have the behavior synced, or > at least to evaluate it. And, there might yet some places, not expecting > much but just to be aware. > > Regards
Hi Anatol, I upgraded STREAM_CRYPTO_METHOD_TLS_CLIENT to be an alias to STREAM_CRYPTO_METHOD_TLS_ANY_CLIENT now, so that automatically upgrades any use of STREAM_CRYPTO_METHOD_TLS_CLIENT to use TLS 1.1 or TLS 1.2 if available. Regards, Niklas

Niklas Keller

9 years ago
2017-06-04 11:22 GMT+02:00 Niklas Keller <me@kelunik.com>:
> 2017-05-29 22:29 GMT+02:00 Anatol Belski <ab@php.net>: > >> Hi Niklas, >> >> > -----Original Message----- >> > From: Niklas Keller [mailto:me@kelunik.com] >> > Sent: Monday, May 29, 2017 10:14 PM >> > To: Anatol Belski <ab@php.net> >> > Cc: Nikita Popov <nikita.ppv@gmail.com>; PHP Internals >> > <internals@lists.php.net> >> > Subject: Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants >> > >> > Hey Anatol, >> > >> > >> > 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? >> > >> Yep, here you are >> >> https://github.com/php/php-src/blob/master/ext/soap/php_http.c#L305 >> https://github.com/php/php-src/blob/master/ext/mysqlnd/mysqlnd_net.c#L974 >> >> Basically it is the same story, as the old definitions are used, which >> the RFC aims to replace. It might be consistent to have the behavior >> synced, or at least to evaluate it. And, there might yet some places, not >> expecting much but just to be aware. >> >> Regards > > > Hi Anatol, > > I upgraded STREAM_CRYPTO_METHOD_TLS_CLIENT to be an alias > to STREAM_CRYPTO_METHOD_TLS_ANY_CLIENT now, so that automatically > upgrades any use of STREAM_CRYPTO_METHOD_TLS_CLIENT to use TLS 1.1 or TLS > 1.2 if available. > > Regards, Niklas >
Hey everyone, thanks for voting! The voting has now been closed with 14 votes in favor and 0 against. You can see the full results on the voting page as always: https://wiki.php.net/rfc/improved-tls-constants#voting Regards, Niklas