Adding a config option in openssl.cnf to enable SHA-1 signature creation and verification #17662

sahanaprasad07 · 2022-02-08T10:28:17Z

At Red Hat, we set the SECLEVEL to 2 in DEFAULT and LEGACY policies (in crypto-policies [1], not providers). So when SECLEVEL 2 is in use, the creation and verification of SHA-1 signatures is rejected as insecure as expected.
But to be backwards compatible with systems that would migrate to OpenSSL 3.0.0 and still use SHA-1 (only for signatures), we thought of providing a config option such as allow-SHA-1-signatures, to be configured in the alg_section of openssl.cnf. When this option is set to True, we would then allow the creation and verification of SHA-1 signatures.

Would upstream be interested or do you see any value addition with this config option? Or would you have any other ideas as to how we could enable this on a need basis?

(We understand that the workaround would be to just switch to SECLEVEL 0 in such cases, but that doesn't work for us unfortunately)

[1] https://src.fedoraproject.org/rpms/crypto-policies

neverpanic · 2022-05-02T17:58:22Z

As you know, SHA-1's collision resistance is no longer what it used to be. In RHEL 9, we're shipping a downstream patch that provides an option to make creation and verification of SHA-1 signatures fail.

This patch is specific for SHA-1, so we'd like to propose an upstream change that allows achieving the same effect. Additionally, such a change should also be usable the next time we decide a digest algorithm is no longer considered secure enough for signatures.

We have SECLEVEL for TLS, but no equivalent for cryptographic usage outside of TLS. In our testing at Red Hat, we saw changes required in Kerberos, RPM signing, DNSSEC, just to name a few. In the majority of cases we encountered, more modern alternatives exist but were just not used yet.

We would propose a new option in the alg_section that allows selecting which digests are acceptable for signature creation & verification, signature verification only, or not at all. This option would affect both use in TLS (with the appropriate changes to ensure algorithms considered insecure would not be negotiated) and outside of TLS.

The configuration would look something like this:

openssl_conf = openssl_init

[openssl_init]
alg_section = evp_properties

[evp_properties]
signature_digest_algorithms = "ALL:!MD4:!MD5:!MDC2:!RIPEMD160:!SM3:~whirlpool:~SHA1:~SHA1-MD5"

This would allow disallow signature verification of signatures made with MD4, MD5, MDC2, RIPEMD160, and SM3 digests, allow verification (but not creation) of signatures with the whirlpool, SHA-1, and SHA1-MD5 hashes, and signature creation and verification using all other algorithms.

Additionally, we would like to provide public API for applications to selectively change these restrictions from their defaults in an OSSL_LIB_CTX. This would be especially useful in applications that adhere to RFCs that still require SHA-1 support. The most notable example here is DNSSEC, but see dotnet/runtime#65874 for a similar case.

This API could be:

/**
 * Override the previously set value for the signature_digest_algorithms
 * evp configuration option.
 */
int EVP_signature_digest_algorithms_set(OSSL_LIB_CTX *libctx,
                                        const char *config);

#define EVP_SIG_DIGEST_BEHAVIOR_DENY (0)
#define EVP_SIG_DIGEST_BEHAVIOR_VERIFYONLY (1)
#define EVP_SIG_DIGEST_BEHAVIOR_ALLOW (2)

/**
 * Change the behavior of the digest algorithm given by its NID in
 * signatures to either allow, verify only, or deny. Keeps the
 * previously set default for all other algorithms.
 */
int EVP_signature_digest_algorithm_set(OSSL_LIB_CTX *libctx,
                                       int mdnid, int behavior);

/**
 * Determine how signature operations with the digest algorithm given by
 * its NID are handled.
 */
int EVP_signature_digest_algorithm_supported(OSSL_LIB_CTX *libctx,
                                             int mdnid);

Before we spend time on implementing this and opening a pull request, we would welcome feedback on the approach.

Questions you may have

Could we extend SECLEVEL to apply outside of TLS?

This is probably doable, but would be some major refactoring and would remove the possibility to have tighter defaults for TLS than for other uses, which is what the majority of systems are doing right now, because SECLEVEL doesn't default to 0.

Why not introduce a SECLEVEL-like number bound to the digest's security bits?

We would argue the SECLEVEL setting is mostly just a proxy for the explicit list of algorithms, with higher effort. Researchers publish vulnerabilities of specific algorithms. System administrators should be able to specifically disallow these algorithms. At the moment, new research results require an OpenSSL update to modify the security bits for the digest.

Additionally, SECLEVEL isn't granular. System administrators and distributors may want to support TLS 1.1, which requires SHA1-MD5. As of OpenSSL 3, that requires setting SECLEVEL to 0, which allows many other algorithms.

Shouldn't applications do this, instead of OpenSSL?

Maybe. From our experience, many applications are simply not aware that they're still relying on SHA-1 digests in signatures, have newer alternatives available and are simple to fix once the developers are aware of the problem.

On the other hand, some applications are aware of their use of SHA-1 and can't move to newer alternatives yet—those would be best served by invoking the API to allow SHA-1 use.

What should the default be?

I'm not sure. If the default breaks previously supported algorithms, we probably need a release note plus a non-bugfix release to do this. On the other hand, the sooner we disallow obviously broken algorithms like MD5 in signatures, the better.

paulidale · 2022-05-03T01:45:40Z

This seems like a reasonable suggestion.

A question: how to deal with algorithms that use "broken" digests but aren't considered broken even so?
E.g. some KDFs, MACs and DRBGs can use e.g. SHA1, and although SHA1 can be attacked, these derivatives cannot be (yet).

t8m · 2022-05-03T07:50:10Z

I read this proposal as applying to signatures only. Which is IMO reasonable as signatures are vulnerable to collision attacks where most of the other uses aren't and should be handled on application-by-application basis.

paulidale · 2022-05-03T08:24:04Z

We will want to do similar for ciphers, ....

neverpanic · 2022-05-03T09:44:22Z

Yeah, this was aiming at signatures only for now. Maybe we eventually want to add a similar approach for KDFs, MACs, DRBGs, but I don't think that area is as critical at the moment considering that the collision resistance isn't required there.

bartonjs · 2022-05-03T15:10:14Z

Configuration options certainly empower users/administrators to make some blanket policy statements; but I think it's worth noting that signing and verifying have different policies applied to them.

NIST SP 800-57p1r5 (2020) still allows processing signatures based on SHA-1/SHA-2-224/SHA-2-512@224/SHA-3-224 hashes, but generally forbids creating them.

NIST SP 800-57p3r1 (2015) acknowledges that SHA-1 is, in general, bad; but carves out some specific exceptions for its use in digital signatures, such as

It is important to note that according to [SP 800-131A], SHA-1 is no longer allowed for
generating digital signatures. However, in this protocol, SHA-1 is allowed for server
authentication, as long as the public key size of the signing function (either RSA or DSA)
is at least 2048 bits

SP 800-131Ar2 (2019) allows digital signature verification based on a SHA-1 hash (for "legacy use", aka existing signatures), while generally prohibiting creating new signatures with it and saying it's a fine to use outside of digital signatures (presumably saying that HMAC-SHA-1 is still fine).

--

Personally, I think it's a bad idea to bake any policy in at this low of a level... it should just be an application decision.

In .NET we used to have policy like this, which, when enabled, prevented use of algorithms that we provided which weren't FIPS Approved (in 2005). The biggest piece of frustration was that people found they had to jump through hoops to compute the HTTP Content-MD5 header when the remote party required it (since the receiver determines policy, but the sender has to comply). After 14 years of annoying our users with this policy we ripped it out.

Based on my experience with .NET customers, blocks at the lower level just result in people writing workarounds. For DSA, no one cares. For ECDSA+SHA-1, probably no one cares. For RSA+SHA-1 there's enough of a corpus of documents that it'll be common to see naive implementations of signature verification pop up (e.g. for PKCS1 padding, verify the last N bytes of the message are the hash, but not checking the padding integrity or DigestInfo header).

Then there's always someone who has to send messages to an embedded system that was built in the early 2000s, and once they get bitten by configuration once or twice they give up and stop calling the low level functions... so non-blinding implementations of PSS will start popping up, too. (If the super-low-level RSA primitives are cut off, then they'll just write their own RSA... or let StackOverflow posts write it for them.)

Unless an API call can reset the policy, I think doing a policy at this level only makes for badness throughout the ecosystem. It was a mistake when .NET did it (since rectified), it's a mistake for Fedora/RHEL/CentOS to try it, and it'd be a mistake for OpenSSL to do it.

neverpanic · 2022-05-03T16:58:14Z

Configuration options certainly empower users/administrators to make some blanket policy statements; but I think it's worth noting that signing and verifying have different policies applied to them.

[FIPS references]

We are aware of the requirements and specifications of FIPS. I would expect the majority of OpenSSL users does not run OpenSSL in FIPS mode, so those do not apply.

The proposal above also enables users and administrators to make different provisions for signing and verifying, and I also think that the default in OpenSSL should at least keep allowing verification of SHA-1, if not also creation (see "What should the default be?" above).

Our rationale for starting to address this topic and providing users and administrators with this configuration option is the cost of a SHA1 chosen-prefix collision attack. I'm citing from SHA-1 is a Shambles:

By renting a GPU cluster online, the entire chosen-prefix collision attack on SHA-1 costed us about 75k USD. However, at the time of computation, our implementation was not optimal and we lost some time (because research). Besides, computation prices went further down since then, so we estimate that our attack costs today about 45k USD. As computation costs continue to decrease rapidly, we evaluate that it should cost less than 10k USD to generate a chosen-prefix collision attack on SHA-1 by 2025.

OpenSSL major releases packaged and installed today will probably still be used in 2025. Users or system administrators that need to protect targets with a value higher than 10k USD currently have no good tools to identify and reject such vulnerable signatures outside of TLS. This suggestion would introduce such a tool. Yes, this has the potential to break some applications. Most of those that break should move to newer hash algorithms, and those that can't for legitimate reasons will have an API available to specifically opt-in to SHA-1 (if we even decide to reject SHA-1 by default).

A chosen-prefix collision on MD5 takes about 72h to compute (i.e., is essentially free), and at the moment there is no way in OpenSSL to disable verification of signatures that use MD5. Would you also argue that OpenSSL should not have a mechanism to prevent usage of MD5?

Unless an API call can reset the policy, I think doing a policy at this level only makes for badness throughout the ecosystem. It was a mistake when .NET did it (since rectified), it's a mistake for Fedora/RHEL/CentOS to try it, and it'd be a mistake for OpenSSL to do it.

This API call is exactly what we are proposing, with your use case in .NET in mind:

Additionally, we would like to provide public API for applications to selectively change these restrictions from their defaults in an OSSL_LIB_CTX. This would be especially useful in applications that adhere to RFCs that still require SHA-1 support. The most notable example here is DNSSEC, but see dotnet/runtime#65874 for a similar case.

As such, I don't think there is a danger that developers will re-implement algorithms, when instead their current code would continue working if they add EVP_signature_digest_algorithm_set(libctx, NID_md5, EVP_SIG_DIGEST_BEHAVIOR_ALLOW);.

tomato42 · 2022-05-03T16:58:51Z

@bartonjs

hashes and digital signatures are very different. Yes, blocking sha-1 as a regular hash would likely be very disruptive, if only looking at impact of disabling MD5 hash in FIPS mode (side note: I don't see how asking users to say "yes, I'm not using it for security" with a single function call is "jumping through hoops"). But this is only about creation and verification of signatures with specific hashes so the impact is very different.
There is nothing we can do to stop people writing their own bad implementations of RSA, DSA or even ECDSA (yes, there are plenty of those too). The point is to make the reviewers/auditors jobs easier; if they see a non-native implementation they know it's garbage.
Sure, there are people that need to interact with legacy systems and they don't care about security, but we need a system that by default, out of the box is secure and depends only algorithms generally considered secure. Just because people don't notice that their systems are insecure doesn't mean that they want them to stay insecure. So yes, if people want to interoperate with old broken systems, they should use custom implementations for that.

paulidale · 2022-05-04T03:54:38Z

Another thought: I think it would make sense to have two configuration settings, one for signing and one for verifying instead of using ! and ~, we'd get away with just one -- simpler syntax means a reduced chance of errors.

neverpanic · 2022-05-04T14:15:55Z

Sure, we can make that happen:

[evp_properties]
signature_digest_algorithms_signing      = "ALL:!MD4:!MD5:!MDC2:!RIPEMD160:!SM3:!whirlpool:!SHA1:!SHA1-MD5"
signature_digest_algorithms_verification = "ALL:!MD4:!MD5:!MDC2:!RIPEMD160:!SM3"

There are upsides and downsides to this – the example above is relatively simple to compare, but consider the following form:

[evp_properties]
signature_digest_algorithms_signing = "ALL:!MD4:!SHA1:!MD5:!whirlpool:!MDC2:!RIPEMD160:!SHA1-MD5:!SM3"
signature_digest_algorithms_verification = "ALL:!RIPEMD160:!MD5:!MDC2:!MD4:!SM3"

The separate lists are probably clearer, though.

Romain-Geissler-1A · 2022-07-29T07:52:53Z

Hi,

We compile our own openssl instead of using any distro one, and we face similar needs. In the end was this discussion settled ?

Most likely we are going to get inspired by Red Hat patches https://gitlab.com/redhat/centos-stream/rpms/openssl/-/blob/c9s/0049-Selectively-disallow-SHA1-signatures.patch#L249 and https://gitlab.com/redhat/centos-stream/rpms/openssl/-/blob/c9s/0052-Allow-SHA1-in-seclevel-2-if-rh-allow-sha1-signatures.patch to patch locally our own openssl.

Cheers,
Romain

beldmit · 2022-07-29T11:16:04Z

OTC question: Do we want to have such functionality upstream?

userdocs · 2022-08-01T14:00:40Z

Hello, I think there is one problem that needs to be addressed here and I can demonstrate. An issue think it is valid and that should be handled by openssl before any patch is applied.

Problem: I build a fully static binary using Alpine/musl (and glibc if I need) using a combination of dependencies, openssl 3.0.5 being one of them, using --openssldir="/etc/ssl" and no source modifications or custom patches.

What has happened on Fedora 36 with the update package crypto-policies-20220428-1.gitdfb10ea.fc36.noarch.rpm after introducing these changes:

File: /etc/crypto-policies/back-ends/opensslcnf.config

[openssl_init]
alg_section = evp_properties

[evp_properties]
rh-allow-sha1-signatures = yes

It is that my static openssl will seg fault on Fedora 36 due to not understanding how to handle this new option, even though we are both using openssl 3.0.5.

qBittorrent version: v4.4.3.1

Caught signal: SIGSEGV
Stack trace:
Segmentation fault

I am of the opinion that whether or not openssl includes this option upstream it should perhaps not seg fault upon encountering an unrecognised option?

The fault also happened on statically linked glibc builds, not just musl with a more useful stacktrace

It should just ignore it the unknown option, I think that is the best option to apply upstream. I am sure this would cause problems with other binaries using statically linked openssl, perhaps like go builds? Any statically built openssl build that was not built on Fedora + their openssl patches

I can confirm the difference in behaviour by applying the relevant patches to my build process using these two patches:

0049-Selectively-disallow-SHA1-signatures.patch

0052-Allow-SHA1-in-seclevel-2-if-rh-allow-sha1-signatures.patch

As a combined patch (very slightly modified to work with base 3.0.5 source code)

https://raw.githubusercontent.com/userdocs/qbt_static_test/main/patches/openssl/3.0.5/patch

It can be demonstrated via docker

docker run -it -p 8080:8080 -w /root -v ~/:/root fedora:latest

Update to make sure crypto-policies-20220428-1.gitdfb10ea.fc36.noarch.rpm is installed

dnf update -y

# no patches applied
curl -Lo qbit-fail https://github.com/userdocs/qbittorrent-nox-static/releases/download/release-4.4.3.1_v2.0.7/x86_64-qbittorrent-nox
# with redhat patches c9 0049 0052
curl -Lo qbit-work https://github.com/userdocs/qbt_static_test/releases/download/release-4.4.3.1_v2.0.7/x86_64-qbittorrent-nox
chmod +x qbit-fail qbit-work

./qbit-fail # without redhat patch
./qbit-work # with redhat patch

So is it possible to have openssl behave differently if it encounters this option via statically built openssl from another Linux distribution? I think this is a valid and plausible scenario that others might encounter.

beldmit · 2022-08-01T14:09:32Z

AFAIK, OpenSSL ignores unknown configuration options. And this stacktrace doesn't mention any OpenSSL functions

Romain-Geissler-1A · 2022-08-01T14:10:22Z

I didn't check, but are you sure the problem really comes from openssl segfaulting when seeing an unknown rh-allow-sha1-signatures config file ? I think there is another explanation which looks more likely: somehow you still use sha1 signature somewhere in your tests, which is something that openssl 3 is less likely to accept (at least in the ssl stack, maybe not directly when using evp, but I didn't check) when using a security level different from 0 (and you use normally either 1 or 2 for the security level).

In our case, we had some hardcoded TLS test certificates, that we generated years ago, still using sha1 as signature algorithm. With the move to openssl 3, it was failing, and re-generating these certificates with -sha256 did fix the issue. So check what you use in your tests, and track any usage of sha1 which ideally shall be removed.

Romain-Geissler-1A · 2022-08-01T14:15:09Z

Keep accepting sha1 is needed for the people who really still use some TLS certificates using sha1 in production. Unfortunately, there are still some, for now. The long term fix being obviously to replace the production TLS certificates by newer ones, using more robust algorithms.

userdocs · 2022-08-01T14:16:07Z

Being static musl the stacktrace is not super great on glibc systems, the one i showed was from a glibc build

My dependencies are these (latest releases)

zlib-ng
iconv
openssl
boost
libtorrent
qt6base
qt6tools
qbittorrent

All I know, as it stands, is that if I apply the two Redhat patches problem is fixed.

I assumed from that. that my static openssl was getting confused when loading the /etc/ssl dir stuff.

If you can advise how I can pinpoint the true cause, i'll try to do.

beldmit · 2022-08-01T14:28:41Z

I have no idea about architecture of your application and libtorrent. I have a possibly wrong suspicion that the exception is thrown because of some unexpected error, but I may be wrong.

There may be problems if you have both statically and dynamically linked openssl, BTW...

userdocs · 2022-08-01T14:33:55Z

I will see if i can get a better glibc stacktrace but the reason I'm here in this thread is that I am patching openssl 3.0.5 with redhat patches for their changes to crypto-policy mentioned here, which fixes my issue.

That does not feel like a libtorrent issue to me, but I'm just a hobbyist so I'm open minded to accepting I might not be seeing things correctly.

If i get better stacktraces i'll add them here

beldmit · 2022-08-01T14:38:25Z

Sure, I agree it can be an unexpected consequence of our patches, but still need better stacktrace.

An exact place and relevant piece of code of exception throwing from here

0x00000000006e2150 in libtorrent::aux::session_impl::session_impl(boost::asio::io_context&, libtorrent::settings_pack const&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void>) ()

may also help.

userdocs · 2022-08-01T14:42:22Z

Thanks and i agree about the stacktrace, I think I can get the stacktraces, even build on ferdora 36 with some tweaking if needed. I'll try to get them asap

neverpanic · 2022-08-01T15:17:13Z

Note that the option discussed in this proposal is different from what RHEL and Fedora apply downstream. We're explicitly not proposing to add an allow-sha1-signatures = yes option as we did in RHEL9 and F36.

AFAIR I also tested that the modified configuration file will can still be successfully read by OpenSSL 1.1, so I'm not sure why exactly this crash is happening for you, but this wasn't a problem in my testing.

userdocs · 2022-08-01T16:37:00Z

I built on fedora and got this stack trace. I opened the issue there to avoid derailing this thread.

arvidn/libtorrent#6991

https://sha-mbles.github.io/ claims a chosen-prefix collision attack on SHA-1 is now achievable for a price of around 45k USD. As a consequence, SHA-1 should no longer be used in applications where collision resistance is required, most notably in signatures. This has been achieved in OpenSSL for TLS by increasing the default SECLEVEL, but uses of SHA-1 in signatures outside of TLS were so far not covered. Introduce the configuration options `signature_md_algorithms_signing` and `signature_md_algorithms_verification` that can contain a set of acceptable digest algorithms for use in signature creation and signature verification, respectively. Additionally, introduce functions allowing library authors to test whether a given digest is acceptable, and allowing to override the default configuration. This mechanism is not specific to SHA-1 and can also be used to block older digests, such as MD4 and MD5, or newer algorithms should further research uncover new vulnerabilities. In its default, no change to current behavior is made, i.e., all algorithms are allowed. Fixes: openssl#17662 Signed-off-by: Clemens Lang <cllang@redhat.com>

beldmit · 2022-08-29T08:21:03Z

Summary of this issue

SHA1 is sort of special algorithm because it is widely used for various purposes. It can't be disabled completely.

As it is not secure enough, it's better to stop using it in signature and verification. We can't do it explicitly in code because of legacy systems, so it needs to be done via configuration option.

We need different requirements for signature and verification - we may want to verify old signature.

We want a more general mechanism because SHA1 is not the last algorithm that would be broken

Property-based filter is not enough because it will disable the algorithm entirely, including HMAC and TLS context. SECLEVEL is also not enough granular way and doesn't affect non-TLS contexts.

Proposed solution doesn't change the default settings now but leaves this option for future, both general and per-vendor.

https://sha-mbles.github.io/ claims a chosen-prefix collision attack on SHA-1 is now achievable for a price of around 45k USD. As a consequence, SHA-1 should no longer be used in applications where collision resistance is required, most notably in signatures. This has been achieved in OpenSSL for TLS by increasing the default SECLEVEL, but uses of SHA-1 in signatures outside of TLS were so far not covered. Introduce the configuration options `signature_md_algorithms_signing` and `signature_md_algorithms_verification` that can contain a set of acceptable digest algorithms for use in signature creation and signature verification, respectively. Additionally, introduce functions allowing library authors to test whether a given digest is acceptable, and allowing to override the default configuration. This mechanism is not specific to SHA-1 and can also be used to block older digests, such as MD4 and MD5, or newer algorithms should further research uncover new vulnerabilities. In its default, no change to current behavior is made, i.e., all algorithms are allowed. Fixes: openssl#17662 Signed-off-by: Clemens Lang <cllang@redhat.com>

https://sha-mbles.github.io/ claims a chosen-prefix collision attack on SHA-1 is now achievable for a price of around 45k USD. As a consequence, SHA-1 should no longer be used in applications where collision resistance is required. Most notably, this applies to signatures. For TLS connections, OpenSSL supports limiting the supported signature algorithms by raising SECLEVEL. However, so far there was no method to prevent the use of SHA-1 is signatures outside of TLS. Introduce the configuration options `signature_md_algorithms_signing` and `signature_md_algorithms_verification` that can contain a set of acceptable digest algorithms for use in signature creation and signature verification, respectively. Additionally, introduce functions allowing library authors to test whether a given digest is acceptable, and allowing to override the default configuration. The configuration option is associated with a libctx, so it can be changed by applications if necessary. In order to make this restriction work with the FIPS provider, additionally introduce two parameters for signature providers, and implement use of these parameters in the default and the fips provider. Pass the default from the current libctx if the selected signature provider supports the parameters and the user has not specified their own value. This will mean the option will not work with 3rd party providers or old fips providers. This mechanism is not specific to SHA-1 and can also be used to block older digests, such as MD4 and MD5, or newer algorithms should further research uncover new vulnerabilities. In its default, no change to current behavior is made, i.e., all algorithms are allowed. Fixes: openssl#17662 Signed-off-by: Clemens Lang <cllang@redhat.com>

sahanaprasad07 added the issue: question The issue was opened to ask a question label Feb 8, 2022

t8m added triaged: feature The issue/pr requests/adds a feature triaged: question The issue contains a question and removed issue: question The issue was opened to ask a question labels Feb 8, 2022

pemensik mentioned this issue May 23, 2022

Sha1 runtime insecure NLnetLabs/unbound#660

Merged

beldmit added the hold: need otc decision The OTC needs to make a decision label Jul 29, 2022

userdocs mentioned this issue Jul 31, 2022

Unable to start qbee 4.4.3.12 on Fedora 36 aarch64 c0re100/qBittorrent-Enhanced-Edition#400

Open

userdocs mentioned this issue Aug 1, 2022

Fedora 36 x86_64 - crypto-policy - sha1 - segfault arvidn/libtorrent#6991

Closed

neverpanic linked a pull request Aug 29, 2022 that will close this issue

Add config option to limit MDs used in signatures #19084

Open

2 tasks

t8m removed the hold: need otc decision The OTC needs to make a decision label Sep 13, 2022

wfurt mentioned this issue Dec 13, 2022

ASP.NET 5 docker image fails to communicate with TLS1.2 server dotnet/runtime#48337

Closed

pavledjo mentioned this issue Mar 7, 2023

Use 'sha256' instead of 'sha' when validating RSA signing supportability potatosalad/erlang-jose#142

Merged

Lomilar mentioned this issue Sep 18, 2023

Crash when signing messages using RSASSA-PKCS1-v1_5 and SHA-1 hash with --force-fips + OpenSSL 3.0.3 nodejs/node#43436

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding a config option in openssl.cnf to enable SHA-1 signature creation and verification #17662

Adding a config option in openssl.cnf to enable SHA-1 signature creation and verification #17662

sahanaprasad07 commented Feb 8, 2022

neverpanic commented May 2, 2022

paulidale commented May 3, 2022

t8m commented May 3, 2022 •

edited

paulidale commented May 3, 2022

neverpanic commented May 3, 2022

bartonjs commented May 3, 2022

neverpanic commented May 3, 2022

tomato42 commented May 3, 2022

paulidale commented May 4, 2022

neverpanic commented May 4, 2022

Romain-Geissler-1A commented Jul 29, 2022

beldmit commented Jul 29, 2022

userdocs commented Aug 1, 2022

beldmit commented Aug 1, 2022

Romain-Geissler-1A commented Aug 1, 2022 •

edited

Romain-Geissler-1A commented Aug 1, 2022 •

edited

userdocs commented Aug 1, 2022 •

edited

beldmit commented Aug 1, 2022

userdocs commented Aug 1, 2022 •

edited

beldmit commented Aug 1, 2022

userdocs commented Aug 1, 2022

neverpanic commented Aug 1, 2022

userdocs commented Aug 1, 2022 •

edited

beldmit commented Aug 29, 2022

Navigation Menu

Adding a config option in openssl.cnf to enable SHA-1 signature creation and verification #17662

Adding a config option in openssl.cnf to enable SHA-1 signature creation and verification #17662

Comments

sahanaprasad07 commented Feb 8, 2022

neverpanic commented May 2, 2022

Questions you may have

Could we extend SECLEVEL to apply outside of TLS?

Why not introduce a SECLEVEL-like number bound to the digest's security bits?

Shouldn't applications do this, instead of OpenSSL?

What should the default be?

paulidale commented May 3, 2022

t8m commented May 3, 2022 • edited

paulidale commented May 3, 2022

neverpanic commented May 3, 2022

bartonjs commented May 3, 2022

neverpanic commented May 3, 2022

tomato42 commented May 3, 2022

paulidale commented May 4, 2022

neverpanic commented May 4, 2022

Romain-Geissler-1A commented Jul 29, 2022

beldmit commented Jul 29, 2022

userdocs commented Aug 1, 2022

beldmit commented Aug 1, 2022

Romain-Geissler-1A commented Aug 1, 2022 • edited

Romain-Geissler-1A commented Aug 1, 2022 • edited

userdocs commented Aug 1, 2022 • edited

beldmit commented Aug 1, 2022

userdocs commented Aug 1, 2022 • edited

beldmit commented Aug 1, 2022

userdocs commented Aug 1, 2022

neverpanic commented Aug 1, 2022

userdocs commented Aug 1, 2022 • edited

beldmit commented Aug 29, 2022

t8m commented May 3, 2022 •

edited

Romain-Geissler-1A commented Aug 1, 2022 •

edited

Romain-Geissler-1A commented Aug 1, 2022 •

edited

userdocs commented Aug 1, 2022 •

edited

userdocs commented Aug 1, 2022 •

edited

userdocs commented Aug 1, 2022 •

edited