Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99744
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.161 cause and error)
MIME-Version: 1.0
In-Reply-To: <HE1PR02MB105234EBBCC3B38F2D5105B3BAD70@HE1PR02MB1052.eurprd02.prod.outlook.com>
References: <CANUQDCiUYNwH_tkZyS_cbWVa1X=4CAA3_14VD+fYjAXk-JU=1g@mail.gmail.com>
 <CANUQDChzB7EYyx8QOPgDC2TPR7n-h-dK43tHDfTZ=ocHPLHSOQ@mail.gmail.com>
 <CAEKnhAH8eGzcUsWODc75_L1kq4OtF2bvR7qJkijWWSVoY7c_mQ@mail.gmail.com>
 <CANUQDChVGuF1rrG3+AVTT+pp0nEmDw7MXyGGX7nVbQ42Kpgytw@mail.gmail.com>
 <CAEKnhAH78Uey_Tp43UY+AVaADi-ckvtBW9EqsuKTj8iDfK+AGQ@mail.gmail.com>
 <CANUQDCivjqg_NN+Zr_ZWWxh8mQyV3JVi1JDSY-ymVoc8ZKyR6w@mail.gmail.com>
 <HE1PR02MB1052A742CD23C1CA9DF54F6EBAD60@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <CANUQDChRXr3FB+fa7744KaBBvawQ+QhLn8z46qAaAdU85pxtbw@mail.gmail.com>
 <CAESVnVoO-Pe+SQeCn1gywQaZA4z4nL7Mtq+7PwYWeAbP=3juZQ@mail.gmail.com>
 <CANUQDChhO7A6by5tcimeEobaP-4k1TRsm4sXh75=K2sCi5HzHQ@mail.gmail.com> <HE1PR02MB105234EBBCC3B38F2D5105B3BAD70@HE1PR02MB1052.eurprd02.prod.outlook.com>
Date: Tue, 4 Jul 2017 20:20:50 +0200
Message-ID: <CANUQDChnN1Mi6E-EUPgFkr5muHCkQt7xDA5F8oy5h2Cxph6Q3w@mail.gmail.com>
To: Anatol Belski <weltling@outlook.de>
Cc: Sara Golemon <pollita@php.net>, Jakub Zelenka <bukka@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a1134f6cc781d3f055381f1f7"
Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
From: me@kelunik.com (Niklas Keller)

--001a1134f6cc781d3f055381f1f7
Content-Type: text/plain; charset="UTF-8"

2017-07-04 13:33 GMT+02:00 Anatol Belski <weltling@outlook.de>:

> Hi,
>
> > -----Original Message-----
> > From: Niklas Keller [mailto:me@kelunik.com]
> > Sent: Monday, July 3, 2017 8:12 PM
> > To: Sara Golemon <pollita@php.net>
> > Cc: Anatol Belski <weltling@outlook.de>; Jakub Zelenka <bukka@php.net>;
> PHP
> > Internals <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> >
> > 2017-07-03 19:24 GMT+02:00 Sara Golemon <pollita@php.net
> > <mailto:pollita@php.net> >:
> >
> >
> >       On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller <me@kelunik.com
> > <mailto:me@kelunik.com> > wrote:
> >       > Additionally there will be two INI options
> >       > which are only added to PHP 7.1 and 7.0 to allow people to
> > immediately
> >       > upgrade to secure defaults without any risk of breaking other
> apps.
> >       >
> >       I understand what you're going for there, but it's just a bit
> weird to
> >       have that INI option exist for a weird pair of version ranges and
> not
> >       forward.   I'd say keep the INI in 7.2 and (perhaps) mark them
> >       deprecated.  There's no sense making that upgrade path unreasonably
> >       difficult.
> >
> >
> >
> > True, but I'd like it to be an INI option to strengthen the security,
> but not allow
> > to weaken it. You really shouldn't use MD5 or SHA1 for TLS certificates
> 2018 (!).
> > If you really need it there, you can still set a default stream context
> option, but
> > we won't clutter the INI options of future versions.
> >
> An INI option doesn't seem necessary. If there's a stream context option,
> the existing code has to be touched. Those who do it, know what they do.
> Same as with the other issue about TLS - stable branches, that have active
> users already, we shouldn't enforce the change, but just offer it.
>

The issue without INI option is that it requires a code change. We can't
just tell people "better apply this configuration change to have secure
TLS". I'd definitely want this to be enabled _everywhere_.


> I'd be also against an INI option in the sense it's being suggested,
> because it would be not useful in 7.2 and above. As you mention also, they
> may have the reverse effect in 7.2.


We can prevent the reverse effect by ignoring it if it has bad security
effects.


> The current RFC doesn't mention any INI, and I think it's too much
> inconsistency having both ini and stream context.


Forget about everything that's in the RFC about the actual implementation.
It's an older idea that needs to be updated based on what's suggested and
seems acceptable.


> As linked in the other mail, what we could do is introduce INI options
> only, Java alike, that would control the behavior same way in every branch.
> As much as almost no one likes new INI options, it would mean likely no
> backport were required.


You still need to backport it then.


> A stream context option sounds more plausible and future oriented to me,
> however.


Regards, Niklas

--001a1134f6cc781d3f055381f1f7--