OpenSSL API CRL Revoke Check: Coverage
Hello, I'm trying to use OpenSSL to validate a certificate chain with CRLs. To achieve this, I create a X509_STORE and add trusted (root) certificates into it via X509_STORE_add_cert(). I also add CRLs published by root and intermediate CAs into the store using X509_STORE_add_crl(). Then I create a X509_STORE_CTX for this store and using X509_STORE_CTX_init() function I set intermediate certs via its chain parameter and target (leaf) cert via its x509 parameter. When I verify cert chain using X509_verify_cert: - Are these CRLs checked for a valid digital signature (both CRLs root & intermediate) ? - Since store should only contain trusted root certificates why should I add CRLs published by intermediate certificates into the store but not to somewhere else (for example ctx)? - Documentation for X509_STORE_add_crl "Untrusted objects should not be added in this way". What does this mean? Dennis K.
TYPE_new() and TYPE_free()
Assuming that I use the ASN1_SEQUENCE, ASN1_SEQUENCE_END, DECLARE_ASN1_FUNCTIONS, IMPLEMENT_ASN1_FUNCTIONS macros ... TYPE_free() says that it frees all sub-objects. Can I assume that, if the sub-objects are also defined with those macros, that it will iterate all the way? TYPE_new() allocates the object. Does it set all the pointers to NULL, and iterate down through sub-structure - so that the free is safe?
Re: openssl 3.0.0 valgrind failure on OPENSSL_ia32_cpuid - retract, sorry
On 8/27/2021 3:46 PM, Ken Goldman wrote: I run valgrind on all my software to find memory leaks. This worked for openssl 1.0.2 and 1.1.1, but fails with 3.0.0. Suggestions? Sorry, I updated valgrind and all is well.
Re: openssl 3.0.0 valgrind failure on OPENSSL_ia32_cpuid
On Fri, Aug 27, 2021 at 2:47 PM Ken Goldman wrote: > > I run valgrind on all my software to find memory leaks. This worked for > openssl 1.0.2 and 1.1.1, but fails with 3.0.0. Suggestions? > > vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x49 0x89 0xD8 > 0x31 > vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 > vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F > vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=1 > ==29625== valgrind: Unrecognised instruction at address 0x56b2b10. > ==29625==at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) > ==29625==by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) > ==29625==by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3) > ==29625== Your program just tried to execute an instruction that Valgrind > ==29625== did not recognise. There are two possible reasons for this. > ==29625== 1. Your program has a bug and erroneously jumped to a non-code > ==29625==location. If you are running Memcheck and you just saw a > ==29625==warning about a bad jump, it's probably your program's fault. > ==29625== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==29625==i.e. it's Valgrind's fault. If you think this is the case or > ==29625==you are not sure, please let us know and we'll try to fix it. > ==29625== Either way, Valgrind will now raise a SIGILL signal which will > ==29625== probably kill your program. > ==29625== > ==29625== Process terminating with default action of signal 4 (SIGILL) > ==29625== Illegal opcode at address 0x56B2B10 > ==29625==at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) > ==29625==by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) > ==29625==by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3) > I stopped using valgrind awhile ago, because I had too many issues with false positives, etc. I really noticed this when dealing with glib/dbus. At this time, I made the switch to ASAN and both gcc and clang support it and the diagnostics have been better than anything I got with valgrind; it's been many years and I never looked back. Just google your compiler and asan and you should get guides, but in general it's as easy as adding CFLAGS='-O0 -g -fsanitize=address -fno-omit-frame-pointer' Then just run the binary as normal. You may need to set up the symbolizer to resolve addresses to file/line names. IIRC its via the ASAN_SYMBOLIZER_PATH and that is discussed further in the ASAN docs. I would give that a try, that's what I am using for OpenSSL 3.0 integration and fuzzing in my CI's Bill
openssl 3.0.0 valgrind failure on OPENSSL_ia32_cpuid
I run valgrind on all my software to find memory leaks. This worked for openssl 1.0.2 and 1.1.1, but fails with 3.0.0. Suggestions? vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x49 0x89 0xD8 0x31 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=1 ==29625== valgrind: Unrecognised instruction at address 0x56b2b10. ==29625==at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) ==29625==by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) ==29625==by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3) ==29625== Your program just tried to execute an instruction that Valgrind ==29625== did not recognise. There are two possible reasons for this. ==29625== 1. Your program has a bug and erroneously jumped to a non-code ==29625==location. If you are running Memcheck and you just saw a ==29625==warning about a bad jump, it's probably your program's fault. ==29625== 2. The instruction is legitimate but Valgrind doesn't handle it, ==29625==i.e. it's Valgrind's fault. If you think this is the case or ==29625==you are not sure, please let us know and we'll try to fix it. ==29625== Either way, Valgrind will now raise a SIGILL signal which will ==29625== probably kill your program. ==29625== ==29625== Process terminating with default action of signal 4 (SIGILL) ==29625== Illegal opcode at address 0x56B2B10 ==29625==at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) ==29625==by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) ==29625==by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3)
openssl-1.1.1l fails to build in macOS 10.13.6 with Xcode 10.1
Building openssl-1.1.1l with Xcode 10.1 under macOS 10.13.6 fails with this error In file included from crypto/rand/rand_unix.c:38: /usr/include/CommonCrypto/CommonRandom.h:35:9: error: unknown type name 'CCCryptorStatus' typedef CCCryptorStatus CCRNGStatus; ^ crypto/rand/rand_unix.c:385:47: error: use of undeclared identifier 'kCCSuccess' if (CCRandomGenerateBytes(buf, buflen) == kCCSuccess) ^ 2 errors generated. make[1]: *** [crypto/rand/rand_unix.o] Error 1 The build succeeds and all tests pass if CommonCryptoError.h is added to the __APPLE__ includes in crypto/rand/rand_unix.c #if defined(__APPLE__) # include # include #endif Is this a safe change to make? Best regards, Scott
Query regarding openssl-3.0.0 ecdsa self tests
Hi, Does openssl-3.0.0 really does ecdsa KAT ? The post test logs says "ECDSA KAT :PASS. But when i debuged the code it actually doing ECDSA pairwise consistency test. Thanks, Nagarjun
RE: SM2 fix in 1.1.1l
> From: Nicola Tuveri > Sent: Friday, 27 August, 2021 07:04 > As such only applications programmatically using the SM2 public key encryption > algorithm (and decryption in particular) should be affected by the mentioned > security advisory. Thanks -- that's exactly what I was looking for. -- Michael Wojcik
Re: 3.0.0. IMPLEMENT_ASN1_FUNCTIONS missing _it prototypes
On 8/24/2021 5:56 AM, Matt Caswell wrote:
On 23/08/2021 20:42, Ken Goldman wrote:
I get warnings on all my ASN1_SEQUENCE_END, a missing prototype for the _it
functions.
The code is working, but I'd like a clean compile.
3.0.0 only, 1.0.2 and 1.1.1 are OK.
Example:
#include
#include
#include
#include
typedef struct {
ASN1_TIME *notBefore;
ASN1_TIME *notAfter;
} TPM_PARTIAL_CERT_VALIDITY;
ASN1_SEQUENCE(TPM_PARTIAL_CERT_VALIDITY) = {
ASN1_SIMPLE(TPM_PARTIAL_CERT_VALIDITY, notBefore, ASN1_TIME),
ASN1_SIMPLE(TPM_PARTIAL_CERT_VALIDITY, notAfter, ASN1_TIME),
} ASN1_SEQUENCE_END(TPM_PARTIAL_CERT_VALIDITY)
Change this line to:
} static_ASN1_SEQUENCE_END(TPM_PARTIAL_CERT_VALIDITY)
static_ worked on 3.0, 1.1.1, and 1.0.2. I found that
it failed on 1.0.1e with:
certifyx509.c:125: error: expected ',' or ';' before 'static_ASN1_SEQUENCE_END'
certifyx509.c:128: warning: no previous prototype for 'TPM_ADDTOCERT_new'
If this makes sense, I can add an ifdef.
(Support for 1.0.1 is a requirement. Sorry.)
Re: SM2 fix in 1.1.1l
[CVE-2021-3711] (https://www.openssl.org/news/secadv/20210824.txt) only applies to SM2 decryption, i.e., it is not related to the digital signature or key exchange algorithms in the SM2 family. In the 1.1.1 branch of OpenSSL, libssl does not support RFC 8998, but in any case RFC 8998 only involves the digital signature and key exchange algorithms of SM2, not the public key encryption algorithm for which the security advisory has been released. As such only applications programmatically using the SM2 public key encryption algorithm (and decryption in particular) should be affected by the mentioned security advisory. Best regards, Nicola Tuveri On Fri, Aug 27, 2021, 15:40 Michael Wojcik wrote: > I imagine I could figure this out by reading the source, but does the SM2 > fix (the high-severity issue for OpenSSL 1.1.1l) apply to TLS using SMx > (RFC 8998), or just to applications that use SM2 directly via the EVP API? > It wasn't clear from the announcement, unless I missed something. > > > > We'll be picking up 1.1.1l shortly, but I'd like to be able to clarify the > situation for management and customers. > > > > -- > > Michael Wojcik >
SM2 fix in 1.1.1l
I imagine I could figure this out by reading the source, but does the SM2 fix (the high-severity issue for OpenSSL 1.1.1l) apply to TLS using SMx (RFC 8998), or just to applications that use SM2 directly via the EVP API? It wasn't clear from the announcement, unless I missed something. We'll be picking up 1.1.1l shortly, but I'd like to be able to clarify the situation for management and customers. -- Michael Wojcik
Re: How to get "EVP_PKEY *dhpkey" from NID_X9_62_prime256v1.
On 27/08/2021 08:47, Kumar Mishra, Sanjeev wrote: Hi All, I am upgrading the code from OpenSSL 1.0.1 to OpenSSL 3.0. I am getting compilation errors for deprecated functions and structure like "EC_KEY_new_by_curve_name()" , "SSL_CTX_set_tmp_ecdh()" and "EC_KEY"..etc. The code is like follows -- --- --- EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); SSL_CTX_set_tmp_ecdh(mrmIcbPtr -> sslServerCtx, ecdh); . . The SSL_CTX_set_tmp_ecdh man page says this: "SSL_CTX_set_tmp_ecdh() sets ECDH parameters to be used to be B. The key is inherited by all B objects created from B. This macro is deprecated in favor of L." https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_tmp_ecdh.html So call SSL_CTX_set1_groups() instead: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html Actually, even easier you can call SSL_CTX_set1_groups_list() (documented on the same man page), which means you can just set the group via a string: SSL_CTX_set1_groups_list(mrmIcbPtr -> sslServerCtx, "P-256"); Where "P-256" is the string name associated with NID_X9_62_prime256v1. Or your final alternative is to not doing anything at all, and simply remove this code. In 3.0 you can specify multiple groups and they have sensible defaults that are already set for you (which include X25519 and P-256). Matt
How to get "EVP_PKEY *dhpkey" from NID_X9_62_prime256v1.
Hi All, I am upgrading the code from OpenSSL 1.0.1 to OpenSSL 3.0. I am getting compilation errors for deprecated functions and structure like "EC_KEY_new_by_curve_name()" , "SSL_CTX_set_tmp_ecdh()" and "EC_KEY"..etc. The code is like follows -- --- --- EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); SSL_CTX_set_tmp_ecdh(mrmIcbPtr -> sslServerCtx, ecdh); . . I got one replacement as int SSL_CTX_set0_tmp_dh_pkey(SSL_CTX *ctx, EVP_PKEY *dhpkey); Now, it will require "EVP_PKEY *dhpkey" Now How to get "EVP_PKEY *dhpkey" from NID_X9_62_prime256v1. ? I am searching the work around of above code. Thanks in anticipation ! Sanjeev Kumar Mishra Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
Re: HMAC verification with EVP Interface
On Thu, 2021-08-26 at 16:27 -0500, William Roberts wrote: > On Thu, Aug 26, 2021 at 3:01 AM Tomas Mraz wrote: > > > > On Wed, 2021-08-25 at 13:20 -0500, William Roberts wrote: > > > Hello, > > > > > > I am trying to verify an HMAC signature with the code below and > > > the > > > EVP_DigestVerifyInit() > > > routine is failing with "error:0608F096:digital envelope > > > routines:EVP_PKEY_verify_init:operation not supported for this > > > keytype". Eventually it gets to EVP_PKEY_verify_init() and since > > > the > > > ctx->pmeth->verify pointer is null, it sets this error. It's > > > unclear > > > to me why this function pointer is NULL, can someone elaborate > > > the > > > right way to do this via EVP interfaces? > > > > As HMAC is not a true signature algorithm there is no support for > > the EVP_DigestVerifyInit() operation with HMAC 'signatures'. You > > just > > have to use EVP_DigestSign*() operation to create a new HMAC and > > compare with the original value. > > > > Ahh okay thanks. This was in the wiki I just scrolled too far and > ended up under asymmetric. > For anyone looking it was on the on the wiki here: > - https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying > > But considering that Verifying could do this, since it has both the > message and hmac > "signature", wouldn't it be nice to add this support since it's > generated through the > sign interface? In my mind a Sign operation always has a verify > operation. There is EVP_MAC API in the 3.0 release and the HMAC support in EVP Signing API is legacy although it is not explicitly deprecated. So it is unlikely to be enhanced in the suggested way. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: HMAC verification with EVP Interface
> > Don't forget to use CRYPTO_memcmp for comparing the HMACs, not regular > > ol' memcmp. > > What's the rationale? The HMAC result isn't secret. The _purported_ tag is public, but the _ground truth_ tag is not. Indeed, that's the whole reason to use a constant time compare. Otherwise, an attacker can adaptively construct a valid tag, or forgery, for a chosen message (with no previous valid tag seen) by varying tag bytes and submitting a chosen message with the candidate tag for verification, and measuring the time. A regular memcmp will early exit on the first mismatch between the purported tag and the ground truth tag. In this way, the attack is linear in complexity. This is the textbook example I give in my crypto courses for timing attacks. Cheers, BBB
