Hi, > -----Original Message----- > From: Niklas Keller [mailto:m...@kelunik.com] > Sent: Wednesday, July 5, 2017 9:43 AM > To: Anatol Belski <weltl...@outlook.de> > Cc: Sara Golemon <poll...@php.net>; Jakub Zelenka <bu...@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > 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`. > > > > 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. > > ----- > Ok, so that's where the cat catches its tail. If there are both INI and > wrapper options, doing the same, it were excessive. Say, if the context option > has to be integrated anyway, why INI? Otherwise, if INI is supposed to provide > same separately, without touching the code - why bother with stream context? > Or in further, if the INI is supposed to be ignored in 7.2, then the code > still has to > be changed. The more complicated, the more inconsistent. > > > > If we choose to block SHA1 and MD5 certificates by default in 7.0 / 7.1, then > we > don't need the INI option. But if you decide it's not acceptable as an > important > security fix, then I definitely want a way to secure all applications at once > with a > configuration change instead of having to change each and every application to > set a default stream context option. > 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. In further - of course, blocking anything by default can be a vote option, no question. Say like by the context option, always go by the 7.2 variant. However I'd see a little sense to disabling sha1 and md5 signed certs completely. There still can be users, that trust their self-signed certificates and that can work indefinitely, whether it is good or not. This especially can concern older systems and organizations perhaps having intranet apps. In case of a complete ban, another issue would be - there's no choice other than to stay by an outdated PHP version without any chance to upgrade, except manually patching it. This is something that should not happen within a stable release line that supports older systems. See for example this link https://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-sha1-certificates.aspx . Regards Anatol
