# [RFC] Distrust SHA-1 Certificates - Thread: https://externals.io/message/97200 - Original archive: https://news-web.php.net/php.internals/97200 - Started by Niklas Keller on 2016-11-26T15:49:12+00:00 - Messages: 48 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/97200.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #97200 — Niklas Keller — 2016-11-26T15:49:12+00:00 URL: https://externals.io/message/97200#97200 Morning Internals, I plan to distrust SHA-1 certificates by default in PHP 7.2. All major browsers will no longer trust SHA-1 certificates starting already 2017-01-01. Unfortunately, PHP doesn't even provide a way yet to limit the accepted algorithms for certificates. The RFC fixes that and introduces new defaults for PHP 7.2. The "signature_algorithms" context option will also be backported to PHP 5.6, which is only supported until the end of 2016 with regular releases, but after that there will be two more years of security-only updates. Therefore I'd like to get this done before the end of 2016. Currently the RFC aims for BC and doesn't restrict the algorithms on older versions. As all major browsers start distrusting those certificates on 2017-01-01 I'm not sure whether that's the correct choice. I'd like to go secure-by-default there and disable SHA-1 also on older versions. People which really need longer can always opt-out and add the needed algorithms again. Unfortunately, we didn't announce any plans regarding SHA-1 yet, so this might be a bit last-minute. You can read the full RFC in the wiki: https://wiki.php.net/rfc/distrust-sha1-certificates Regards, Niklas --- ## #97202 — Stanislav Malyshev — 2016-11-26T21:06:13+00:00 URL: https://externals.io/message/97200#97202 · In reply to: #97200 Hi! > You can read the full RFC in the wiki: > https://wiki.php.net/rfc/distrust-sha1-certificates I would propose making a constant for default value. This way if your code wants to use that option is a generic way, there is a value to fall back on, and you don't need to keep around a long string that can be mis-copied, etc. -- Stas Malyshev smalyshev@gmail.com --- ## #97204 — Niklas Keller — 2016-11-27T10:38:25+00:00 URL: https://externals.io/message/97200#97204 · In reply to: #97202 > > I would propose making a constant for default value. This way if your > code wants to use that option is a generic way, there is a value to fall > back on, and you don't need to keep around a long string that can be > mis-copied, etc. > A constant for the default value doesn't make much sense to me, as you shouldn't set the default value, it's already the default. If we want constants, we could have one for SHA-1 and another for the SHA-2 group. We already have http://php.net/manual/en/openssl.signature-algos.php, but those are integers unfortunately. Regards, Niklas --- ## #97205 — Jakub Zelenka — 2016-11-27T13:06:31+00:00 URL: https://externals.io/message/97200#97205 · In reply to: #97200 > Morning Internals, > > I plan to distrust SHA-1 certificates by default in PHP 7.2. All major > browsers will no longer trust SHA-1 certificates starting already > 2017-01-01. > > Unfortunately, PHP doesn't even provide a way yet to limit the accepted > algorithms for certificates. The RFC fixes that and introduces new defaults > for PHP 7.2. The "signature_algorithms" context option will also be > backported to PHP 5.6, which is only supported until the end of 2016 with > regular releases, but after that there will be two more years of > security-only updates. Therefore I'd like to get this done before the end > of 2016. > > Currently the RFC aims for BC and doesn't restrict the algorithms on older > versions. As all major browsers start distrusting those certificates on > 2017-01-01 I'm not sure whether that's the correct choice. I'd like to go > secure-by-default there and disable SHA-1 also on older versions. People > which really need longer can always opt-out and add the needed algorithms > again. Unfortunately, we didn't announce any plans regarding SHA-1 yet, so > this might be a bit last-minute. > > You can read the full RFC in the wiki: > https://wiki.php.net/rfc/distrust-sha1-certificates > > I think you should change the format to match the one supported by OpenSSL [1] which is also simpler. In general I'm not a big fan of such defaults especially when new values can be added later (e.g. EdDSA that is specified in TLS 1.3) so we have to keep it up to date which was kind of issue in the past. However I see the point that we should make it easier for users to have it secure by default so it's probably a good choice. It's not actually just about SHA I'm not so sure about 5.6 as we are very close to the end of active support and if this introduces any bug, we won't be able to fix it. It would be also motivation for some users to update to 7. [1] https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set1_sigalgs_list.html [2] Cheers Jakub --- ## #97206 — Jakub Zelenka — 2016-11-27T13:09:21+00:00 URL: https://externals.io/message/97200#97206 · In reply to: #97205 > > > > > > […] > I think you should change the format to match the one supported by OpenSSL > [1] which is also simpler. > > In general I'm not a big fan of such defaults especially when new values > can be added later (e.g. EdDSA that is specified in TLS 1.3) so we have to > keep it up to date which was kind of issue in the past. However I see the > point that we should make it easier for users to have it secure by default > so it's probably a good choice. It's not actually just about SHA > > Ah sent before I finished it. :) I wanted to say that it's not just about SHA-1 but also MD5 that I think we might still support but would have to double check that... --- ## #97207 — Niklas Keller — 2016-11-27T14:22:18+00:00 URL: https://externals.io/message/97200#97207 · In reply to: #97206 2016-11-27 14:09 GMT+01:00 Jakub Zelenka : > > > > > > […] > It is exactly in OpenSSL's format for SSL_CTX_set1_sigalgs_list. > In general I'm not a big fan of such defaults especially when new values > > […] > That's true, but I don't see a way in OpenSSL do have a blacklist instead, but we could do that in our own verify callback. > However I see the point that we should make it easier for users to have it > > […] > > Ah sent before I finished it. :) I wanted to say that it's not just about > SHA-1 but also MD5 that I think we might still support but would have to > double check that... > I wanted to double-check that, too, but didn't do that yet. If MD5 is still supported, we should definitely put it into PHP 5.6 as a security update. As far as I can see, MD5 support is the case if it has not been disabled by the OpenSSL version in use, as all supported algorithms are allowed by default. SSL_CTX_set1_sigalgs is anyway only supported starting in OpenSSL 1.0.2, so we need a custom verify callback for older OpenSSL versions. In our own verify callback we can use a blacklist instead of the suggested whitelist by default. Regards, Niklas --- ## #97208 — Jakub Zelenka — 2016-11-27T15:10:53+00:00 URL: https://externals.io/message/97200#97208 · In reply to: #97207 > > > 2016-11-27 14:09 GMT+01:00 Jakub Zelenka : > > > […] > It is exactly in OpenSSL's format for SSL_CTX_set1_sigalgs_list. > Ah you right. I incorrectly read the RFC. So it's fine then. > > > > […] > That's true, but I don't see a way in OpenSSL do have a blacklist instead, > but we could do that in our own verify callback. > Yeah but not sure if it's ideal too. Will have to think about it. > > > > […] > > I wanted to double-check that, too, but didn't do that yet. If MD5 is > still supported, we should definitely put it into PHP 5.6 as a security > update. > > As far as I can see, MD5 support is the case if it has not been disabled > by the OpenSSL version in use, as all supported algorithms are allowed by > default. > > SSL_CTX_set1_sigalgs is anyway only supported starting in OpenSSL 1.0.2, > so we need a custom verify callback for older OpenSSL versions. In our own > verify callback we can use a blacklist instead of the suggested whitelist > by default. > > No need to add support for 1.0.1 as it's going to be EOL end of December. Lower version are EOL already. Cheers Jakub --- ## #97209 — Niklas Keller — 2016-11-27T15:17:35+00:00 URL: https://externals.io/message/97200#97209 · In reply to: #97208 > > > […] > own > > […] > No need to add support for 1.0.1 as it's going to be EOL end of December. > Lower version are EOL already. > That may be true, but we only raised the minimum requirement for newer versions of PHP. If this is going to be backported for PHP 5.6 / 7.0 / 7.1, we have to support those older OpenSSL versions I guess? Regards, Niklas --- ## #97210 — Jakub Zelenka — 2016-11-27T19:37:50+00:00 URL: https://externals.io/message/97200#97210 · In reply to: #97209 > > […] > > That may be true, but we only raised the minimum requirement for newer > versions of PHP. If this is going to be backported for PHP 5.6 / 7.0 / 7.1, > we have to support those older OpenSSL versions I guess? > > Well it depends if it requires feature available only in the later version of OpenSSL which would be the case for the currently proposed version of the RFC that would make use of SSL_CTX_set1_sigalgs_list macro. I don't think that we should parse the string of allowed sig algs and re-implement it for OpenSSL versions that are EOL anyway. It's not something unusual to have a feature dependent on the library version. For example we did exactly the some for openssl_pbkdf2 that worked only if it was compiled with OpenSSL 1.0.0+. So if you had PHP 7.0 and OpenSSL 0.9.8, it wasn't available. I have been thinking about the defaults and I don't think we should have any default value for this. Instead we should concentrate on supporting security levels [1]. That will give a much better way how to define a number of bits security. For example if we have selected level 2 to get 112 bits of security, then the SSH-1 sig algs would be automatically disabled as it offers only 80 bits of security. It would also disable all other weaker algs so user couldn't for example use RSA keys shorter than 2048 bits. That's much better and easier way for users to define the security as they would just need to set a number (from 0 to 5 atm). I'm aware that this is supported only by OpenSSL 1.1 but I wouldn't see that as an issue. At the time the PHP 7.2 is out, there will be much bigger usage of OpenSSL 1.1 and the users on lower version could still disable it manually. [1] https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_security_level.html Cheers Jakub --- ## #97211 — Niklas Keller — 2016-11-27T20:28:52+00:00 URL: https://externals.io/message/97200#97211 · In reply to: #97210 > > Well it depends if it requires feature available only in the later version > > […] > Having a feature not available is different from having a security issue if you're using the wrong OpenSSL version. > I have been thinking about the defaults and I don't think we should have > any default value for this. Instead we should concentrate on supporting > security levels [1]. That will give a much better way how to define a > number of bits security. For example if we have selected level 2 to get 112 > bits of security, then the SSH-1 sig algs would be automatically disabled > as it offers only 80 bits of security. It would also disable all other > weaker algs so user couldn't for example use RSA keys shorter than 2048 > bits. That's much better and easier way for users to define the security as > they would just need to set a number (from 0 to 5 atm). I'm aware that > this is supported only by OpenSSL 1.1 but I wouldn't see that as an issue. > At the time the PHP 7.2 is out, there will be much bigger usage of OpenSSL > 1.1 and the users on lower version could still disable it manually. > I've seen that, too. I've been confused by SHA-1 being mentioned at level 4, but I missed that it's only talking about the MAC mechanism there. I guess this is the better alternative, but in any way, we have to fix 5.6+ to remove MD5 support I think. Regards, Niklas > [1] https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_ > security_level.html > > Cheers > > Jakub --- ## #99227 — Niklas Keller — 2017-05-29T10:58:19+00:00 URL: https://externals.io/message/97200#99227 · In reply to: #97200 Morning Internals, I have updated the RFC to use a "min_signature_bits" setting instead. Please share your thoughts. https://wiki.php.net/rfc/distrust-sha1-certificates Regards, Niklas 2016-11-26 16:49 GMT+01:00 Niklas Keller : > Morning Internals, > > I plan to distrust SHA-1 certificates by default in PHP 7.2. All major > browsers will no longer trust SHA-1 certificates starting already > 2017-01-01. > > Unfortunately, PHP doesn't even provide a way yet to limit the accepted > algorithms for certificates. The RFC fixes that and introduces new defaults > for PHP 7.2. The "signature_algorithms" context option will also be > backported to PHP 5.6, which is only supported until the end of 2016 with > regular releases, but after that there will be two more years of > security-only updates. Therefore I'd like to get this done before the end > of 2016. > > Currently the RFC aims for BC and doesn't restrict the algorithms on older > versions. As all major browsers start distrusting those certificates on > 2017-01-01 I'm not sure whether that's the correct choice. I'd like to go > secure-by-default there and disable SHA-1 also on older versions. People > which really need longer can always opt-out and add the needed algorithms > again. Unfortunately, we didn't announce any plans regarding SHA-1 yet, so > this might be a bit last-minute. > > You can read the full RFC in the wiki: https://wiki.php.net/ > rfc/distrust-sha1-certificates > > Regards, Niklas --- ## #99231 — lauri.kentta@gmail.com — 2017-05-29T14:03:14+00:00 URL: https://externals.io/message/97200#99231 · In reply to: #99227 > I have updated the RFC to use a "min_signature_bits" setting instead. At least that name is misleading. Most PHP users would probably wonder why a setting of 128 does not allow the 160-bit hash from SHA-1 or the 512-bit RSA. So the name should be more like "min_cryptographic_strength" (possibly prefixed with "signature_") to make it clear that this is not really about the bits in signature. I'm not totally convinced about this bit approach in general. What happens if SHA-2 is suddenly broken and people move to SHA-3 of the same length? Just my thoughts. -- Lauri Kenttä --- ## #99235 — Jakub Zelenka — 2017-05-29T20:00:59+00:00 URL: https://externals.io/message/97200#99235 · In reply to: #99227 > Morning Internals, > > I have updated the RFC to use a "min_signature_bits" setting instead. > > Wouldn't be better use security levels instead as it is in OpenSSL? Of course I mean just for sig level to not re-implement everything. Basically having sig_level or something like that... --- ## #99237 — Niklas Keller — 2017-05-29T20:16:50+00:00 URL: https://externals.io/message/97200#99237 · In reply to: #99235 2017-05-29 22:00 GMT+02:00 Jakub Zelenka : > > > > […] > Wouldn't be better use security levels instead as it is in OpenSSL? Of > course I mean just for sig level to not re-implement everything. Basically > having sig_level or something like that... > As we can't use the OpenSSL implementation directly, I don't see any reason to use arbitrary integers there which you have to look up again. Maybe we should fine a totally different way. Regards, Niklas --- ## #99238 — Niklas Keller — 2017-05-29T20:17:40+00:00 URL: https://externals.io/message/97200#99238 · In reply to: #99231 2017-05-29 16:03 GMT+02:00 Lauri Kenttä : > > > > […] > > At least that name is misleading. Most PHP users would probably wonder why > a setting of 128 does not allow the 160-bit hash from SHA-1 or the 512-bit > RSA. So the name should be more like "min_cryptographic_strength" (possibly > prefixed with "signature_") to make it clear that this is not really about > the bits in signature. > > I'm not totally convinced about this bit approach in general. What happens > if SHA-2 is suddenly broken and people move to SHA-3 of the same length? > I'm open to better suggestions. Regards, Niklas --- ## #99253 — Niklas Keller — 2017-05-30T05:51:23+00:00 URL: https://externals.io/message/97200#99253 · In reply to: #99235 Hi Jakub, do you know how I can check whether a certificate is in the trust store or not? Regards, Niklas 2017-05-29 22:00 GMT+02:00 Jakub Zelenka : > > > > […] > Wouldn't be better use security levels instead as it is in OpenSSL? Of > course I mean just for sig level to not re-implement everything. Basically > having sig_level or something like that... --- ## #99283 — Jakub Zelenka — 2017-05-30T20:11:53+00:00 URL: https://externals.io/message/97200#99283 · In reply to: #99253 > > do you know how I can check whether a certificate is in the trust store or > not? > > I guess it depends what you want to do. If you want to check if the cert is in cert store loaded in the SSL struct, then you could get it using SSL_get_client_CA_list and then check the resulted STACK_OF(X509_NAME). If you know X509_STORE_CTX, then you should be able to get chain from it using X509_STORE_CTX_get0_chain and then go through it. But not really sure what fits best to your use case. I'd probably need look into OpenSSL internals to see what would be the best solution. Cheers Jakub --- ## #99284 — Jakub Zelenka — 2017-05-30T20:26:27+00:00 URL: https://externals.io/message/97200#99284 · In reply to: #99237 > 2017-05-29 22:00 GMT+02:00 Jakub Zelenka : > > > […] > > As we can't use the OpenSSL implementation directly, I don't see any > reason to use arbitrary integers there which you have to look up again. > Maybe we should fine a totally different way. > > Well we are going to implement security levels at some point anyway as it is the primary way how to control security strength in OpenSSL 1.1+ so people will need to look it up anyway. It is also much easier to use than directly setting security bits IMHO. It might also allow us to simplify implementation in the future (for example if it gets separated to its own verify param in the future, we could use that). Also we will be able to just completely skip that if the main security level is already on that level or higher (it would be already covered by that). Please mind that this is an openssl extension so we should prefer the API offered by the library and not trying to invent our own solutions. Cheers Jakub --- ## #99701 — Niklas Keller — 2017-07-03T13:13:50+00:00 URL: https://externals.io/message/97200#99701 · In reply to: #99284 2017-05-30 22:26 GMT+02:00 Jakub Zelenka : > > > > […] > Well we are going to implement security levels at some point anyway as it > is the primary way how to control security strength in OpenSSL 1.1+ so > people will need to look it up anyway. It is also much easier to use than > directly setting security bits IMHO. It might also allow us to simplify > implementation in the future (for example if it gets separated to its own > verify param in the future, we could use that). Also we will be able to > just completely skip that if the main security level is already on that > level or higher (it would be already covered by that). > > Please mind that this is an openssl extension so we should prefer the API > offered by the library and not trying to invent our own solutions. > > Cheers > > Jakub > What's the way to proceed now? Time is running low for the PHP 7.2 feature freeze. I've implemented it manually for https://github.com/amphp/socket/pull/31 now. The captured chain always seems to contain the trusted certificate as last certificate. Honestly, what isn't secure for the public internet PKI shouldn't be considered secure for other contexts. I'd personally be fine with not even providing a setting other than disabling verify_peer. Regards, Niklas --- ## #99717 — Anatol Belski — 2017-07-03T16:49:40+00:00 URL: https://externals.io/message/97200#99717 · In reply to: #99701 Hi, > -----Original Message----- > From: Niklas Keller [mailto:me@kelunik.com] > Sent: Monday, July 3, 2017 3:14 PM > To: Jakub Zelenka > Cc: PHP Internals > Subject: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > 2017-05-30 22:26 GMT+02:00 Jakub Zelenka : > > > […] > wrote: > > […] > > What's the way to proceed now? Time is running low for the PHP 7.2 feature > freeze. > I haven't followed the discussion back then, but just read through. The discussion seems unfinished yet, as far as I understood. The two approaches - the one going by security levels, and the other using strength bits as a argument. As for me, security levels were more future oriented and the original alike, while have to be emulated with older dependencies. On the other hand - giving the strength directly is a an explicit approach, even if it's completely different from the latest OpenSSL. It were good to hear from Jakub yet. About how to proceed - I'd say the issue is clear and either way should be fixed. The RFC chooses the explicit strength approach. What I'm a bit concerned about is, that there's no implementation by this time, neither for 7.2 nor for lower. Given there are indeed just last moments before the feature freeze, for 7.2 it depends on RMs. In general, I'd prefer to see the discussion to come more or less to the conclusion about pro/contra of the concrete approach, especially from the POV different OpenSSL versions and future support. If a patch with an implementation could make it into 7.2, the backport for lower branches will have no choice regarding approach. But, without being able to look at th patch, it is hard to say, whether a backport is even doable. For example, how it often could be, an implementation of a new stream context option might require some additional struct member, etc. Alternatively, what could be done - bring the approach discussion and consequently the BC implementation in all of 7\.[012] while letting the restrictive part to target 7.3. Either way, please let's see the code. Regards Anatol --- ## #99718 — Niklas Keller — 2017-07-03T17:12:57+00:00 URL: https://externals.io/message/97200#99718 · In reply to: #99717 > > I haven't followed the discussion back then, but just read through. The > discussion seems unfinished yet, as far as I understood. The two > approaches - the one going by security levels, and the other using > strength bits as a argument. As for me, security levels were more future > oriented and the original alike, while have to be emulated with older > dependencies. On the other hand - giving the strength directly is a an > explicit approach, even if it's completely different from the latest > OpenSSL. It were good to hear from Jakub yet. > > About how to proceed - I'd say the issue is clear and either way should be > fixed. The RFC chooses the explicit strength approach. What I'm a bit > concerned about is, that there's no implementation by this time, neither > for 7.2 nor for lower. Given there are indeed just last moments before the > feature freeze, for 7.2 it depends on RMs. > This is caused by the approach not being clear, I have an implementation without options locally. > In general, I'd prefer to see the discussion to come more or less to the > conclusion about pro/contra of the concrete approach, especially from the > POV different OpenSSL versions and future support. If a patch with an > implementation could make it into 7.2, the backport for lower branches will > have no choice regarding approach. But, without being able to look at th > patch, it is hard to say, whether a backport is even doable. For example, > how it often could be, an implementation of a new stream context option > might require some additional struct member, etc. Alternatively, what could > be done - bring the approach discussion and consequently the BC > implementation in all of 7\.[012] while letting the restrictive part to > target 7.3. Either way, please let's see the code. > 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. Regards, Niklas --- ## #99722 — Sara Golemon — 2017-07-03T17:21:48+00:00 URL: https://externals.io/message/97200#99722 · In reply to: #99717 > About how to proceed - I'd say the issue is clear and either way > should be fixed. The RFC chooses the explicit strength approach. > What I'm a bit concerned about is, that there's no implementation > by this time, neither for 7.2 nor for lower. Given there are indeed > just last moments before the feature freeze, for 7.2 it depends on RMs. > I've told Niklas on Twitter, but I'll repeat here for the record. I fully expect a rush of last-minute RFCs "urgently" needing an extension of the feature freeze deadline. These come every new release as people are shocked to discover that timetables exist. IMO any RFC which does not have a merged implementation by July 20th* should assume it's not making it into 7.2, however RFCs will be taken on a case-by-case basis while in the beta period. As to this one: It certainly seems important that we don't let users blindly ignore terrible certificates. That's a false sense of security, and is arguably worse than no security at all. I expect to allow this RFC as far out as beta2 ASSUMING the implementation is sensible enough to get a passing vote from internals. If it moves things along smoother/quicker, I would suggest to constrain this discussion as though it were ONLY targeting 7.2, and we can have a separate discussion about how/when it should be back-ported to 7.1 and 7.0 since this change does represent a (theoretical**) BC break. -Sara * Yes, this includes ext/sodium, and I'm less inclined to extend lee-way to that for a number of reasons. ** Legitimately signed sites should not actually be a problem, AIUI. --- ## #99723 — Sara Golemon — 2017-07-03T17:24:34+00:00 URL: https://externals.io/message/97200#99723 · In reply to: #99718 > 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 understand what you're going for there, but it's just a bit weird to have that INI option exist for a weird pair of version ranges and not forward. I'd say keep the INI in 7.2 and (perhaps) mark them deprecated. There's no sense making that upgrade path unreasonably difficult. -Sara --- ## #99724 — Niklas Keller — 2017-07-03T18:11:45+00:00 URL: https://externals.io/message/97200#99724 · In reply to: #99723 2017-07-03 19:24 GMT+02:00 Sara Golemon : > > > […] > I understand what you're going for there, but it's just a bit weird to > have that INI option exist for a weird pair of version ranges and not > forward. I'd say keep the INI in 7.2 and (perhaps) mark them > deprecated. There's no sense making that upgrade path unreasonably > difficult. > True, but I'd like it to be an INI option to strengthen the security, but not allow to weaken it. You really shouldn't use MD5 or SHA1 for TLS certificates 2018 (!). If you really need it there, you can still set a default stream context option, but we won't clutter the INI options of future versions. Regards, Niklas --- ## #99732 — Davey Shafik — 2017-07-04T06:53:17+00:00 URL: https://externals.io/message/97200#99732 · In reply to: #99724 It should be noted that Certificate Authorities (CAs) haven't been issuing SHA-1 certs since December 31st 2015. I think the best solution if possible, would be to treat MD5 and SHA-1 certs as invalid in _all_ supported versions of PHP and requiring that the verify_peer option be set to false to accept them. For PHP 7.2 also add deprecation notices. For PHP 7.3 and later, remove support completely. > 2017-07-03 19:24 GMT+02:00 Sara Golemon : > > > […] > > True, but I'd like it to be an INI option to strengthen the security, but > not allow to weaken it. You really shouldn't use MD5 or SHA1 for TLS > certificates 2018 (!). If you really need it there, you can still set a > default stream context option, but we won't clutter the INI options of > future versions. > > Regards, Niklas --- Next page: https://externals.io/message/97200.md?page=2