RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

Hi Jakub, > -----Original Message----- > From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of Jakub > Zelenka > Sent: Wednesday, July 5, 2017 3:24 PM > To: Niklas Keller <me@kelunik.com> > Cc: Anatol Belski <weltling@outlook.de>; Sara Golemon <pollita@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > Hi, > > > On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller <me@kelunik.com > <mailto:me@kelunik.com> > wrote: > > > > > But the RFC is what you wrote about some days ago. Anything I > told is based on the RFC and the previous conversations. My understanding was, > that you were intended to push the exact RFC to vote. If you tell now there's no > approach and the RFC has to be ignored, then it doesn't help. If there's another > approach, so please present it. > > > Nobody wants to backport OpenSSL's implementation, so I don't see the > viability of supporting auth_level. > > > Backporting auth_level would be overkill but we could add a sig_level as I said > previously. It would simplify many things in the future and address exactly the > issue. Setting explicit options named by algorithm is not flexible and after couple > of years it will be just an ugly unused leftover from past... > > > > I've outlined my current suggestion several mails ago: > > ----- > > 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. > ----- > > > > I don't like adding new INI in general. It won't really help because people > won't > usually set it and changing behavior in such way is not good IMHO. > > To sum it up I'd really prefer solution based on security level (in this case just a > sig_level part of it) and have it just as a context option which could be > backported in the following way: > > 7.0 - default to 0 (the same behavior as now to be safe) > 7.1 - default to 1 (80 bits of security and more - disable md5 as it shouldn't break > too many apps and at least protect against md5 signed certs). > 7.2 - default to 2 (SHA-1 disabled as well). > Do you think it were possible to get in time with an implementation, if there's an agreement? As Sara is willing to accept a fix to this even later in the cycle, and that could be a good chance to align all the branches. As for me, this approach sounds feasible from both BC and functionality POV, except one detail - say if in 7.2 the level is for some reason have to be set to 0 because an app requires it, it should be possible at least for some time. Thanks Anatol