Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99836
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.174 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <HE1PR02MB10525C8674C3C8655DA0F844BAA90@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>
 <CANUQDChnN1Mi6E-EUPgFkr5muHCkQt7xDA5F8oy5h2Cxph6Q3w@mail.gmail.com>
 <HE1PR02MB1052F972CF1C581D0A38EB76BAD70@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <CANUQDChUwSWmXj4ddsTs8Zqbvku3bVQJBGc2605Zxysg+NgO+Q@mail.gmail.com>
 <HE1PR02MB105289B5F24BE29088A82C72BAD70@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <CANUQDChcHqbmhbb3H9c10a=DE3Smm3aagOCFd+8dx4NyMPaLGA@mail.gmail.com>
 <HE1PR02MB1052BB64ED18F8AEF2B6B701BAD40@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <CANUQDCgQj6AsGLUAwfPYwhLA+4mbZNRkdmVh2-Ms45q8Suuk9w@mail.gmail.com>
 <HE1PR02MB1052F6DCE13BFC510F92E0E7BAD50@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <HE1PR02MB10525C8674C3C8655DA0F844BAA90@HE1PR02MB1052.eurprd02.prod.outlook.com>
Date: Tue, 11 Jul 2017 17:34:54 +0100
Message-ID: <CAEKnhAEdo69u1gnuNX3OvM-1XayOeHqJCbE9f21GGCf+i-Nfww@mail.gmail.com>
To: Anatol Belski <weltling@outlook.de>
Cc: Niklas Keller <me@kelunik.com>, Sara Golemon <pollita@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11473dbe87c4a305540d47a2"
Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
From: bukka@php.net (Jakub Zelenka)

--001a11473dbe87c4a305540d47a2
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 10, 2017 at 9:54 PM, Anatol Belski <weltling@outlook.de> wrote:

> Hi,
>
> > -----Original Message-----
> > From: Anatol Belski [mailto:weltling@outlook.de]
> > Sent: Thursday, July 6, 2017 4:52 PM
> > To: Niklas Keller <me@kelunik.com>
> > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP
> > Internals <internals@lists.php.net>
> > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> >
> > Morning, guys,
> >
> > > -----Original Message-----
> > > From: Niklas Keller [mailto:me@kelunik.com]
> > > Sent: Wednesday, July 5, 2017 4:39 PM
> > > To: Anatol Belski <weltling@outlook.de>
> > > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP
> > > Internals <internals@lists.php.net>
> > > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> > >
> > >     Ok, so you strive to create a completely new RFC with a solution
> > > based on today's situation. I think you still don't see my point. Say
> > > there's insecure_allow_sha1_signature, which is a stream context. Then
> > >
> > >
> > >     - in 7.0 and 7.1
> > >       - if absent, insecure_allow_sha1_signature = true
> > >       - if present, the given value taken
> > >       - impact for 7.2 migration - if explicit
> > > insecure_allow_sha1_signature = false is in the code, no impact
> > >     - in 7.2
> > >       - if absent, insecure_allow_sha1_signature = false
> > >       - if present, depending on the decision either the exact value is
> > > taken or ignored
> > >       - future impact - none, the option can be even silently removed
> > >     - in 7.3
> > >       - removed and disabled completely
> > >
> > >     No see same if insecure_allow_sha1_signature is an INI
> > >
> > >     - in 7.0 and 7.1
> > >       - if not set, insecure_allow_sha1_signature = On
> > >       - if set, the given value is taken
> > >       - impact for 7.2 migration - depending on decision, either it's
> > > deprecated warning or disabled by default
> > >     - in 7.2
> > >       - if not set, insecure_allow_sha1_signature = Off
> > >       - if set, the given value is taken, warning is issued
> > >     - in 7.3
> > >       - removed and disabled completely
> > >
> > >     Both options do same, but in different manner. Both have advantages
> > > and downsides, but one option only is both necessary and sufficient to
> > > achieve the goal.
> > >
> > >
> > >
> > > You plan assumes we'll disallow sha1 / md5 completely in the future,
> > > dunno whether that'll be the case. I'd prefer that.
> > >
> > Nome, that's not mine, it's was your intention as I've remembered, might
> be
> > wrong. Anyway, what I wanted is only to show the redundancy having
> multiple
> > ways to do same.
> >
> > Anyway, now that Jakub also responded with an approach as well, maybe
> it's
> > time to get an RFC get the thing done? It could have the two suggestions
> > brought till now as an "exclusive or" choice and the disablement plan.
> The one
> > that won would be followed up. An implementation were great to have
> before.
> >
> > Both suggestions, either the separate context options for md5 and sha1,
> or
> > security levels, do same job and only differ in the way it's done. The
> downside of
> > security levels is, that fe the suggested security level 2 will disable
> both, while
> > user might want to disable only sha1, that's where the separate options
> win on
> > flexibility. Whereby having a higher security level should automatically
> ensure a
> > certain weak functionality is disabled at once, which has some use as
> well. IMO,
> > the INI option is a no go - the argument that user can get everything
> done at
> > once breaks encapsulation, as not every stream in the app might require
> it.
> >
> > The plan about the default disablement by version brought by Jakub sounds
> > plausible, as for me. IMHO the complete disablement should not be a part
> of this
> > RFC.
> >
> > I would suggest, it's time to get on RFC and bust this issue. It would
> be great, if
> > all the interested parties could cooperate on this.
> >
> Any news on the topic?
>
>
After reading related discussion on openssl-users [1], I'm not so sure if
we should be doing that at all...

Especially I agree with this bit:

"Making your code more complex is a far higher risk than a practical
certificate forgery based on a collision attack on SHA-1. "

The only thing, that makes sense IMHO would be adding support for setting
security level only for OpenSSL 1.1.

[1]
http://openssl.6102.n7.nabble.com/Rejecting-SHA-1-certificates-td71439.html

Cheers

Jakub

--001a11473dbe87c4a305540d47a2--