> > > 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. Regards, Niklas
