Re: Re: [RFC] Distrust SHA-1 Certificates

On Wed, Jul 5, 2017 at 2:34 PM, Anatol Belski <weltling@outlook.de> wrote: > 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? Yep it would be a small patch so I don't see a problem with that.. > 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. > > It would be a context option so app could change it when creating stream context. I think there is no need to have a global option as this should be specific to stream. Cheers Jakub