Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99718
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.162 cause and error)
MIME-Version: 1.0
In-Reply-To: <HE1PR02MB1052A742CD23C1CA9DF54F6EBAD60@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>
Date: Mon, 3 Jul 2017 19:12:57 +0200
Message-ID: <CANUQDChRXr3FB+fa7744KaBBvawQ+QhLn8z46qAaAdU85pxtbw@mail.gmail.com>
To: Anatol Belski <weltling@outlook.de>, Sara Golemon <pollita@php.net>
Cc: Jakub Zelenka <bukka@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a113cf57ce1077305536ce0cd"
Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
From: me@kelunik.com (Niklas Keller)

--001a113cf57ce1077305536ce0cd
Content-Type: text/plain; charset="UTF-8"

>
> I haven't followed the discussion back then, but just read through. The
> discussion seems unfinished yet, as far as I understood. The two
> approaches  - the one going by security levels, and the other using
> strength bits as a argument. As for me, security levels were more future
> oriented and the original alike, while have to be emulated with older
> dependencies. On the other hand - giving the strength directly is a an
> explicit approach, even if it's completely different from the latest
> OpenSSL. It were good to hear from Jakub yet.
>
> About how to proceed - I'd say the issue is clear and either way should be
> fixed. The RFC chooses the explicit strength approach. What I'm a bit
> concerned about is, that there's no implementation by this time, neither
> for 7.2 nor for lower. Given there are indeed just last moments before the
> feature freeze, for 7.2 it depends on RMs.
>

This is caused by the approach not being clear, I have an implementation
without options locally.


> In general, I'd prefer to see the discussion to come more or less to the
> conclusion about pro/contra of the concrete approach, especially from the
> POV different OpenSSL versions and future support. If a patch with an
> implementation could make it into 7.2, the backport for lower branches will
> have no choice regarding approach. But, without being able to look at th
> patch, it is hard to say, whether a backport is even doable. For example,
> how it often could be, an implementation of a new stream context option
> might require some additional struct member, etc. Alternatively, what could
> be done - bring the approach discussion and consequently the BC
> implementation in all of 7\.[012] while letting the restrictive part to
> target 7.3. Either way, please let's see the code.
>

I think the best approach for now would be that:

Add two new context options for the "ssl" wrapper:
"insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
will both default to false starting in PHP 7.2 while the backports to PHP
7.1 and 7.0 will default to true. 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.

Regards, Niklas

--001a113cf57ce1077305536ce0cd--