Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object
Am 14.03.2016 um 18:48 schrieb Salz, Rich via RT: > Did you enable RC4 when you built openssl? Yes, more specifically I did not disable it. Otherwise it would not have been possible to encrypt with RC4 with "openssl cms -rc4 -encrypt", would it? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4429 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object
I had written a message about this issue to openssl-users, but received no reaction. As OpenSSL cannot decrypt data encrypted by itself, this looks like a defect. It is also not possible to decrypt RC4-encrypted CMS objects created by third-party software. This was reproduced with the current HEAD revision from the OpenSSL_1_0_2-stable branch, namely with Git revision e76f48539109829819aabc03953cf2cfd4612961. How to reproduce: Create a self-signed certificate, encrypt some data as a CMS message with "-rc4" using the certificate as a recipient, and try to decrypt it again. This fails with an error message: $ echo "abcdefg" >data.txt $ openssl req -x509 -newkey rsa:2048 -keyout key.pem -nodes -out cert.pem -days 100 -subj "/CN=RC4 CMS Test" Generating a 2048 bit RSA private key +++ ...+++ writing new private key to 'key.pem' - $ openssl cms -rc4 -encrypt -binary -in data.txt -out data.txt.cms -outform DER cert.pem $ openssl cms -decrypt -in data.txt.cms -inform DER -out data2.txt -inkey key.pem -recip cert.pem Error decrypting CMS structure 140735291474768:error:2E078066:CMS routines:cms_EncryptedContent_init_bio:cipher parameter initialisation error:cms_enc.c:128: With other encryption algorithms, this works as expected. The same problem is also reproducible with the "openssl smime" command. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4429 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3719] Bug report: Documentation for -no_explicit option of openssl ocsp missing
There's no documentation available for the -no_explicit option of openssl ocsp: https://www.openssl.org/docs/apps/ocsp.html Dr. Henson explained the meaning of the option and of the corresponding flag OCSP_NOEXPLICIT for OCSP_basic_verify() like this on the openssl-users list: If the responder root CA is set to be trusted for OCSP signing then it can be used to sign OCSP responses for any certificate (aka a global responder). This comes under: 1. Matches a local configuration of OCSP signing authority for the certificate in question or alternatively: Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response. from RFC2560 et al. If the -no_explicit flag is set or OCSP_NOEXPLICIT is set then this behaviour is disabled. -- Stephan ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl.org #3415] Bug report: Uninitialized memory reads reported by valgrind for ECDSA signatures
The OpenSSL FAQ says that with a -DPURIFY build no messages about uninitialized data should appear: https://www.openssl.org/support/faq.html#PROG14 14. Why does Valgrind complain about the use of uninitialized data? When OpenSSL's PRNG routines are called to generate random numbers the supplied buffer contents are mixed into the entropy pool: so it technically does not matter whether the buffer is initialized at this point or not. Valgrind (and other test tools) will complain about this. When using Valgrind, make sure the OpenSSL library has been compiled with the PURIFY macro defined (-DPURIFY) to get rid of these warnings. The following test was done with Git commit id 802fdcda1ebc4241a8e02af0046ba2f5264f71f6 from the OpenSSL_1_0_2-stable branch on Linux Intel 64-bit. I added the following line to the Configure script (I want to compile with -DPURIFY, but without actually running the compiler under the purify command): mypurify, gcc:-g -DPURIFY -Wall::(unknown)::, Executed the following commands: $ ./Configure mypurify no-dso no-shared no-asm $ make depend $ make clean $ make $ make test Go to the test directory and execute the ecdsatest executable under valgrind: $ cd test $ valgrind ./ecdsatest ==31925== Memcheck, a memory error detector ==31925== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==31925== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==31925== Command: ./ecdsatest ==31925== some tests from X9.62: testing prime192v1: ok testing prime239v1: ==31925== Use of uninitialised value of size 8 ==31925==at 0x459E40: bn_GF2m_mul_1x1 (bn_gf2m.c:145) ==31925==by 0x45A030: bn_GF2m_mul_2x2 (bn_gf2m.c:215) ==31925==by 0x45A99A: BN_GF2m_mod_mul_arr (bn_gf2m.c:417) ==31925==by 0x438959: ec_GF2m_simple_field_mul (ec2_smpl.c:702) ==31925==by 0x438BC3: gf2m_Madd (ec2_mult.c:128) ==31925==by 0x439391: ec_GF2m_montgomery_point_multiply (ec2_mult.c:284) ==31925==by 0x439616: ec_GF2m_simple_mul (ec2_mult.c:355) ==31925==by 0x419B9D: EC_POINTs_mul (ec_lib.c:1057) ==31925==by 0x419C2C: EC_POINT_mul (ec_lib.c:1071) ==31925==by 0x41C9A9: EC_KEY_generate_key (ec_key.c:284) ==31925==by 0x401B32: x9_62_test_internal (ecdsatest.c:202) ==31925==by 0x401DF5: x9_62_tests (ecdsatest.c:266) ==31925== ==31925== Use of uninitialised value of size 8 ==31925==at 0x459E58: bn_GF2m_mul_1x1 (bn_gf2m.c:146) ==31925==by 0x45A030: bn_GF2m_mul_2x2 (bn_gf2m.c:215) ==31925==by 0x45A99A: BN_GF2m_mod_mul_arr (bn_gf2m.c:417) ==31925==by 0x438959: ec_GF2m_simple_field_mul (ec2_smpl.c:702) ==31925==by 0x438BC3: gf2m_Madd (ec2_mult.c:128) ==31925==by 0x439391: ec_GF2m_montgomery_point_multiply (ec2_mult.c:284) ==31925==by 0x439616: ec_GF2m_simple_mul (ec2_mult.c:355) ==31925==by 0x419B9D: EC_POINTs_mul (ec_lib.c:1057) ==31925==by 0x419C2C: EC_POINT_mul (ec_lib.c:1071) ==31925==by 0x41C9A9: EC_KEY_generate_key (ec_key.c:284) ==31925==by 0x401B32: x9_62_test_internal (ecdsatest.c:202) ==31925==by 0x401DF5: x9_62_tests (ecdsatest.c:266) ... and so on... The full report is to big to include it inline, I add it as a compressed attachment. -- Stephan ecdsatest.valgrind.txt.gz Description: GNU Zip compressed data
[openssl.org #3349] Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
Am 09.05.14 00:53, schrieb Stephen Henson via RT:
On Thu May 08 15:49:11 2014, s...@pdflib.com wrote:
I can confirm that with this patch applied my use case with
X509_verify_cert() works as expected (misidentification of signing
certificate as CRL issuer no longer occurs).
Could you give me more details of this case? If possible if you could send the
certificates and CRLs involved (privately if you wish).
It may be possible to address this case in X509_verify_cert() itself.
I have prepared a second test certificate testcert2.pem, a
corresponding CRL testcrl.pem, and a new test program x509_verify.c
that reproduces the issue in the full context of X509_verify_cert().
The callback function verify_cb() for X509_verify_cert() ignores all
errors related to the validation of the certificate chain, in order to
allow verification of other formal certificate requirements.
Actual result of running the test program:
verify_cb: certificate subject: CN=ATS PLOP User AKID,O=PDFlib
GmbH,L=Munich,C=DE
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY ignored
verify_cb: certificate subject: CN=ATS PLOP User AKID,O=PDFlib
GmbH,L=Munich,C=DE
X509_V_ERR_KEYUSAGE_NO_CRL_SIGN not ignored
error 35 at 0 depth lookup: key usage does not include CRL signing
X509_verify_cert returns false
Expected result:
The verify_cb() function should not be invoked with the
X509_V_ERR_KEYUSAGE_NO_CRL_SIGN error, and X509_verify_cert() should
return true.
--
Stephan
testcert2.pem
Description: application/x509-ca-cert
testcrl.pem
Description: application/x509-ca-cert
/*
* Test program for OpenSSL RT bug #3349
*
* The verify_cb() function intentionally ignores all errors regarding
* the verification of the certificate chain, to allow for validation of
* other formal requirements. The problem is that the certificate to be
* verified is misidentifed as the CRL issuer certificate, which
* causes the incorrect X509_V_ERR_KEYUSAGE_NO_CRL_SIGN error.
*/
#include stdio.h
#include openssl/err.h
#include openssl/bio.h
#include openssl/evp.h
#include openssl/x509.h
#include openssl/x509v3.h
#include openssl/pem.h
#include openssl/engine.h
static BIO *bio_stdout = 0;
static
int
verify_cb(int ok, X509_STORE_CTX *ctx)
{
if (!ok)
{
int cert_error = X509_STORE_CTX_get_error(ctx);
X509 *current_cert = X509_STORE_CTX_get_current_cert(ctx);
X509_NAME *x509_subject = X509_get_subject_name(current_cert);
printf(verify_cb: certificate subject: );
X509_NAME_print_ex(bio_stdout, x509_subject, 0, XN_FLAG_RFC2253);
printf(\n);
switch (cert_error)
{
case X509_V_ERR_UNABLE_TO_GET_CRL:
printf(X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT ignored\n);
ok = 1;
break;
case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
printf(X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT ignored\n);
ok = 1;
break;
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
printf(X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN ignored\n);
ok = 1;
break;
case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:
printf(X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY ignored\n);
ok = 1;
break;
case X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE:
printf(X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE ignored\n);
ok = 1;
break;
case X509_V_ERR_CERT_UNTRUSTED:
printf(X509_V_ERR_CERT_UNTRUSTED ignored\n);
ok = 1;
break;
case X509_V_ERR_KEYUSAGE_NO_CRL_SIGN:
printf(X509_V_ERR_KEYUSAGE_NO_CRL_SIGN not ignored\n);
break;
default:
break;
}
if (!ok)
{
printf(\t%serror %d at %d depth lookup: %s\n,
X509_STORE_CTX_get0_parent_ctx(ctx) ? [CRL path] : ,
cert_error,
X509_STORE_CTX_get_error_depth(ctx),
X509_verify_cert_error_string(cert_error));
}
}
return ok;
}
int
main()
{
BIO *pem;
const char *certfile = testcert2.pem;
const char *crlfile = testcrl.pem;
X509 *cert;
X509_STORE *store;
X509_STORE_CTX *ctx;
X509_VERIFY_PARAM *vpm;
BIO *bio_crl;
X509_CRL *crl;
STACK_OF(X509_CRL) *crls;
bio_stdout = BIO_new_fp(stdout, BIO_NOCLOSE);
pem = BIO_new(BIO_s_file());
BIO_read_filename(pem, certfile);
cert = PEM_read_bio_X509_AUX(pem, NULL, NULL, NULL);
store = X509_STORE_new();
X509_STORE_set_verify_cb(store, verify_cb);
vpm = X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(vpm,
X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);
X509_STORE_set1_param(store, vpm);
bio_crl = BIO_new(BIO_s_file());
BIO_read_filename(bio_crl, crlfile);
crl = PEM_read_bio_X509_CRL(bio_crl, NULL, NULL, NULL);
BIO_free(bio_crl);
[openssl.org #3349] Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
I posted this test case for function X509_check_akid() on the
openssl-users mailing list, but got no reaction, therefore I'm
submitting it now as a defect for triaging.
Test case:
1) Certificate that has an Authority Key Identifier extension (save as
file testcert.pem):
-BEGIN CERTIFICATE-
MIIBvzCCASigAwIBAgIBAjANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdUZXN0
IENBMB4XDTE0MDUwMjA5MDI1OFoXDTE0MDYwMTA5MDI1OFowFDESMBAGA1UEAwwJ
VGVzdCBDZXJ0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCwnv66JvZTVaf
Z3tqMo5od80yv9J0rxUMlAPXFiRM3P/JgDjW5NVIt2Ryaqwd7qZFN1f0HpcQAM5m
SJsQpi8ZxbfGB9BIt7SgRuKdj5ntDX1WJ84gl4C8R2t75B8d0WrJBJUYL2XCOEnu
S0RpfxvLZryH8Pr48Wp8NM6gONAjgQIDAQABoyMwITAfBgNVHSMEGDAWgBQLHOwh
WWaA9y49g7bt77DLa5/RKjANBgkqhkiG9w0BAQsFAAOBgQB7Md75mT3aHcR1vyf7
q8t5+x2JzbXxY3bSF1eRreaC65luDGwHrwd8e6vsYQGfOL35Q9lz+6eJRQWFsLkV
LoILyOEJlfJIN2hX7ZOphTsQ4xhgUanBtQBh7a3if4ywF6YMS8XgBwCxXcmrndGm
OZLjSWhsx6spsyLl56iduRWtzQ==
-END CERTIFICATE-
2) Test program that loads the certificate and invokes X509_check_akid()
for the certificate with its own Authority Key Identifier (all error
checks omitted for brevity):
snip ---
/*
* Test program for X509_check_akid()
*
* The program loads a certificate that has the
* X509v3 Authority Key Identifier and invokes X509_check_akid()
* with this authority key identifier and the certificate itself.
*/
#include stdio.h
#include openssl/err.h
#include openssl/bio.h
#include openssl/evp.h
#include openssl/x509.h
#include openssl/x509v3.h
#include openssl/pem.h
int
main()
{
BIO *pem;
const char *file = testcert.pem;
X509 *cert;
int akid_check;
pem = BIO_new(BIO_s_file());
BIO_read_filename(pem, file);
cert = PEM_read_bio_X509_AUX(pem, NULL, NULL, NULL);
X509_check_purpose(cert, -1, -1);
akid_check = X509_check_akid(cert, cert-akid);
printf(X509_check_akid result %d '%s'\n, akid_check,
X509_verify_cert_error_string(akid_check));
return 0;
}
--- snip ---
Actual result:
When compiled and executed with a current OpenSSL build from the
OpenSSL_1_0_2-stable branch the program prints:
X509_check_akid result 0 'ok'
Expected result:
X509_check_akid() should return an error code because the certificate
actually cannot be identified as its own issuer via the X509v3 Authority
Key Identifier extension.
Background:
The test case scenario actually occurs in an application that uses
X509_verify_cert() where certain checks are disabled through a callback
function applied with X509_STORE_set_verify_cb(). A certificate is
incorrectly identified as the CRL issuer certificate through this behavior.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3309] Bug: Missing critical flag for extended key usage not detected in time-stamp verification
Am 15.04.14 20:00, schrieb Stephen Henson via RT: The cause was that the lastpost parameter was set to 0 instead of -1. The purpose of lastpos is to find multiple extensions of the same time so you can continue from the last found position or -1 to start from the beginning. Erroneously setting it to 0 will mean it misses the extension if it is first. Thanks for identifying the cause. I've just added a fix (and to two other cases in the same file). Let me know of any problems. I've applied your suggested fix locally (replaced 0 with -1 in the calls to X509_get_ext_by_NID()), and I can confirm that it corrects the problem. In what OpenSSL version(s) will this fix be included? Will it be included in OpenSSL 1.0.2? I could not yet see it in the public Git repository. Thanks Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3309] Bug: Missing critical flag for extended key usage not detected in time-stamp verification
Am 15.04.14 20:00, schrieb Stephen Henson via RT: I've just added a fix (and to two other cases in the same file). Let me know of any problems. The commit now showed up in the public Git repository, so I'm all set now. Best Regards Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3309] Bug: Missing critical flag for extended key usage not detected in time-stamp verification
Hi,
the following problem was reproduced with several OpenSSL 1.0.1 versions
and also with a recent build from the OpenSSL_1_0_2-stable branch:
RFC 3161 says in 2.3. Identification of the TSA:
The corresponding certificate MUST contain only one instance of the
extended key usage field extension as defined in [RFC2459] Section
4.2.1.13 with KeyPurposeID having value:
id-kp-timeStamping. This extension MUST be critical.
The openssl ts -verify command resp. the corresponding function
check_purpose_timestamp_sign() in source file v3_purp.c does check
this requirement. However, the check fails to detect a missing critical
flag if the extensions of the TSA certificate are arranged in a specific
order.
How to reproduce:
Save the three attachments into a directory and run the shell script
tsacritical.sh. The shell scripts creates a CA and TSA certificate
from scratch, creates a time-stamp request, a corresponding time-stamp
reply and verifies the time-stamp reply.
Actual output (only last two lines):
Response has been generated.
Verification: OK
Expected result:
The time-stamp response must not be generated because of the missing
critical flag for the extended key usage field extension.
The expected result actually is produced if the order of the extension
in the TSA certificate is reversed. See file tsa.extfile:
With this order the missing critical flag is not detected:
extendedKeyUsage = timeStamping
keyUsage = critical,nonRepudiation
When the order is reversed, the missing critical flag is detected:
keyUsage = critical,nonRepudiation
extendedKeyUsage = timeStamping
With this order of extensions the openssl ts -reply command will fail
with the following expected error message when running the test script:
Response is not generated.
140735124738912:error:2F083075:time stamp
routines:TS_RESP_CTX_set_signer_cert:invalid signer certificate
purpose:ts_rsp_sign.c:206:
The problematic source code is in function
check_purpose_timestamp_sign() in source file v3_purp.c:
/* Only time stamp key usage is permitted and it's required. */
if (!(x-ex_flags EXFLAG_XKUSAGE) || x-ex_xkusage != XKU_TIMESTAMP)
return 0;
/* Extended Key Usage MUST be critical */
i_ext = X509_get_ext_by_NID((X509 *) x, NID_ext_key_usage, 0);
if (i_ext = 0)
{
X509_EXTENSION *ext = X509_get_ext((X509 *) x, i_ext);
if (!X509_EXTENSION_get_critical(ext))
return 0;
}
return 1;
With the bad extension order (1) extendedKeyUsage, (2) keyUsage the
function X509_get_ext_by_NID() does not retrieve the extension and
returns a negative return value. Therefore the condition (i_ext = 0) is
false and 1 is returned.
I was not able to find the root cause why X509_get_ext_by_NID() fails to
retrieve the extension here, but the function
check_purpose_timestamp_sign() should also not return 1 if the extended
key usage extension cannot be retrieved, as the first if statement has
already checked via the flags that the extended key usage exists and the
the value is timeStamping.
Best Regards
Stephan Muehlstrasser
[ tsa_config1 ]
serial = tsaserial
digests = md5, sha1, sha256, sha384, sha512
default_policy = 1.2.3.4
crypto_device = builtin
[ tsa_cert ]
# This extension order triggers the bug that OpenSSL cannot detect
# the absence of the critical flag of the extendedKeyUsage extension
extendedKeyUsage = timeStamping
keyUsage = critical,nonRepudiation
# With this order the timestamp certificate is correctly rejected by
# openssl ts -reply
# keyUsage = critical,nonRepudiation
# extendedKeyUsage = timeStamping
tsacritical.sh
Description: Bourne shell script
