From nayak_purushotham at yahoo.com Thu Jan 1 20:17:32 2015 From: nayak_purushotham at yahoo.com (Purushotham Nayak) Date: Thu, 1 Jan 2015 20:17:32 +0000 (UTC) Subject: [openssl-users] OpenSSL AES encryption using AES_* functions and EVP_* functions In-Reply-To: <001a01d02532$4bca5c50$e35f14f0$@prinpay.com> References: <001a01d02532$4bca5c50$e35f14f0$@prinpay.com> Message-ID: <1428150525.3458232.1420143452809.JavaMail.yahoo@jws10619.mail.bf1.yahoo.com> Happy new year and thanks for the response. > EVP will by default add and remove PKCS5 (or more exactly PKCS7) padding. > To avoid that, and particularly to decrypt values from your old code which used > some garbage data (see above) rather than valid padding, > EVP_CIPHER_CTX_set_padding (ctx, 0); This was the key piece of info for me. I tried without EVP_BytesToKey and NULL IV at first, seemed straight forward, but wasn't getting the expected output so added it. Once I removed EVP_BytesToKey and added EVP_CIPHER_CTX_set_padding to 0 it works. Note: p_text is 16 bytes in my production code (its read from external source); hard coded it here; sorry for missed detail; didn't mean to waste ur time. ________________________________ From: Dave Thompson To: 'Purushotham Nayak' ; openssl-users at openssl.org Sent: Wednesday, December 31, 2014 2:45 PM Subject: RE: [openssl-users] OpenSSL AES encryption using AES_* functions and EVP_* functions > From: openssl-users On Behalf Of Purushotham Nayak > Sent: Wednesday, December 31, 2014 12:22 > I have some data that was encrypted using the openssl (`AES_*`) functions. > I want update this code to use the newer (EVP_*) functions which are > FIPS compliant. But I should be able to decrypt data that was encrypted > using the old code. > I've pasted below both the old and the new code. The encrypted/decrypted > contents are different. i.e. I can't use them interchangeably. This means > I can't upgrade the code without having to decrypt using the old code > and then re-encrypt. > Are there any values for the parameters to EVP_BytesToKey so that > aes_key derived is the same in both cases. Or is there any other way > to accomplish the same using the (EVP_*) functions? I've tried What on earth makes you think EVP_BytesToKey is appropriate? EVP_BytesToKey is used for *password-based* encryption, where the key (and sometimes IV) is derived in a complicated way from a character string intended to be remembered by humans. (Even for that it is outdated and PKCS5_PBKDF2* is better.) If you have an actual key, as you did in your old code, you simply pass that same actual key to EVP_EncryptInit as the actual key. > What algorithm is being used in AES_set_encrypt/decrypt_key function? The key scheduling defined in FIPS 197 (and before that Rijndael). And so is EVP_EncryptInit* when used on an AES cipher. > The code using the `AES_*` functions > int main() > { > unsigned char p_text[]="plain text"; > unsigned char c_text[16]; > AES_encrypt(p_text, c_text, &aes_key); This old code allocates a buffer of 11 bytes to contain the plaintext and passes it to AES_encrypt which reads 16 bytes (always). The remaining 5 bytes are undefined by the C standard -- in fact the *behavior* is undefined by standard, although in practice nearly all implementations will read *some* values. *What* values they read may depend on your compiler, version, options, computer, operating system, and the phase of the moon, which means you probably can't duplicate it in the new code. You can still decrypt old values with the fixes described below, but you can't faithfully recreate them. > The code using the `EVP_*` functions. (Encryption code is below and the decryption code is similar). > int main() > { > EVP_CIPHER_CTX *ctx = (EVP_CIPHER_CTX*)malloc(sizeof(EVP_CIPHER_CTX)); > EVP_CIPHER_CTX_init(ctx); EVP_CIPHER_CTX_new() is simpler. > const EVP_CIPHER *cipher = EVP_aes_128_ecb(); // key size 128, mode ecb (not FIPS compliant?) FIPS140 covers only the algorithm not the mode, so all modes are equally "compliant". However ECB is frequently insecure and a Very Bad Idea if used for anything other than random data. See Wikipedia, or practically any good crypto reference. > EVP_EncryptInit(ctx, cipher, aes_key, aes_iv); Pass the actual key, of the correct size. ECB does not use an IV, so you can pass NULL or any value of the correct size which will be ignored. Not using an IV is one of the (several) things that makes ECB frequently insecure, see above. EVP will by default add and remove PKCS5 (or more exactly PKCS7) padding. To avoid that, and particularly to decrypt values from your old code which used some garbage data (see above) rather than valid padding, EVP_CIPHER_CTX_set_padding (ctx, 0); > unsigned char p_text[]="plain text"; int p_len = sizeof(p_text); > unsigned char c_text[16]; int c_len = 16; > int t_len; > EVP_EncryptUpdate(ctx, c_text, &c_len, p_text, p_len); > EVP_EncryptFinal(ctx, (c_text + c_len), &t_len); > c_len += t_len; Happy New Year. From Peter.Klee at fiserv.com Fri Jan 2 17:36:38 2015 From: Peter.Klee at fiserv.com (Klee, Peter (King of Prussia)) Date: Fri, 2 Jan 2015 17:36:38 +0000 Subject: [openssl-users] READ error during tape restore via OpenSSL on AIX Message-ID: <99A57158E0F9D04CBB4649464ACD323A2876B113@JWPKEXMBX03.corp.checkfree.com> Hello OpenSSL community, We are running OpenSSL on IBM AIX version 7.1 on an IBM Power8 server. The OpenSSL versions installed are as follows: openssh.base.client 6.0.0.6103 COMMIT COMPLETE 06/25/14 17:46:58 openssh.base.server 6.0.0.6103 COMMIT COMPLETE 06/25/14 17:46:58 openssl.base 1.0.1.510 COMMIT COMPLETE 09/23/14 15:49:29 When backing up files to tape with no encryption using the AIX backup command, we are able to restore the files from tape using the AIX restore command, with no issue. When backing up files to tape with symmetric OpenSSL encryption (for instance blowfish, aes-128-cbc, aes-256-cbc, with either a password or a key file) the files back up to tape without error. But when restored from tape, we consistently receive the following error messages during the restore: 804401144:error:0200B005:system library:fread:I/O error:bss_file.c:245: 804401144:error:20082002:BIO routines:FILE_READ:system lib:bss_file.c:246: One of the files backed up and restored is a database file (Intersystems Cache) and the restored database passes an integrity check after each restore. The restored text files in the target directory come up with no differences when using diff to compare them to the original files in the source directory. So, we aren't seeing any issues with the integrity of the restored files. But why are the two error messages showing up consistently? Here's our backup command, this time using the aes-256-cbc encryption algorithm and the password shown: find . -print | backup -ivUf - | openssl enc -aes-256-cbc -k abc123 -out /dev/rmt0.1 And here's the restore command and the result: openssl enc -d -aes-256-cbc -k abc123 -in /dev/rmt0.1 | restore -xvqf - IBM8_SYS2(/store/abcalt)$ bc -k abc123 -in /dev/rmt0.1 | restore -xvqf - < x 0 . x 974127104 ./CACHE.DAT 804401144:error:0200B005:system library:fread:I/O error:bss_file.c:245: 804401144:error:20082002:BIO routines:FILE_READ:system lib:bss_file.c:246: x 40904 ./RMS x 0 ./stream IBM8_SYS2(/store/abcalt)$ Those two exact 804401144 error messages show up consistently during every tape restore. We have tried specifying the block size on the backup and restore but it makes no difference. It should be noted that when we use the backup and restore commands with OpenSSL encryption and no tape drive, but backing up to a different directory and restoring from there, there are no errors during the restore. The errors only happen when restoring from tape. Any thoughts you have on this are appreciated. Peter M Klee System Analyst Fiserv DataSafe Fiserv Credit Union Solutions 800-523-7282 x 2376 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jan 2 17:44:43 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Jan 2015 12:44:43 -0500 Subject: [openssl-users] READ error during tape restore via OpenSSL on AIX In-Reply-To: <99A57158E0F9D04CBB4649464ACD323A2876B113@JWPKEXMBX03.corp.checkfree.com> References: <99A57158E0F9D04CBB4649464ACD323A2876B113@JWPKEXMBX03.corp.checkfree.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D552373E3@USMBX1.msg.corp.akamai.com> They are I/O errors (openssl errstr is your friend here) and probably related to the tape I/O device not being ready, timing out, or something like that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Jan 2 20:53:31 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 2 Jan 2015 20:53:31 +0000 Subject: [openssl-users] READ error during tape restore via OpenSSL on AIX In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D552373E3@USMBX1.msg.corp.akamai.com> References: <99A57158E0F9D04CBB4649464ACD323A2876B113@JWPKEXMBX03.corp.checkfree.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D552373E3@USMBX1.msg.corp.akamai.com> Message-ID: <20150102205331.GK24649@mournblade.imrryr.org> On Fri, Jan 02, 2015 at 12:44:43PM -0500, Salz, Rich wrote: > They are I/O errors (openssl errstr is your friend here) and probably related to the tape I/O device not being ready, timing out, or something like that. Tape devices generally require I/O operations to be in multiples of a tape block. The output of "openssl enc" is not going to satisfy that property. A final filter is required that "pads" the encrypted output to a multiple of the tape block size, and strips the padding on input. -- Viktor. From Michael.Wojcik at microfocus.com Fri Jan 2 22:00:50 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 2 Jan 2015 22:00:50 +0000 Subject: [openssl-users] READ error during tape restore via OpenSSL on AIX In-Reply-To: <20150102205331.GK24649@mournblade.imrryr.org> References: <99A57158E0F9D04CBB4649464ACD323A2876B113@JWPKEXMBX03.corp.checkfree.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D552373E3@USMBX1.msg.corp.akamai.com> <20150102205331.GK24649@mournblade.imrryr.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Friday, January 02, 2015 15:54 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] READ error during tape restore via OpenSSL on > AIX > > On Fri, Jan 02, 2015 at 12:44:43PM -0500, Salz, Rich wrote: > > > They are I/O errors (openssl errstr is your friend here) and probably related > > to the tape I/O device not being ready, timing out, or something like that. > > Tape devices generally require I/O operations to be in multiples of a tape > block. The output of "openssl enc" is not going to satisfy that property. A > final filter is required that "pads" the encrypted output to a multiple of the > tape block size, and strips the padding on input. One traditional way to do this "reblocking" is with the dd command, using "conv=sync". Since this is AIX, the OP might also look at the tctl command, which also has a mode ("tctl write') that reads from standard input and writes complete blocks to a tape device. I'm sure there are plenty of examples online. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From richmoore44 at gmail.com Sat Jan 3 17:16:45 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Sat, 3 Jan 2015 17:16:45 +0000 Subject: [openssl-users] Problems verifying OCSP signatures In-Reply-To: References: Message-ID: I've now got this working, though to do so I seem to have to take the certificates supplied in the OCSP response directly out of the certs field of the OCSP_BASICRESP and add these as intermediates for the verification too. It feels bad to directly access the internals of this struct but there doesn't seem to be another way (unless someone can enlighten me). Cheers Rich. On 28 December 2014 at 16:42, Richard Moore wrote: > Hi All, > > I'm trying to get some code to verify the signature of an OCSP response to > work properly and I'm hitting quite a few road blocks. I've also been > talking > to the curl developers who are having the same problems and I wondered if > anyone can help us. > > I've tried 3 different ways of handling the verification and none of them > seem > to work reliably. All 3 work properly for checking the OCSP status of > www.google.com, but they all fail when testing revoked.grc.com and > tn123.org. > I'm sure I must be doing something wrong, but I've no idea what and there > seems to be very little documentation in this area. I've put the 3 > approaches > I've tried below in case anyone has any ideas. Note that the reason all the > openssl symbols has a q_XXX prefix is just due to a dlopen shim and doesn't > change the behaviour of the functions at all. > > If anyone has any suggestions of what I'm doing wrong then please let me > know. > > Thanks > > Rich. > > /** > * This version takes the whole issuer chain, and adds them as > intermediates. > * It also sets up the CA store. > */ > bool QSslOcspReply::hasValidSignature1(const QList > &issuers) const > { > // Create the certificate store > X509_STORE *certStore = q_X509_STORE_new(); > if (!certStore) { > qWarning() << "Unable to create certificate store"; > return false; > } > > // Build a stack to put the issuer in > STACK_OF(X509) *intermediates = 0; > intermediates = (STACK_OF(X509) *) q_sk_new_null(); > > if (!intermediates) { > q_X509_STORE_free(certStore); > return false; > } > > #if OPENSSL_VERSION_NUMBER >= 0x10000000L > foreach (const QSslCertificate &cert, issuers) > q_sk_push( (_STACK *)intermediates, reinterpret_cast *>(cert.handle())); > #else > foreach (const QSslCertificate &cert, issuers) > q_sk_push( (STACK *)intermediates, reinterpret_cast *>(cert.handle())); > #endif > > foreach (const QSslCertificate &caCertificate, > QSslSocket::defaultCaCertificates()) > q_X509_STORE_add_cert(certStore, (X509 *)caCertificate.handle()); > > int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates, > certStore, OCSP_TRUSTOTHER); > > // A verify result is a failure if it is 0 or less > if (verifyResult <= 0) { > unsigned long errnum = q_ERR_get_error(); > const char *error = q_ERR_error_string(errnum, 0); > > qDebug() << "OCSP response verification failed" << verifyResult; > qDebug() << "Error was: " << error; > // ### TODO: Fix mem leak > return false; > } > qDebug() << "OCSP response verification good"; > > #if OPENSSL_VERSION_NUMBER >= 0x10000000L > q_sk_free( (_STACK *) intermediates); > #else > q_sk_free( (STACK *) intermediates); > #endif > q_X509_STORE_free(certStore); > > return true; > } > > /** > * This version takes the whole issuer chain, and adds them as > intermediates. > * It does not set up any CAs. > */ > bool QSslOcspReply::hasValidSignature2(const QList > &issuers) const > { > // Create the certificate store > X509_STORE *certStore = q_X509_STORE_new(); > if (!certStore) { > qWarning() << "Unable to create certificate store"; > return false; > } > > // Build a stack to put the issuer in > STACK_OF(X509) *intermediates = 0; > intermediates = (STACK_OF(X509) *) q_sk_new_null(); > > if (!intermediates) { > q_X509_STORE_free(certStore); > return false; > } > > #if OPENSSL_VERSION_NUMBER >= 0x10000000L > foreach (const QSslCertificate &cert, issuers) > q_sk_push( (_STACK *)intermediates, reinterpret_cast *>(cert.handle())); > #else > foreach (const QSslCertificate &cert, issuers) > q_sk_push( (STACK *)intermediates, reinterpret_cast *>(cert.handle())); > #endif > > int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates, > certStore, OCSP_TRUSTOTHER); > > // A verify result is a failure if it is 0 or less > if (verifyResult <= 0) { > unsigned long errnum = q_ERR_get_error(); > const char *error = q_ERR_error_string(errnum, 0); > > qDebug() << "OCSP response verification failed" << verifyResult; > qDebug() << "Error was: " << error; > // ### TODO: Fix mem leak > return false; > } > qDebug() << "OCSP response verification good"; > > #if OPENSSL_VERSION_NUMBER >= 0x10000000L > q_sk_free( (_STACK *) intermediates); > #else > q_sk_free( (STACK *) intermediates); > #endif > q_X509_STORE_free(certStore); > > return true; > } > > /** > * This version takes the just the actual issuer, and adds it as an > intermediate. > * It does not set up any CAs. > */ > bool QSslOcspReply::hasValidSignature3(const QSslCertificate &issuer) const > { > // Create the certificate store > X509_STORE *certStore = q_X509_STORE_new(); > if (!certStore) { > qWarning() << "Unable to create certificate store"; > return false; > } > > // Build a stack to put the issuer in > STACK_OF(X509) *intermediates = 0; > intermediates = (STACK_OF(X509) *) q_sk_new_null(); > > if (!intermediates) { > q_X509_STORE_free(certStore); > return false; > } > > #if OPENSSL_VERSION_NUMBER >= 0x10000000L > q_sk_push( (_STACK *)intermediates, reinterpret_cast *>(issuer.handle())); > #else > q_sk_push( (STACK *)intermediates, reinterpret_cast *>(issuer.handle())); > #endif > > int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates, > certStore, OCSP_TRUSTOTHER); > > // A verify result is a failure if it is 0 or less > if (verifyResult <= 0) { > unsigned long errnum = q_ERR_get_error(); > const char *error = q_ERR_error_string(errnum, 0); > > qDebug() << "OCSP response verification failed" << verifyResult; > qDebug() << "Error was: " << error; > // ### TODO: Fix mem leak > return false; > } > qDebug() << "OCSP response verification good"; > > #if OPENSSL_VERSION_NUMBER >= 0x10000000L > q_sk_free( (_STACK *) intermediates); > #else > q_sk_free( (STACK *) intermediates); > #endif > q_X509_STORE_free(certStore); > > return true; > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Sat Jan 3 21:45:20 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sat, 03 Jan 2015 22:45:20 +0100 Subject: [openssl-users] Problems verifying OCSP signatures In-Reply-To: References: Message-ID: <54A862F0.7060305@mathemainzel.info> On 03.01.2015 18:16, Richard Moore wrote: > I've now got this working, though to do so I seem to have to take the > certificates supplied in the OCSP response directly out of the certs > field of the OCSP_BASICRESP and add these as intermediates for the > verification too. It feels bad to directly access the internals of > this struct but there doesn't seem to be another way (unless someone > can enlighten me). > > Cheers > > Rich. the certificate you want to test its validity with OCSP has the same intermediate CA cert. as the OCSP responder certificate you use in OCSP response Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5971 bytes Desc: S/MIME Cryptographic Signature URL: From richmoore44 at gmail.com Sat Jan 3 21:59:54 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Sat, 3 Jan 2015 21:59:54 +0000 Subject: [openssl-users] Problems verifying OCSP signatures In-Reply-To: <54A862F0.7060305@mathemainzel.info> References: <54A862F0.7060305@mathemainzel.info> Message-ID: On 3 January 2015 at 21:45, Walter H. wrote: > On 03.01.2015 18:16, Richard Moore wrote: > > I've now got this working, though to do so I seem to have to take the > certificates supplied in the OCSP response directly out of the certs field > of the OCSP_BASICRESP and add these as intermediates for the verification > too. It feels bad to directly access the internals of this struct but there > doesn't seem to be another way (unless someone can enlighten me). > > Cheers > > Rich. > > the certificate you want to test its validity with OCSP has the same > intermediate CA cert. as the OCSP responder certificate you use in OCSP > response > Simply specifying the intermediates from the certificate chain of the server doesn't appear to actually work - that's what I tried first. Sadly I've not seen any documentation or examples of how to use this part of openssl. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Sun Jan 4 19:33:29 2015 From: marquess at openssl.com (Steve Marquess) Date: Sun, 04 Jan 2015 14:33:29 -0500 Subject: [openssl-users] OpenSSL FIPS module breaks the century mark Message-ID: <54A99589.4050206@openssl.com> Revision 2.0.9 of the OpenSSL FIPS Object Module v2.0 (FIPS 140-2 validation certificate #1747) recently received formal approval: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 This latest revision adds five new formally tested platforms ("Operational Environments") bringing the total number of such platforms to 102; more by far than for any other validated cryptographic module. We have some more platforms on the way... As always, there is no need to upgrade any already deployed instances of the OpenSSL FIPS Module. But, if you're doing new development it's preferable to use the latest revision as that will be valid for all tested platforms. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From vvprasad.chalumuri at gmail.com Mon Jan 5 11:55:42 2015 From: vvprasad.chalumuri at gmail.com (VVPrasad Chalumuri) Date: Mon, 5 Jan 2015 17:25:42 +0530 Subject: [openssl-users] X509_CINF_dup fails with "invalid object encoding" error Message-ID: Hi, I was trying to duplicate the X509_CINF structure variable using ASN1_item_dup with OpenSSL 1.0.1i code. But, it fails with the following error. The same code works fine, if I run it against OpenSSL 0.9.8zb. *error code; 218906840 in a_object.c line 303.Error message: error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encodingerror code; 218640442 in tasn_dec.c line 751.error data: Field=algorithm, Type=X509_ALGORError message: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 errorerror code; 218640442 in tasn_dec.c line 751.error data: Field=signature, Type=X509_CINFError message: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error* Can some one please point out, if I'm missing something? I really appreciate any help extended. Copying the code snippet below with this mail. --VVPrasad ============================================================ *IMPLEMENT_ASN1_DUP_FUNCTION(X509_CINF)* *int test_X509_CINF_dup() * *{* * char *serial = "1230ABCD";* * ASN1_INTEGER *asn1int = NULL;* * X509_NAME *name = NULL;* * X509_CINF *x509cinf;* * X509 *x509 = NULL;* * X509_CINF *cinf = NULL;* * int days = 365;* * struct timeval now;* * ASN1_TIME *nb;* * ASN1_TIME *na;* * struct timeval nbs;* * time_t tsec;* * time_t secs;* * long millis;* * int flags, line;* * const char *data, *file;* * unsigned long code;* * char *errstr;* * x509cinf = X509_CINF_new();* * /* allocate memory for X509_CINF */* * if (!(x509cinf->version = ASN1_INTEGER_new())) {* * fprintf(stderr, "ERROR(%d): Allocating memory for X509_CINF\n",__LINE__);* * goto err;* * }* * /* set the version */* * if (!ASN1_INTEGER_set(x509cinf->version, CERT_V3)) {* * fprintf(stderr, "ERROR(%d): Setting version for X509_CINF\n",__LINE__);* * goto err;* * }* * /* set the serial number */* * {* * /* convert the serial number into an ASN1_INTEGER */* * if (char_array_2_asn1_integer(&asn1int, serial) < 0) {* * fprintf(stderr, "ERROR(%d): char_array_2_asn1_integer\n",__LINE__);* * goto err;* * }* * if (x509cinf->serialNumber)* * M_ASN1_INTEGER_free(x509cinf->serialNumber);* * x509cinf->serialNumber = asn1int;* * }* * /* set subject name */* * {* * if (create_subject_name(&name) < 0) {* * fprintf(stderr, "ERROR(%d): Invalid subject name\n",__LINE__);* * goto err;* * }* * /* set it, but free first if one already exists */* * if (x509cinf->subject)* * X509_NAME_free(x509cinf->subject);* * x509cinf->subject = name; * * }* * /* set validity */* * {* * timeval_clock(&now, NULL);* * nb = x509cinf->validity->notBefore;* * if (! ASN1_TIME_set(nb, now.tv_sec)) {* * fprintf(stderr, "ERROR(%d): Setting notBefore\n",__LINE__);* * goto err;* * }* * na = x509cinf->validity->notAfter;* * if (! ASN1_TIME_set(na, now.tv_sec)) {* * fprintf(stderr, "ERROR(%d): Setting notAfter\n",__LINE__);* * goto err;* * }* * if (nb->type != V_ASN1_UTCTIME && nb->type != V_ASN1_GENERALIZEDTIME) {* * if (! X509_gmtime_adj(nb,0)) {* * fprintf(stderr, "ERROR(%d): Setting notBefore to today\n",__LINE__);* * goto err;* * }* * }* * /* convert time to timeval */* * parsetimebuf((const char *)nb->data, nb->length, (nb->type == V_ASN1_UTCTIME)? 1 : 0, &secs, &millis);* * nbs.tv_sec = (long)secs;* * nbs.tv_usec = millis * TME_MICROS_PER_MILLI;* * /* set notAfter to days after notBefore */* * tsec = (time_t)nbs.tv_sec;* * if (! X509_time_adj(na, (long)60*60*24*days, &tsec)) {* * fprintf(stderr, "ERROR(%d): Calculating notAfter\n",__LINE__);* * goto err;* * }* * }* * /* duplicate the cert info */* * if (! (cinf = X509_CINF_dup(x509cinf))) {* * fprintf(stderr, "ERROR: Allocating memory for the certificate information object\n");* * code = ERR_get_error_line_data(&file, &line, &data, &flags);* * while (code)* * {* * printf("error code; %lu in %s line %d.\n", code, file, line);* * if (data && (flags & ERR_TXT_STRING))* * printf("error data: %s\n", data);* * errstr = ERR_error_string(code, NULL);* * printf("Error message: %s\n", errstr);* * code = ERR_get_error_line_data(&file, &line, &data, &flags);* * }* * goto err;* * }* * /** * * ...............................* * */* * return 0;* *err:* * X509_CINF_free(x509cinf);* * X509_CINF_free(cinf);* * X509_free(x509);* * return -1;* *}* *int char_array_2_asn1_integer(ASN1_INTEGER **num, const char* const serial) * *{* * BIGNUM *bn = NULL;* * ASN1_INTEGER *asn1int = NULL;* * /* create an asn1 integer, if not already exists */* * if (*num) {* * asn1int = *num;* * } else if (!(asn1int = ASN1_INTEGER_new())) {* * goto err;* * }* * if (BN_hex2bn(&bn, serial) <= 0)* * goto err;* * if (! BN_to_ASN1_INTEGER(bn, asn1int))* * goto err;* * BN_free(bn);* * *num = asn1int;* * return 0;* *err:* * BN_free(bn);* * ASN1_INTEGER_free(asn1int);* * return -1;* *}* *int create_subject_name(X509_NAME** x509_name)* *{* * X509_NAME *newname=NULL;* * X509_NAME_ENTRY *ne=NULL;* * ASN1_OBJECT *obj=NULL;* * int setnumber = -1;* * int loc=0;* * int i = 0;* * int num;* * int str_type;* * char* types[] = {"CN", "emailAddress", "OU", "O", "C", 0};* * unsigned char* values[] = {* * (unsigned char*)"test", * * (unsigned char*)"hello at com.au", * * (unsigned char*)"test_ou", * * (unsigned char*)"test_o", * * (unsigned char*)"US", * * 0 };* * /* create a new name */* * if (! (newname = X509_NAME_new())) {* * fprintf(stderr, "ERROR(%d): allocating new X509 name\n",__LINE__);* * goto err;* * }* * while (types[i] && values[i])* * {* * /* convert type string to object identifier (ASN1_OBJECT) */* * if (! (obj = OBJ_txt2obj(types[i], 0))) {* * fprintf(stderr, "ERROR(%d): unknown ldapv3 DN type [%s]\n",__LINE__, types[i]);* * goto err;* * }* * /* create a new entry */* * if (! (ne = X509_NAME_ENTRY_new())) {* * fprintf(stderr, "ERROR(%d): allocating new X509 name component\n",__LINE__);* * goto err;* * }* * /* set the rdn type */* * if (! X509_NAME_ENTRY_set_object(ne, obj)) {* * fprintf(stderr, "ERROR(%d): setting ldapv3 DN type\n",__LINE__);* * goto err;* * }* * /* determine the string type */* * str_type = (OBJ_obj2nid(obj) == NID_pkcs9_emailAddress) ? V_ASN1_IA5STRING : V_ASN1_PRINTABLESTRING;* * if (! X509_NAME_ENTRY_set_data(ne, str_type, values[i], strlen((const char*)values[i]))) {* * fprintf(stderr, "ERROR(%d): setting ldapv3 DN data\n",__LINE__);* * goto err;* * }* * if (strcmp(types[i], "emailAddress")) { * * loc++;* * } else { * * loc = 0;* * setnumber++;* * }* * ne->set = setnumber;* * /* add the name entry to the name we are building */* * if (! sk_X509_NAME_ENTRY_insert(newname->entries, ne, loc)) {* * fprintf(stderr, "ERROR(%d): adding ldapv3 DN component\n",__LINE__);* * goto err;* * }* * i++;* * }* * /* reverse the set numbers */* * for (i = 0, num = sk_X509_NAME_ENTRY_num(newname->entries) ; i < num ; ++i) {* * sk_X509_NAME_ENTRY_value(newname->entries, i)->set = setnumber -* * sk_X509_NAME_ENTRY_value(newname->entries, i)->set;* * }* * /* success */* * *x509_name = newname;* * return 0;* *err:* * if (newname) X509_NAME_free(newname);* * *x509_name = NULL;* * return -1;* *}* ============================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jan 5 12:10:30 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 05 Jan 2015 12:10:30 +0000 Subject: [openssl-users] OpenSSL source reformat Message-ID: <54AA7F36.5080105@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have previously announced our intention to reformat the entire codebase into a more consistent style (see our roadmap document here: https://www.openssl.org/about/roadmap.html) Since then we have been busy working towards doing that. I'd like to make available for comment a sample reformat. So far I've run it for master and 1.0.2, but the current thinking is that this will also be applied to 1.0.1, 1.0.0 and 0.9.8 (this is necessary to significantly ease the maintenance overhead) I've put the results of the reformat up on my github account here: https://github.com/mattcaswell/openssl The reformat of master is on the "sample-master-reformat" branch, and the 1.0.2 reformat is on "sample-1.0.2-reformat". The style itself is heavily influenced by the Linux Kernel Coding style: https://www.kernel.org/doc/Documentation/CodingStyle Although there are some significant differences - most notably that we are using spaces not tabs for indents, and the indent depth is 4 characters not 8. We will be publishing our own style guide in due course. I'm not looking to open any religious wars here - so I'm not looking for comments on the style itself (e.g. debates about whether 2, 4 or 8 character indents are better (we've already had those!)) - but I'm mainly seeking feedback on anywhere where the reformatting has failed. We've already looked of course...but sometimes many sets of eyes are better! I've also made available the script that was used to do the reformatting. The script is called openssl-format-source and is in the util directory of the branches mentioned above. This script depends on GNU indent being available. It should be executed from the root of the source tree as follows: util/openssl-format-source -v -c . There are also some one-off manual tweaks (both before and after running the script) that need to be done which are present in the sample reformat branches. These are related to multi-line comments which have their own internal formatting - these aren't handled too well. The manual steps should be a one-off exercise though. The hope is that we will be able to re-run the script at regular intervals. Thanks Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqn82AAoJENnE0m0OYESR/r0IALuQC+UQKEr6mSTHu3aex+TQ OSirP2FzQAwxLwRujnLSC9xVsRiDEg8CjGDJFpMBWUz3+tL1+9A5tUzt9gb6rqE3 sVVZCYuB81Q0Ge5bA9pTluOg+BX6E7UfcEmoeJMol0GPYjXeAWqmp67XrpSj5ZA7 iH0JUURP5/aj3NWXZpUZG/KVVsGAJl8UQtCF2xycYVE/1A7rb+C7voedXA7QvAnZ rIn9h4B8wzU9dfHOdZj9PjPfXTn+XEUI+9aY4kDsnuuH3yw0Jb0hGb2fF1bOIb/M RtS658hNCCr8wWdgiGoUNkbv8s21hrWBQ8oobM4izbn8+wr6OYBFKfoYCfBP9IY= =O1i4 -----END PGP SIGNATURE----- From elaine.anacortes at gmail.com Mon Jan 5 13:09:35 2015 From: elaine.anacortes at gmail.com (elaine ossipov) Date: Mon, 5 Jan 2015 05:09:35 -0800 Subject: [openssl-users] [openssl-announce] Another record-breaking donation from Smartisan Technology In-Reply-To: <54A44B23.3040607@openssl.com> References: <54A2B931.601@opensslfoundation.com> <54A44B23.3040607@openssl.com> Message-ID: Congrat's, that is so good to hear, and looking forward to some awesome breakthroughs! :) ~e -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Steve Marquess" Subject: [openssl-announce] Another record-breaking donation from Smartisan Technology Date: Wed, 31 Dec 2014 11:14:43 -0800 Size: 4943 URL: From openssl at openssl.org Mon Jan 5 14:13:38 2015 From: openssl at openssl.org (OpenSSL) Date: Mon, 5 Jan 2015 15:13:38 +0100 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: <20150105141338.GA19261@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.1k, 1.0.0p and 0.9.8zd. These releases will be made available on 8th January. They will fix a number of security defects. Since these security defects are considered as moderate severity or less no further details or patches will be made available in advance of the release. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqpq7AAoJENnE0m0OYESRCeQH/3i7C8kpk+n6cqwaEedjt5Mo eU0F+d8OrxPMqzEo4qftGe+7ygvwJBdA8tb0/4fQuqmg9wBSbJMa7qku20qOpKF9 daYfOPQCXgdGUjomp5GYz86/7Aq7aND8qQLnCcWWdwBv+8ypP0Hgywilr1LW+nnv xBNNbQSBERPayGcSIqFI0xYd2r8Q8vUp9BMKnkHoR5ty3nO43/nGQnPwEX5O3tJc XZzWVVxrKhp/wMiAueWz44vc0juO8LdfkuWUtjJj3F9cL9qLOG877ho4cM/t9WX/ jheVNun1Cd9Z0wIn0nHYgtJUn/eVyTc9LckoVKt9pg4+HhsJd4cTC8X92HQbB6E= =fM80 -----END PGP SIGNATURE----- From openssl at comaxis.com Mon Jan 5 20:01:37 2015 From: openssl at comaxis.com (openssl at comaxis.com) Date: Mon, 5 Jan 2015 15:01:37 -0500 Subject: [openssl-users] OpenSSL and iCloud Message-ID: Are there any known problems using OpenSSL with iCloud? I am trying to connect to imap.mail.me.com using port 993. My call to SSL_Connect() returns 0, with SSL_get_error() returing 1 (SSL_ERROR_SSL). I am using OpenSSL version 1.0.1h, running on Win32. I can use this code with any other IMAP server with no problems. From wiml at omnigroup.com Mon Jan 5 20:49:04 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Mon, 5 Jan 2015 12:49:04 -0800 Subject: [openssl-users] OpenSSL and iCloud In-Reply-To: References: Message-ID: <31DF10CD-9538-4BDA-85A0-7D28F195A291@omnigroup.com> On Jan 5, 2015, at 12:01 PM, openssl at comaxis.com wrote: > Are there any known problems using OpenSSL with iCloud? I am trying to > connect to imap.mail.me.com using port 993. My call to SSL_Connect() > returns 0, with SSL_get_error() returing 1 (SSL_ERROR_SSL). I am using > OpenSSL version 1.0.1h, running on Win32. I can use this code with any > other IMAP server with no problems. Are you able to connect using the openssl s_client application? I can connect (to port 993, no starttls) with either 1.0.1j or 0.9.8za; perhaps s_client will give you a more diagnostic error message if it also fails for you. From openssl at comaxis.com Mon Jan 5 22:24:34 2015 From: openssl at comaxis.com (openssl at comaxis.com) Date: Mon, 5 Jan 2015 17:24:34 -0500 Subject: [openssl-users] OpenSSL and iCloud In-Reply-To: <31DF10CD-9538-4BDA-85A0-7D28F195A291@omnigroup.com> References: <31DF10CD-9538-4BDA-85A0-7D28F195A291@omnigroup.com> Message-ID: <0e8ee25ec1b076ec08b11f66afc0ccef.squirrel@sm.webmail.pair.com> > > On Jan 5, 2015, at 12:01 PM, openssl at comaxis.com wrote: >> Are there any known problems using OpenSSL with iCloud? I am trying to >> connect to imap.mail.me.com using port 993. My call to SSL_Connect() >> returns 0, with SSL_get_error() returing 1 (SSL_ERROR_SSL). I am using >> OpenSSL version 1.0.1h, running on Win32. I can use this code with any >> other IMAP server with no problems. > > > Are you able to connect using the openssl s_client application? I can > connect (to port 993, no starttls) with either 1.0.1j or 0.9.8za; perhaps > s_client will give you a more diagnostic error message if it also fails > for you. > > I made a build of 1.0.1j but it made no difference to my application. In fact, I *can* use "openssl s_client -connect" with iCloud. Doing the same thing with my own server (which my application works with) the only thing I see different in the diagnostics provided by openssl is the cipher: for imap.mail.me.com I get "AES256-GCM-SHA384" but with my own, I get "ECDHE-RSA-AES256-GCM-SHA384". Do I need to do something in the build open OpenSSL to get support for AES256, or something different in my code that uses SSL? I would assume the latter, since the openssl utility is using my brand new builds of the ssl dlls. Here is what I am doing (with error checking removed): SSL_library_init(); SSL_load_error_strings(); wsprintf (seed,"%lx%lx", GetCurrentProcessId(), time(0)); RAND_seed (seed, strlen(seed)); meth=SSLv3_method(); ctx = SSL_CTX_new(meth); SSL_CTX_set_options(ctx,0); SSL_CTX_set_verify(ctx,SSL_VERIFY_NONE,NULL); SSL_CTX_set_default_verify_paths(ctx); ssl = SSL_new(ctx); sbio = BIO_new_socket(gSocket, BIO_NOCLOSE); SSL_set_bio(ssl, sbio, sbio); ret = SSL_connect(ssl); From openssl at comaxis.com Mon Jan 5 22:31:29 2015 From: openssl at comaxis.com (openssl at comaxis.com) Date: Mon, 5 Jan 2015 17:31:29 -0500 Subject: [openssl-users] OpenSSL and iCloud In-Reply-To: <0e8ee25ec1b076ec08b11f66afc0ccef.squirrel@sm.webmail.pair.com> References: <31DF10CD-9538-4BDA-85A0-7D28F195A291@omnigroup.com> <0e8ee25ec1b076ec08b11f66afc0ccef.squirrel@sm.webmail.pair.com> Message-ID: Never mind - I got it to work by using: meth = SSLv23_method(); > >> >> On Jan 5, 2015, at 12:01 PM, openssl at comaxis.com wrote: >>> Are there any known problems using OpenSSL with iCloud? I am trying to >>> connect to imap.mail.me.com using port 993. My call to SSL_Connect() >>> returns 0, with SSL_get_error() returing 1 (SSL_ERROR_SSL). I am using >>> OpenSSL version 1.0.1h, running on Win32. I can use this code with any >>> other IMAP server with no problems. >> >> >> Are you able to connect using the openssl s_client application? I can >> connect (to port 993, no starttls) with either 1.0.1j or 0.9.8za; >> perhaps >> s_client will give you a more diagnostic error message if it also fails >> for you. >> >> > I made a build of 1.0.1j but it made no difference to my application. In > fact, I *can* use "openssl s_client -connect" with iCloud. Doing the same > thing with my own server (which my application works with) the only thing > I see different in the diagnostics provided by openssl is the cipher: > for imap.mail.me.com I get "AES256-GCM-SHA384" but with my own, I > get "ECDHE-RSA-AES256-GCM-SHA384". Do I need to do something in the build > open OpenSSL to get support for AES256, or something different in my code > that uses SSL? I would assume the latter, since the openssl utility is > using my brand new builds of the ssl dlls. Here is what I am doing (with > error checking removed): > > SSL_library_init(); > SSL_load_error_strings(); > wsprintf (seed,"%lx%lx", GetCurrentProcessId(), time(0)); > RAND_seed (seed, strlen(seed)); > meth=SSLv3_method(); > ctx = SSL_CTX_new(meth); > > SSL_CTX_set_options(ctx,0); > SSL_CTX_set_verify(ctx,SSL_VERIFY_NONE,NULL); > SSL_CTX_set_default_verify_paths(ctx); > ssl = SSL_new(ctx); > sbio = BIO_new_socket(gSocket, BIO_NOCLOSE); > SSL_set_bio(ssl, sbio, sbio); > ret = SSL_connect(ssl); > > > From erik at efca.com Mon Jan 5 22:49:06 2015 From: erik at efca.com (Erik Forsberg) Date: Mon, 5 Jan 2015 14:49:06 -0800 Subject: [openssl-users] Web site problem Message-ID: <-bqoakhrPP4PXO0@srv.efca.com> Starting a few days ago, www.openssl.org when clicking on the Source tab, then selecting the GitWeb tab, redirects you to git.openssl.org (probably ok ? ) but that page returns the OpenSSL home page (same as www.openssl.org) so no web git access. DNS issues perhaps ? From noloader at gmail.com Tue Jan 6 00:17:19 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 5 Jan 2015 19:17:19 -0500 Subject: [openssl-users] OpenSSL and iCloud In-Reply-To: References: <31DF10CD-9538-4BDA-85A0-7D28F195A291@omnigroup.com> <0e8ee25ec1b076ec08b11f66afc0ccef.squirrel@sm.webmail.pair.com> Message-ID: On Mon, Jan 5, 2015 at 5:31 PM, wrote: > Never mind - I got it to work by using: meth = SSLv23_method(); You might consider removing the weak/wounded stuff: meth = SSLv23_method(); ... long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION; SSL_CTX_set_options(ctx,flags); >>> On Jan 5, 2015, at 12:01 PM, openssl at comaxis.com wrote: >>>> Are there any known problems using OpenSSL with iCloud? I am trying to >>>> connect to imap.mail.me.com using port 993. My call to SSL_Connect() >>>> returns 0, with SSL_get_error() returing 1 (SSL_ERROR_SSL). I am using >>>> OpenSSL version 1.0.1h, running on Win32. I can use this code with any >>>> other IMAP server with no problems. >>> >>> >>> Are you able to connect using the openssl s_client application? I can >>> connect (to port 993, no starttls) with either 1.0.1j or 0.9.8za; >>> perhaps >>> s_client will give you a more diagnostic error message if it also fails >>> for you. >>> >> I made a build of 1.0.1j but it made no difference to my application. In >> fact, I *can* use "openssl s_client -connect" with iCloud. Doing the same >> thing with my own server (which my application works with) the only thing >> I see different in the diagnostics provided by openssl is the cipher: >> for imap.mail.me.com I get "AES256-GCM-SHA384" but with my own, I >> get "ECDHE-RSA-AES256-GCM-SHA384". Do I need to do something in the build >> open OpenSSL to get support for AES256, or something different in my code >> that uses SSL? I would assume the latter, since the openssl utility is >> using my brand new builds of the ssl dlls. Here is what I am doing (with >> error checking removed): >> >> SSL_library_init(); >> SSL_load_error_strings(); >> wsprintf (seed,"%lx%lx", GetCurrentProcessId(), time(0)); >> RAND_seed (seed, strlen(seed)); >> meth=SSLv3_method(); >> ctx = SSL_CTX_new(meth); >> >> SSL_CTX_set_options(ctx,0); >> SSL_CTX_set_verify(ctx,SSL_VERIFY_NONE,NULL); >> SSL_CTX_set_default_verify_paths(ctx); >> ssl = SSL_new(ctx); >> sbio = BIO_new_socket(gSocket, BIO_NOCLOSE); >> SSL_set_bio(ssl, sbio, sbio); >> ret = SSL_connect(ssl); From rohit.kaushal at gmail.com Tue Jan 6 02:02:21 2015 From: rohit.kaushal at gmail.com (Rohit Kaushal) Date: Mon, 5 Jan 2015 18:02:21 -0800 Subject: [openssl-users] POST Integrity test/fingerprint failure on 32-bit MIPS/R3000 with openssl-fips-2.0.5 Message-ID: Hello, I am working on a validation with a FIPS lab including algorithm testing etc. and not claim any OpenSSL 2.0.5 FIPS certs. For this, i have made minor changes to the fips-openssl-2.0.5 source including the fips_test_suite.c file. This (modified) fips_test_suite binary with fipscanister.o static linkage runs fine on MIPS. A cloned binary (my_fips_test_suite) linked via a FIPS capable libcrypto.so (openssl-1.0.1j) fails. This behavior is seen when compiled natively on MIPS or via a mipscross toolchain (mipsisa32-xlr-linux). The configure env on my (x86) build machine provides the necessary ARCH and CC so CROSS_COMPILE isn't specified. The incore allows the binary creation to compute the hmac-sha1 for fipscanister and fips_premain. The fipsopenssl objects get installed in /usr/local/ssl/fips-2.0 fine. The fipscanister.o, fips_premain.c and their .sha1 files are copied to /myinstall/usr/lib as the fipslibdir path prior to building openssl 1.0.1j. -------- begin script for fipsopenssl > cd openssl-fips-2.0.5 > export MACHINE=mips > export SYSTEM=Linux > export ARCH=mips > export CROSS_COMPILE= > export FIPS_SIG=/mysrc/openssl-fips-2.0.5/util/incore > export HOSTCC=gcc > ./config > make > make build_tests > make build_algvs -------- end script for fipsopenssl -------- begin script for openssl ./config no-asm threads shared fips --prefix=/usr --install_prefix=/myinstall \ --with-fipslibdir=/myinstall/usr/lib/ -------- end script for openssl -------- begin cross compilation output for fipsopenssl + cd /mysrc/openssl-fips-2.0.5 + export MACHINE=mips + MACHINE=mips + export SYSTEM=Linux + SYSTEM=Linux + export ARCH=mips + ARCH=mips + export CROSS_COMPILE= + CROSS_COMPILE= + export FIPS_SIG=/mysrc/openssl-fips-2.0.5/util/incore + FIPS_SIG=/mysrc/openssl-fips-2.0.5/util/incore + export HOSTCC=gcc + HOSTCC=gcc + /mysrc/openssl-fips-2.0.5/config Operating system: mips-whatever-linux2 Auto Configuring fipsonly Configuring for linux-generic32 CC =/opt/mipscross/crosstool/gcc-3.4.3-glibc-2.3.6/mipsisa32-xlr-linux/bin/mipsisa32-xlr-linux-gcc CFLAG =-DOPENSSL_FIPSCANISTER -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DTERMIO -O3 -fomit-frame- pointer -Wall ------- end cross compilation output for fipsopenssl ------- begin objdump on x86 build machine with MIPS cross compiler -bash-3.2$ objdump -t fipscanister.o | grep FIPS_ro 00000000 g O .rodata 00000010 FIPS_rodata_start 0000ca40 g O .rodata 00000010 FIPS_rodata_end -bash-3.2$ objdump -t fipscanister.o | grep FIPS_text 00000000 l F .text 00000000 FIPS_text_startX 000578e0 l F .text 00000000 FIPS_text_endX 00057900 g F .text 00000000 FIPS_text_end 00000020 g F .text 00000000 FIPS_text_start -bash-3.2$ objdump -t libcrypto.so.1.0.1 | grep FIPS_ro 001c4770 g O .rodata 00000010 FIPS_rodata_start 001d11b0 g O .rodata 00000010 FIPS_rodata_end -bash-3.2$ objdump -t libcrypto.so.1.0.1 | grep FIPS_text 0004a800 l F .text 00000000 FIPS_text_startX 000a20e0 l F .text 00000000 FIPS_text_endX 000a2100 g F .text 00000000 FIPS_text_end 0004a820 g F .text 00000000 FIPS_text_start The .text offset differs by 0x0004a800 b/w libcrypto and fispcanister.o The .rodata offset differs by 0x001c4770 b/w libcrypto and fispcanister.o -bash-3.2$ objdump -t fipscanister.o | grep -i FIPS | wc 776 4654 42131 -bash-3.2$ objdump -t libcrypto.so.1.0.1 | grep -i FIPS | wc 787 4722 52864 The additional objdump output for libcrypto.so are... 00000000 l df *ABS* 00000000 o_fips.c 00000000 l df *ABS* 00000000 fips_ers.c 00200190 l O .data 000001b0 FIPS_str_reasons 00200340 l O .data 00000200 FIPS_str_functs 0020b540 l O .data 00000004 fips_drbg_flags 0020b544 l O .data 00000004 fips_drbg_type 00000000 l df *ABS* 00000000 evp_fips.c 001359c4 g F .text 00000000 RAND_set_fips_drbg_type 0004a6f0 g F .text 00000000 ERR_load_FIPS_strings 0004a5b8 g F .text 00000000 FIPS_mode_set 0004a580 g F .text 00000000 FIPS_mode 001359e4 g F .text 00000000 RAND_init_fips 0004a580 g F .text 00000000 FIPS_mode --------- end objdump on x86 build machine with MIPS cross compiler --------- begin runtime output on MIPS target bash>./my_fips_test_suite 1. Non-Approved cryptographic operation test... DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK a. Included algorithm (D-H)......successful POST started Integrity test started Integrity test Failed Incorrectly!! ... POST Failed 2. Automatic power-up self test...Failed! --------- end runtime output on MIPS target Happy to provide any details to get some guidance on what to debug or edit for MIPS configure/incore ? Thank you. Best, rk -------------- next part -------------- An HTML attachment was scrubbed... URL: From bird_112 at hotmail.com Tue Jan 6 02:37:24 2015 From: bird_112 at hotmail.com (jack seth) Date: Mon, 5 Jan 2015 20:37:24 -0600 Subject: [openssl-users] Need help encrypting my ca.key Message-ID: I must be doing something wrong but I can't figure out what it is. I am trying to encrypt my private ca key with this command openssl rsa -in ca.key -out caencrypted.key -aes256 This works fine but the problem is I don't get the original key back when I decrypt it using this command openssl rsa -in caencrypted.key -out catest.key catest.key doesn't have the same characters in it as ca.key when looking at them in a text editor. What am I missing here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 6 02:48:13 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Jan 2015 02:48:13 +0000 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: References: Message-ID: <20150106024813.GC7322@mournblade.imrryr.org> On Mon, Jan 05, 2015 at 08:37:24PM -0600, jack seth wrote: > I must be doing something wrong but I can't figure out what it is. I am trying to encrypt my private ca key with this command > > openssl rsa -in ca.key -out caencrypted.key -aes256 > > This works fine but the problem is I don't get the original key back when I decrypt it using this command > > openssl rsa -in caencrypted.key -out catest.key > > > catest.key doesn't have the same characters in it as ca.key when looking at them in a text editor. What am I missing here? There are multiple possible key formats for the same key. Instead compare the outputs of: $ umask 077 $ openssl rsa -in ca.key -noout -text > txt1 $ openssl rsa -in catest.key -noout -text > txt2 $ diff txt1 txt2 -- Viktor. From bird_112 at hotmail.com Tue Jan 6 05:04:19 2015 From: bird_112 at hotmail.com (jack seth) Date: Mon, 5 Jan 2015 23:04:19 -0600 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: <20150106024813.GC7322@mournblade.imrryr.org> References: , <20150106024813.GC7322@mournblade.imrryr.org> Message-ID: Thanks for the response. First I am running this on Windows 7. Questions 1. How can I determine what key format my ca.key is in? 2. You say there are multiple key formats for the same key, but for my peace of mind I would like to get the same key format that I originally had. How can I do this? > Date: Tue, 6 Jan 2015 02:48:13 +0000 > From: openssl-users at dukhovni.org > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Need help encrypting my ca.key > > On Mon, Jan 05, 2015 at 08:37:24PM -0600, jack seth wrote: > > I must be doing something wrong but I can't figure out what it is. I am trying to encrypt my private ca key with this command > > > > openssl rsa -in ca.key -out caencrypted.key -aes256 > > > > This works fine but the problem is I don't get the original key back when I decrypt it using this command > > > > openssl rsa -in caencrypted.key -out catest.key > > > > > > catest.key doesn't have the same characters in it as ca.key when looking at them in a text editor. What am I missing here? > > There are multiple possible key formats for the same key. Instead > compare the outputs of: > > $ umask 077 > $ openssl rsa -in ca.key -noout -text > txt1 > $ openssl rsa -in catest.key -noout -text > txt2 > $ diff txt1 txt2 > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 6 05:13:49 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Jan 2015 05:13:49 +0000 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: References: <20150106024813.GC7322@mournblade.imrryr.org> Message-ID: <20150106051349.GJ7322@mournblade.imrryr.org> On Mon, Jan 05, 2015 at 11:04:19PM -0600, jack seth wrote: > Thanks for the response. First I am running this on Windows 7. Questions > > 1. How can I determine what key format my ca.key is in? openssl asn1parse -in ca.key (don't post the output). plus some knowledge of the various ASN.1 encodings (PKCS#8, ...). See the pkey(1) and rsa(1) manpages from OpenSSL 1.0.0 or later. > 2. You say there are multiple key formats for the same key, but > for my peace of mind I would like to get the same key format that > originally had. How can I do this? Copy the original file. :-) > > There are multiple possible key formats for the same key. Instead > > compare the outputs of: > > > > $ umask 077 > > $ openssl rsa -in ca.key -noout -text > txt1 > > $ openssl rsa -in catest.key -noout -text > txt2 > > $ diff txt1 txt2 This really is sufficient to do the comparison. You can adapt to Windows without too much effort. -- Viktor. From noloader at gmail.com Tue Jan 6 05:23:35 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 6 Jan 2015 00:23:35 -0500 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: References: <20150106024813.GC7322@mournblade.imrryr.org> Message-ID: On Tue, Jan 6, 2015 at 12:04 AM, jack seth wrote: > Thanks for the response. First I am running this on Windows 7. Questions > > 1. How can I determine what key format my ca.key is in? If its binary, then its simply ASN.1/DER encoded. If its ASCII (human readable) and starts with MII (IIRC), then its Base64 encoded ASN.1/DER. If its ASCII (human readable) and starts with ----- BEGIN XXX -----, then its PEM. > 2. You say there are multiple key formats for the same key, but for my peace > of mind I would like to get the same key format that I originally had. How > can I do this? Use -outform to control the output encoding. I think the two values of interest are DER and PEM. Jeff From openssl-users at dukhovni.org Tue Jan 6 05:37:25 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Jan 2015 05:37:25 +0000 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: References: <20150106024813.GC7322@mournblade.imrryr.org> Message-ID: <20150106053725.GM7322@mournblade.imrryr.org> On Tue, Jan 06, 2015 at 12:23:35AM -0500, Jeffrey Walton wrote: > Use -outform to control the output encoding. I think the two values of > interest are DER and PEM. What actually matters are multiple ASN.1 key formats. Whether the ASN.1 is raw binary or packaged in PEM is secondary. $ openssl genrsa 512 -----BEGIN RSA PRIVATE KEY----- MIIBOwIBAAJBALo6pp7yqc3Yb/NnBzr7SXJZ9ZdiSaxVs3CCuJJYyF2WLGsj/Ku/ 9konSOGXmu0Jgyj0PvaF6w8ahuSt9DrUSm0CAwEAAQJAGovNwI6awer+WlXvY+r6 F0DXj1LFabl1sK4RnVrmhOBrAuakW+k6TCDlFD6dn6atL5eUtpfx9LJqEzDKNeF/ CQIhAOBTVljS6gi44fNv6eV1WvnshWxm998gg4vZdYRtaAWHAiEA1IY/VBa5JiUp BUk9ahoCefARGG8XbkqndMeC00Hk7WsCIQCZl3Xfi0nCfxP14gJ7oUaRKGiSOE4u 78whzNqxuVcnsQIgaGBim+7pEfXwNpto4UJS8wZXrxNog4+AvNb7xru3Lm8CIQCO wYET4FCkEz4HQQ6ldz32dp9mjny4g65pXzGgDI4VUw== -----END RSA PRIVATE KEY----- $ openssl genrsa 512 | openssl pkey -----BEGIN PRIVATE KEY----- MIIBVQIBADANBgkqhkiG9w0BAQEFAASCAT8wggE7AgEAAkEA1YPZYCY0C70K3Pfp OloIoOyUlqosTI3TlWs9UkH+qbi3Tpt67X+hMy0Jh67Zur5pzbDJ+oP7n7snYzCv WH+9KQIDAQABAkBqmKPa09fiEGQvA3omDrMGHHbmbVkmcxwyGdMIkTgh5NPFNSLO /ZGK6WtjwAiDjTTAzOpFZyhC9FqFyk8ZNbtxAiEA82KP3RccwBkAAterVBLfcjZ/ RxAAou47Xb8MQuTeg70CIQDglPJ2LPNDTs9AL6+M+4GLN7Gd0CxoFSq2HmGOE3a/ 3QIhAIWdh5N+G8eOMgZddm6Kiec+6fMOYvsPxMG7n7Sdx1cVAiBGO25DtLTylJ/N k9wTe8e8UNNz5dktR4lO4NtjQgT95QIhAIfTJUtxbp5pnDD1MY1VdSdFb+r9pYBd Wv5nsvJuR+kj -----END PRIVATE KEY----- The second of these is PKCS#8, the ASN.1 encoding contains an algorithm identifier wrapped around the key data in the second case. $ openssl genrsa 512 2>/dev/null| openssl asn1parse 0:d=0 hl=4 l= 314 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :00 7:d=1 hl=2 l= 65 prim: INTEGER :F778575DCAA1A82AFC543BB9BB2C78AD7C65E75BA1AEC2042474E3FB11D309C8F86158327E18FF8C169DD85431CFFDFF7AC2044B023FBFCA6FFBB003A1BD7A4F 74:d=1 hl=2 l= 3 prim: INTEGER :010001 79:d=1 hl=2 l= 64 prim: INTEGER :4B6C2C0473EB8D1B7CC81763E5FE09D1A62650BB06AE0287CCACAB872BC98C2350D2E35AF5B8D46C0969791A8750E329B233C7C62360CB20237505A67ACC3501 145:d=1 hl=2 l= 33 prim: INTEGER :FCE7B9C91BF6DDBC3A097674B541B079872B5A07F6EB5D6715A5F356BEBF3841 180:d=1 hl=2 l= 33 prim: INTEGER :FA7F96CCEDEA1F156EBF42A03E670D5476327068951237E0483FA07C2D798E8F 215:d=1 hl=2 l= 33 prim: INTEGER :8D705B2AEA04CA45767FCC4BC10317DB1F895334991750895246192D2E486B01 250:d=1 hl=2 l= 32 prim: INTEGER :76CB9B508463CB69F6A36D8D610AAE1FA80E3390E561466E6ED4FDDEE61207B1 284:d=1 hl=2 l= 32 prim: INTEGER :3EFC405C0EF05DBBB15060BC6026DED2D9BAC7EA74C5E78E0DA1118D5DB2057C $ openssl genrsa 512 2>/dev/null| openssl pkey | openssl asn1parse 0:d=0 hl=4 l= 341 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :00 7:d=1 hl=2 l= 13 cons: SEQUENCE 9:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption 20:d=2 hl=2 l= 0 prim: NULL 22:d=1 hl=4 l= 319 prim: OCTET STRING [HEX DUMP]:3082013B0201000241009490922BEE6320FEC958EC6CCAAB7844A1A6DF4C7A76E4CB2845C6A4FC324487312BE187CD10749E4A29A105F23B19E927AB1A347C668BF3C96C6C407F66FA43020301000102405707258974993F3FE1C524A24A4B0E25EE2829D0CC408FA06ED4091CA6DBEF85FA06C77BC0CCD9239C93A746857AB7AB8773D5D7B43A38C1DDAC208B71C9EE79022100C5DC2867DBDD1DE355001E9A174DE0B344CB202FD36F7BB16D3DAED8A596675F022100C038388D144730C58C781BDE93B8C1C112452F5FB0038F54132020DA11978B9D022100A5D4AFC8DC6DA6EF31FEB7A74E80E723593525F4EFB1306AB4B44E272621B8E1022033B3EBA226FE2F2433F06AAEA7D55E686C5DA7AC794FBBD1C58332D2F5406A11022100A9F30E296B6981C28607E03B5BD07CE437D67FD0EC698AC6390B07477BF221AC $ openssl genrsa 512 2>/dev/null| openssl pkey | openssl asn1parse -strparse 22 0:d=0 hl=4 l= 314 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :00 7:d=1 hl=2 l= 65 prim: INTEGER :BAD0B8BB3BC5919E1D74F913B1702DDC838E1ACDB43465C3786BF825464573F1C9E7FE775A0DC4CE65BFF689A1ACA87B48250FF541638F97A237051E50619C5F 74:d=1 hl=2 l= 3 prim: INTEGER :010001 79:d=1 hl=2 l= 64 prim: INTEGER :41D9A2D434CC7E78CA8F59E0EC31CBA8A822A6260E384E0AA9DEFD183E7DEAD11C8644271246A116FE870875B13010FE71F3E55BA5BD98A4C4B380F2A664AE41 145:d=1 hl=2 l= 33 prim: INTEGER :E1F5F199701FFFE8C18C4F0683A18F165877C52C6E09B785B332999248D07E61 180:d=1 hl=2 l= 33 prim: INTEGER :D3A68DC15442FEB6FDCC2F19C7276391EAF0F437FF300FBDA728F8BFCCC092BF 215:d=1 hl=2 l= 33 prim: INTEGER :BEAF98C54DD413584F0DA31AF23682D3EEB0945A9C39E300176B9A21D304EFC1 250:d=1 hl=2 l= 32 prim: INTEGER :106987F087F232024AA7FCB709047AEA23C7CF8850179000EAE7787297140FCD 284:d=1 hl=2 l= 32 prim: INTEGER :0B401B54C892FD9A9059215E35ADAF2E86820B5616F80F19FCC71E7A81700701 -- Viktor. From noloader at gmail.com Tue Jan 6 05:57:02 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 6 Jan 2015 00:57:02 -0500 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: <20150106053725.GM7322@mournblade.imrryr.org> References: <20150106024813.GC7322@mournblade.imrryr.org> <20150106053725.GM7322@mournblade.imrryr.org> Message-ID: On Tue, Jan 6, 2015 at 12:37 AM, Viktor Dukhovni wrote: > On Tue, Jan 06, 2015 at 12:23:35AM -0500, Jeffrey Walton wrote: > >> Use -outform to control the output encoding. I think the two values of >> interest are DER and PEM. > > What actually matters are multiple ASN.1 key formats. Whether the > ASN.1 is raw binary or packaged in PEM is secondary. > It seems to me he's interested in using the same format so the keys don't diff across commands. He should probably pick something (-outform PEM or DER) and use it consistently to satisfy his requirements. If I misread, then my apologies. From Richard.Dwan at neul.com Tue Jan 6 10:57:40 2015 From: Richard.Dwan at neul.com (Richard Dwan) Date: Tue, 6 Jan 2015 10:57:40 +0000 Subject: [openssl-users] A quick note about recent development builds of Node.js that others might find useful Message-ID: Just something to help others that use openSSL in Node.js add-ons with recent Node builds (0.11.15); building node to use the system ssl library (rather than it's built in copy) appears to make a significant difference to an add-on that attempts to use the ssl library itself. Doing this resolved my prior inexplicable problem. (snip) > I have successfully managed to compile and link to a current openssl library (openssl-1.0.1j.tar.gz) but have been unable to determine what are the likely causes of the following error messages: > > 139924302898976:error:1411C146:SSL routines:tls1_prf:unsupported digest type:t1_enc.c:276: > 139924302898976:error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable:t1_enc.c:602: (snip) Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From curious_freddy at gmsl.co.uk Tue Jan 6 10:42:35 2015 From: curious_freddy at gmsl.co.uk (Fred) Date: Tue, 06 Jan 2015 10:42:35 +0000 Subject: [openssl-users] Specify algorithm for openssl smime decrypt Message-ID: <54ABBC1B.3080107@gmsl.co.uk> Hi, I need to decrypt some S/MIME content with an invalid key length for the AlgOID specified in the PCKS7 content. AES-256 is specified as the AlgOID, but a key length of 192 bits is being used. Is there anyway to get openssl to decrypt this using the openssl smime command? i.e. override the cipher used so that is uses aes-192-cbc ? From steve at openssl.org Tue Jan 6 12:38:59 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 6 Jan 2015 12:38:59 +0000 Subject: [openssl-users] Specify algorithm for openssl smime decrypt In-Reply-To: <54ABBC1B.3080107@gmsl.co.uk> References: <54ABBC1B.3080107@gmsl.co.uk> Message-ID: <20150106123859.GA5817@openssl.org> On Tue, Jan 06, 2015, Fred wrote: > Hi, > > I need to decrypt some S/MIME content with an invalid key length > for the AlgOID specified in the PCKS7 content. > > AES-256 is specified as the AlgOID, but a key length of 192 bits is > being used. > > Is there anyway to get openssl to decrypt this using the openssl > smime command? i.e. override the cipher used so that is uses > aes-192-cbc ? Not using the smime command no. There are ways to handle this either with a short program or by using a binary cut+paste using asn1parse. Another alternative is to use a modified version of OpenSSL which detects this and works around the problem. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Tue Jan 6 12:59:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Jan 2015 07:59:06 -0500 Subject: [openssl-users] Web site problem In-Reply-To: <-bqoakhrPP4PXO0@srv.efca.com> References: <-bqoakhrPP4PXO0@srv.efca.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55237859@USMBX1.msg.corp.akamai.com> > Starting a few days ago, www.openssl.org when clicking on the Source tab, > then selecting the GitWeb tab, redirects you to git.openssl.org (probably ok ? > ) but that page returns the OpenSSL home page (same as www.openssl.org) > so no web git access. It wasn't a DNS problem, it was an Apache config problem. We want to send people to github for general git-web activity. I forgot to remote the tab. Thanks! -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From BenBE at geshi.org Tue Jan 6 17:43:24 2015 From: BenBE at geshi.org (Benny Baumann) Date: Tue, 06 Jan 2015 18:43:24 +0100 Subject: [openssl-users] [openssl-dev] OpenSSL source reformat In-Reply-To: <54AA7EFB.1060409@openssl.org> References: <54AA7EFB.1060409@openssl.org> Message-ID: <54AC1EBC.3050905@geshi.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Matt, first of all: THANK YOU! This has been overdue for ages! Just a small tweak that would be nice I'd like to see would be to always have block markers for loops and conditions. The lack of those was one of the many pitfalls with the old source especially as the indentation had been off by one level in contrast to common rules. Including the the block markers (AKA curly brackets) at all times even for single statements has two advantages: - - You always have a block grouping statements to the proper statement - - You won't create a Apple-Style Goto Fail that easily AFAIK indent should support adding all of them automagically; otherwise astyle is another powerful solution. Anyway: BIG THANKS for finally making the code readable*. Kind regards, BenBE. *Comprehensible is a different kettle of fish ;-) Am 05.01.2015 um 13:09 schrieb Matt Caswell: > We have previously announced our intention to reformat the entire > codebase into a more consistent style (see our roadmap document > here: https://www.openssl.org/about/roadmap.html) > > Since then we have been busy working towards doing that. I'd like > to make available for comment a sample reformat. So far I've run it > for master and 1.0.2, but the current thinking is that this will > also be applied to 1.0.1, 1.0.0 and 0.9.8 (this is necessary to > significantly ease the maintenance overhead) > > I've put the results of the reformat up on my github account here: > https://github.com/mattcaswell/openssl > > The reformat of master is on the "sample-master-reformat" branch, > and the 1.0.2 reformat is on "sample-1.0.2-reformat". > > The style itself is heavily influenced by the Linux Kernel Coding > style: https://www.kernel.org/doc/Documentation/CodingStyle > > Although there are some significant differences - most notably that > we are using spaces not tabs for indents, and the indent depth is > 4 characters not 8. We will be publishing our own style guide in > due course. > > I'm not looking to open any religious wars here - so I'm not > looking for comments on the style itself (e.g. debates about > whether 2, 4 or 8 character indents are better (we've already had > those!)) - but I'm mainly seeking feedback on anywhere where the > reformatting has failed. We've already looked of course...but > sometimes many sets of eyes are better! > > I've also made available the script that was used to do the > reformatting. The script is called openssl-format-source and is in > the util directory of the branches mentioned above. This script > depends on GNU indent being available. It should be executed from > the root of the source tree as follows: > > util/openssl-format-source -v -c . > > There are also some one-off manual tweaks (both before and after > running the script) that need to be done which are present in the > sample reformat branches. These are related to multi-line comments > which have their own internal formatting - these aren't handled > too well. The manual steps should be a one-off exercise though. The > hope is that we will be able to re-run the script at regular > intervals. > > Thanks > > Matt > > _______________________________________________ openssl-dev mailing > list openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUrB67AAoJEPHTXLno4S6tdR0P/R7MQGYZ5cRErk/55luMZLgi Om9JmXBa4NCKedVVUXLQOlkiWu4Oa3s/J0xezTwzCR5P+B9x0miDUMjm9yKy6g4q t3mhAAiGOKfofLVq7M6iOE72SO2Pd4FTCywVMPuE6p9vAK7o/Gufn/8W52ud8oBb l7O5l2o6B0191q+6v3oLb8zY028FESrJgTDfq4htzvVlOkl3mnzvXP87juyrEzIb Y4FY7DzGi146mkRro3Q3Yb0fQcNTvVajQyAMLsLTRWDSXFs998BFxMih3hlJa+gc SvPi/rjE/gNaRxB3obc0o48hdy3Q7Q6DvpxVqwxb7Y2i3kWwJaCRCcOsEvYhfqkt 5kevKe/exKEyDWtjokWat9alB/Qla6Yb725OjOo4UQvmjT2OwULB9uFoXxig3/H/ oBES33FAAU0Kul4YwmfWb17m2QWeXHcqTITXUuS2zasMxF+2wbgb5o3bcQx7QUnd Fxf4emHb9OVqLdiN7WyNkUBceot2IBB73hud2myfKZS9g71F5hhsdsXvoWp5e3/I Cp1hnD2ViE5hWF4bGbKM7Eom9IeEho1idKCGGhfgRJ2tjweP66ORZnUK+Dz84N7a Je1peZ95uAUCy2F/PI2QFpxgvSU9lHiHGpRoEQRGbCn0N24La6mi0B7APjhWgHXk tiPO8GEKG7W5TGq0thzL =iwE9 -----END PGP SIGNATURE----- From noloader at gmail.com Tue Jan 6 18:21:22 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 6 Jan 2015 13:21:22 -0500 Subject: [openssl-users] OpenSSL source reformat In-Reply-To: <54AA7F36.5080105@openssl.org> References: <54AA7F36.5080105@openssl.org> Message-ID: On Mon, Jan 5, 2015 at 7:10 AM, Matt Caswell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We have previously announced our intention to reformat the entire > codebase into a more consistent style (see our roadmap document here: > https://www.openssl.org/about/roadmap.html) > ... Beers on me! Steve: Can I send a case of Heinekens to the Foundation and trust everyone gets a cold one? Jeff From marquess at openssl.com Tue Jan 6 18:29:34 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 06 Jan 2015 13:29:34 -0500 Subject: [openssl-users] OpenSSL source reformat In-Reply-To: References: <54AA7F36.5080105@openssl.org> Message-ID: <54AC298E.8000607@openssl.com> On 01/06/2015 01:21 PM, Jeffrey Walton wrote: > On Mon, Jan 5, 2015 at 7:10 AM, Matt Caswell wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> We have previously announced our intention to reformat the entire >> codebase into a more consistent style (see our roadmap document here: >> https://www.openssl.org/about/roadmap.html) >> ... > > Beers on me! > > Steve: Can I send a case of Heinekens to the Foundation and trust > everyone gets a cold one? Er, well, we're spread across multiple continents so shipping it around would be a bit of an issue. I have enough trouble with declarations and import duties for computer gear; I have no idea what's involved with recuperative beverages. But I volunteer to drink it and tell my colleagues how good it was :-) -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From thevoog at voog.ca Tue Jan 6 18:52:01 2015 From: thevoog at voog.ca (Chris Eltervoog) Date: Tue, 06 Jan 2015 11:52:01 -0700 Subject: [openssl-users] openssl, opencrypto integration Message-ID: <20150106115201.eeb34916bcd0f3b3f2a731314e331348.e50f79e840.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jan 6 19:48:20 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 06 Jan 2015 19:48:20 +0000 Subject: [openssl-users] OpenSSL source reformat In-Reply-To: <54AC298E.8000607@openssl.com> References: <54AA7F36.5080105@openssl.org> <54AC298E.8000607@openssl.com> Message-ID: <54AC3C04.5080504@openssl.org> On 06/01/15 18:29, Steve Marquess wrote: > But I volunteer to drink it and tell my colleagues how good it was :-) Its good to see the spirit of Open Source alive and well - with everyone pitching in to do their bit. :-) Matt From bird_112 at hotmail.com Tue Jan 6 23:25:21 2015 From: bird_112 at hotmail.com (jack seth) Date: Tue, 6 Jan 2015 17:25:21 -0600 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: References: , <20150106024813.GC7322@mournblade.imrryr.org>, , Message-ID: Well I ran the command openssl asn1parse -in ca.key I got a bunch of numbers, a hex dump, and something that says 'rsaEncryption' but I don't see anything that looks like ASN.1, DER or PEM. You were right that I want the output to stay the same as the original. My key is human readable. It does have MII at the start but it also has ----Begin Private Key---- at the beginning. Any more steps to follow to find out what type of key this is? > Date: Tue, 6 Jan 2015 00:23:35 -0500 > From: noloader at gmail.com > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Need help encrypting my ca.key > > On Tue, Jan 6, 2015 at 12:04 AM, jack seth wrote: > > Thanks for the response. First I am running this on Windows 7. Questions > > > > 1. How can I determine what key format my ca.key is in? > If its binary, then its simply ASN.1/DER encoded. > > If its ASCII (human readable) and starts with MII (IIRC), then its > Base64 encoded ASN.1/DER. > > If its ASCII (human readable) and starts with ----- BEGIN XXX -----, > then its PEM. > > > 2. You say there are multiple key formats for the same key, but for my peace > > of mind I would like to get the same key format that I originally had. How > > can I do this? > > Use -outform to control the output encoding. I think the two values of > interest are DER and PEM. > > Jeff > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 6 23:39:04 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Jan 2015 23:39:04 +0000 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: References: <20150106024813.GC7322@mournblade.imrryr.org> Message-ID: <20150106233903.GS7322@mournblade.imrryr.org> On Tue, Jan 06, 2015 at 05:25:21PM -0600, jack seth wrote: > Well I ran the command > openssl asn1parse -in ca.key > > I got a bunch of numbers, a hex dump, and something that says 'rsaEncryption' In that case, this is a PKCS#8 file encoded in PEM. The first line was probably: -----BEGIN PRIVATE KEY----- > It does have MII at the start but it also has ----Begin Private Key---- at the beginning. Now that I've read this far, good to see everything still makes sense. > Any more steps to follow to find out what type of key this is? It is an RSA key, in PKCS#8 format, encoded as PEM. The "openssl pkey" command outputs PKCS#8. The "openssl rsa" command outputs the legacy RSA format. Use "openssl pkey" not "openssl rsa". But to be blunt this is all a big waste of time. Both formats work just fine, and contain identical data, if you bother to check it with "-text". -- Viktor. From bird_112 at hotmail.com Wed Jan 7 03:38:24 2015 From: bird_112 at hotmail.com (jack seth) Date: Tue, 6 Jan 2015 21:38:24 -0600 Subject: [openssl-users] Need help encrypting my ca.key In-Reply-To: <20150106233903.GS7322@mournblade.imrryr.org> References: , <20150106024813.GC7322@mournblade.imrryr.org>, , , , <20150106233903.GS7322@mournblade.imrryr.org> Message-ID: Thanks for your help. I prefer to err on the side of caution. Before I delete my plaintext ca.key; I want to be absolutely sure that I get back the exact key when I decrypt it. I'm a noob with this so I don't want to take any chances. Thanks again. > Date: Tue, 6 Jan 2015 23:39:04 +0000 > From: openssl-users at dukhovni.org > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Need help encrypting my ca.key > > On Tue, Jan 06, 2015 at 05:25:21PM -0600, jack seth wrote: > > > Well I ran the command > > openssl asn1parse -in ca.key > > > > I got a bunch of numbers, a hex dump, and something that says 'rsaEncryption' > > In that case, this is a PKCS#8 file encoded in PEM. The first > line was probably: > > -----BEGIN PRIVATE KEY----- > > > It does have MII at the start but it also has ----Begin Private Key---- at the beginning. > > Now that I've read this far, good to see everything still makes > sense. > > > Any more steps to follow to find out what type of key this is? > > It is an RSA key, in PKCS#8 format, encoded as PEM. The "openssl > pkey" command outputs PKCS#8. The "openssl rsa" command outputs > the legacy RSA format. Use "openssl pkey" not "openssl rsa". > > But to be blunt this is all a big waste of time. Both formats work > just fine, and contain identical data, if you bother to check it > with "-text". > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jan 7 08:47:12 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 07 Jan 2015 09:47:12 +0100 Subject: [openssl-users] openssl, opencrypto integration In-Reply-To: <20150106115201.eeb34916bcd0f3b3f2a731314e331348.e50f79e840.wbe@email13.secureserver.net> References: <20150106115201.eeb34916bcd0f3b3f2a731314e331348.e50f79e840.wbe@email13.secureserver.net> Message-ID: <54ACF290.4000607@wisemo.com> (Resend from correct account) On 06/01/2015 19:52, Chris Eltervoog wrote: > > I have implemented a H/W encryption driver and have integrated it with > cryptodev. In eng_cryptodev.c there is an array digests[]. In that > array it defines CRYPTO_MD5 to have a keylen of 16. In cryptodev, the > xform.c file definedes MD5 to have a keylen of 0. Why is the keylen > not zero for the MD5 entry in this table? > I presume that this particular array uses the field name "keylen" to really refer to the hashlen (the size of the digest value), since digests generally don't have keys (otherwise they would be considered MAC algorithms). The code in xform.c then probably refers to a more general definition, which encompasses both digests and MACs, and uses a 0 MAC keylen to indicate that this is a digest, not a MAC. > Cryptodev also defines the keylen in a structure. The keylen is zero > there. A comparison happens on session creation. This difference > causes a check in the session creation to fail and cryptodev always > selects the s/w crypto engine. If I change the eng_cryptodev digests[] > entry for CRYPTO_MD5 to have a keylen of zero the MD5 hashing works, > however Key generation output changes. If you run the openssl test > case for key generation it will fail. It seems that the files > generated are smaller. I don't see how this change has this side > affect with key generation. > IF my previous presumption is right, the correct change would be to keep both tables as they are, but change the comparison to compare values that are actually supposed to be the same, such as MAC key length to MAC key length (implicit 0 in the digests[] array), and result length to result length (named keylen in the digests[] array). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jan 7 09:04:31 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 07 Jan 2015 10:04:31 +0100 Subject: [openssl-users] OpenSSL Release Strategy and Blog In-Reply-To: <20141228112634.GA26337@roeckx.be> References: <5499FF9F.6040205@openssl.org> <549F4F6A.9010507@wisemo.com> <20141228112634.GA26337@roeckx.be> Message-ID: <54ACF69F.8020307@wisemo.com> On 28/12/2014 12:26, Kurt Roeckx wrote: > On Sun, Dec 28, 2014 at 01:31:38AM +0100, Jakob Bohm wrote: >> 3. The 1.0.x binary compatibility promise seems to not have been >> completely kept. As recently as just this December, As a practical >> example: I had an OS upgrade partially fail due to the presence of >> a self-compiled up to date 1.0.1* library that conflicted with an >> OS supplied 1.0.x library that was frozen earlier while relying on >> your promise. > Can you give more details about this? Please note the binary > compatibility will only work if you used the same options to build > the library. (This is one of the reasons to make more structures > opaque.) Yep, I presume the distribution packagers used different compile options for the 1.0.x installed in /usr/lib, than I had used for the 1.0.1 installed in /usr/local/lib. >> Also the 1.0.1 changelog includes at least one change of binary >> flag values to get a different compatibility behavior than >> previous 1.0.1 releases, thus there is not even binary >> compatibility within 1.0.1 . > I assume you're talking about SSL_OP_NO_TLSv1_1? It's unfortunate > that SSL_OP_ALL already contained that in 1.0.0 while 1.0.0 > doesn't even know anything about TLS 1.1. But that only affects > people who compiled with 1.0.1 or 1.0.1a headers. Yes, that's exactly the one. > >> must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1) >> as the new LTS release, and you need to deal with the fact that >> since the 0.9.8 end-of-life announcement, you have been unclear >> which of the two existing 1.0.x releases would be LTS-security, >> causing some projects (not mine, fortunately) to irreversibly >> pick a different one than you did. > I think people should stop using both 0.9.8 and 1.0.0 as soon as > possible since they do not support TLS 1.2. You really want to use > TLS 1.2. I agree, that is why I had a locally compiled 1.0.1 on that particular system. > >> The best you can do is to split libcrypt into two or tree well >> defined layers, that can be mixed in applications but do not break >> their layering internally. These could be: rawalgs (non-opaque >> software primitives, bignums etc. with CPU acceleration but >> nothing more fancy) > I don't think we intend to remove functions like AES_* yet but > might deprecate them in favour APIs that exist for a very long > time. Please note that for instance using the AES functions you > do not have AESNI acceleration but by using the EVP interfance you > do. Thing is that the AES_, DES_ etc. functions have long been a key part ofSSLeay/OpenSSL. Notably, the DES library had previously been distributedseparately, and the large integer library is a key componentfor people implementing new new crypto algorithms and methodsnot yet (or ever) in OpenSSL. And unlike higher level mechanisms, they tend not to bloat statically linkedapplications with lots unused code.(Though the use of EVP insidethe RNG forced me to do some patching to avoid pulling in the EVP RSA code). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jan 7 09:26:33 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 07 Jan 2015 10:26:33 +0100 Subject: [openssl-users] OpenSSL Release Strategy and Blog In-Reply-To: <54A0A239.8080304@openssl.org> References: <5499FF9F.6040205@openssl.org> <549F4F6A.9010507@wisemo.com> <54A0A239.8080304@openssl.org> Message-ID: <54ACFBC9.20002@wisemo.com> On 29/12/2014 01:37, Matt Caswell wrote: > On 28/12/14 00:31, Jakob Bohm wrote: >> On 24-12-2014 00:49, Matt Caswell wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement >>> contained a link to the recently published OpenSSL Release Strategy that >>> is available here: >>> https://www.openssl.org/about/releasestrat.html >>> >>> I have put up a blog post on the thinking behind this strategy on the >>> newly created OpenSSL Blog that you may (or may not!) find interesting. >>> It can be found here: >>> https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ >> I am afraid that this is a somewhat rush decision, with insufficient >> consideration for the impact on others: > Not at all. This decision has been under consideration for some > considerable period of time with much discussion of the impacts. Discussing this only amongst yourselves has probably blinded you to the needs ofoutsiders, leading to a bad decision. But since your minds are made mostly up, let me rephrase the key communityneeds as I see them: 1. The ability, at any given day, to know which of the currently available OpenSSLreleases is going to receive back-portable security patches with binary compatibilityfor at least 3 to 5 years into the future from that day. A given community member (such as a Linux distro or a closed source product) will use this on one of the daysnear the end of their development cycle, after which they will intend to provideonly small drop in patches (shared libraries, small programs, binary diffs) for the lifetime of their "product". 2. The ability to use libcrypt as the basis for non-SSL code, such as OpenSSH or theSRP reference impementation (you should coordinate changes in low level APIswith at least those two teams). Also there is the need to use subsets of libcryptwithout the rest, e.g. in bootloaders or kernels (I don't know if any of the kernel crypto in Linux or BSD uses OpenSSL code). And then there is all the fun securityresearchers are having with the code. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From postmaster at openssl.org Thu Jan 8 05:13:12 2015 From: postmaster at openssl.org (Mail Administrator) Date: Thu, 8 Jan 2015 13:13:12 +0800 Subject: [openssl-users] *****SPAM***** Message-ID: <20150108051328.B8D5A20672@mta.openssl.org> Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: The original message was received at Thu, 8 Jan 2015 13:13:12 +0800 from openssl.org [172.56.10.220] ----- The following addresses had permanent fatal errors ----- [...] Content analysis details: (16.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openssl.org] 1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available. [123.168.9.34 listed in bb.barracudacentral.org] 0.8 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [123.168.9.34 listed in dnsbl.sorbs.net] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5133] 2.4 RCVD_IN_MSPIKE_L5 RBL: Very bad reputation (-5) [123.168.9.34 listed in bl.mailspike.net] 0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Mail Administrator" Subject: Date: Thu, 8 Jan 2015 13:13:12 +0800 Size: 31101 URL: From jennifer_sh at openssl.org Thu Jan 8 16:27:57 2015 From: jennifer_sh at openssl.org (jennifer_sh at openssl.org) Date: Tue, 8 Jan 2015 17:27:57 +0100 Subject: [openssl-users] *****SPAM***** My Best Photo Message-ID: <20150108132814.461E3206BB@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi, I want to share my photo with you. Wishing you all the best. Regards, [...] Content analysis details: (9.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 0.9999] 0.0 FSL_HELO_NON_FQDN_1 No description available. 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 1.0 MISSING_FROM Missing From: header 0.5 MISSING_MID Missing Message-Id: header 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: My Best Photo Date: Tue, 8 Jan 2015 17:27:57 +0100 Size: 6280 URL: From openssl at openssl.org Thu Jan 8 15:37:53 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:37:53 +0100 Subject: [openssl-users] OpenSSL version 0.9.8zd released Message-ID: <20150108153753.GA29145@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 0.9.8zd released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8zd of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-0.9.8-notes.html OpenSSL 0.9.8zd is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8zd.tar.gz Size: 3737538 MD5 checksum: e9b9ee12f2911e1a378e2458d9bfff77 SHA1 checksum: b9a6356d5385e0bd6b8af660576bfdef7b45666e The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zd.tar.gz openssl sha1 openssl-0.9.8zd.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUrpVNAAoJENnE0m0OYESRDe0H/3AKK345ct3rR0QEQ1YN6d33 T4upEE2CKGaDhhqfPl0iHPDVxec+st98JxF3Yg5wQxWO7DxMe5bbKCYl/hM0ZSQd zTzeECDH5WtzlyXTCp5TZdLMwpPL3kkW0Q7D4q/RXZ6DE3fNVLDsxJOiVa4cWtHL JnuJCCqwSC5a5CfhcyAu5Tqt2/0xoFxcai8NmmhIWe806pfrwsN9PoD0YW9ARlLC hySrcCLy4MHtZYie4dv7JIOtVb1PPyX6qNsoKriGdpwb+drPvRtQFxSkbif+2gkf Y7YkDs8nKCdLwJvgonprl6HgcHh4eeBNpxOgfwMo/Vnw02HZvm7na2t4jxvmm+E= =+Z6j -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 8 15:38:58 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:38:58 +0100 Subject: [openssl-users] OpenSSL version 1.0.0p released Message-ID: <20150108153858.GA29225@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.0p released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0p of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.0-notes.html OpenSSL 1.0.0p is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.0p.tar.gz Size: 4008663 MD5 checksum: f66da50ff3624aeaf292948f27d8ae7d SHA1 checksum: 04dd495c47c7a11f7f311747121b6b77e08abb5b The checksums were calculated using the following commands: openssl md5 openssl-1.0.0p.tar.gz openssl sha1 openssl-1.0.0p.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUrpJ5AAoJENnE0m0OYESRXL4IAJ66ZB4N5/nhxPCYV0vGMjCE A6jBTMPNfcF+CX26rFr3nWTX85zvmAFW9r+nIddlvnLSsWtDKtOpZsyWiFzFSrtK gp7xPhI3B//Di1bkDk0zkhUcAT/7DU/8yp8Nm5J0XMu71H+3Uxh/QP6ZpyW1ZSJ7 eWeZGr+PoVaC0gcRR2HBPtaArL0fhbgGI7HggRslvNupiwBqJ42Z0wDY12ONaA38 Be6jiUBElRQqr5VmjPOSdezX0ZTErI7NZ5It1DCtsLuglbVsmrim57PSpOkWwVh0 FRi39qNR7T4/2SEcUN01EX7VENarqZaxIxJuYCIx6v8DXYQQ8NloUudBe6icmE8= =9lIN -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 8 15:39:33 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:39:33 +0100 Subject: [openssl-users] OpenSSL version 1.0.1k released Message-ID: <20150108153933.GA29291@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1k released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1k of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1k is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1k.tar.gz Size: 4434910 MD5 checksum: d4f002bd22a56881340105028842ae1f SHA1 checksum: 19d818e202558c212a9583fcdaf876995a633ddf The checksums were calculated using the following commands: openssl md5 openssl-1.0.1k.tar.gz openssl sha1 openssl-1.0.1k.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUro4+AAoJENnE0m0OYESRxuQH/2TFznmtvL92IMO6rjeCClYM bBqxvIaVs/l7sflcsENo67HNCn0/RmblmfULVY96Pvoin7z19wMyEFL+3NSM1w8v HkX2mRz23V8PEDxn23f3i1ltCCZgc+aQyKoOf6Rbo4WHxgIHKXdKqm8dhyVj6ODw s2Go3TvaUNtG1BoW6AJtr1ZHosq+WKaOjq5yiRdFb1o/00GipSOb6gRsT2qJHEXS NpFEJm1CRguJ7qe3SPgu7gGyQ34MVl9jO1onRlMqsE4anvZBtm5sK97YXRrc4fqK 0E/SO1sW+mz359fHJMYmYnefG0hs1+KNnA1ydEfLLrf1Bc8Lqft37rN0cVfKdzg= =oLV9 -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 8 15:44:33 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:44:33 +0100 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20150108154433.GA30257@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [08 Jan 2015] ======================================= DTLS segmentation fault in dtls1_get_record (CVE-2014-3571) =========================================================== Severity: Moderate A carefully crafted DTLS message can cause a segmentation fault in OpenSSL due to a NULL pointer dereference. This could lead to a Denial Of Service attack. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Markus Stenberg of Cisco Systems, Inc. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS memory leak in dtls1_buffer_record (CVE-2015-0206) ======================================================= Severity: Moderate A memory leak can occur in the dtls1_buffer_record function under certain conditions. In particular this could occur if an attacker sent repeated DTLS records with the same sequence number but for the next epoch. The memory leak could be exploited by an attacker in a Denial of Service attack through memory exhaustion. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 7th January 2015 by Chris Mueller who also provided an initial patch. Further analysis was performed by Matt Caswell of the OpenSSL development team, who also developed the final patch. no-ssl3 configuration sets method to NULL (CVE-2014-3569) ========================================================= Severity: Low When openssl is built with the no-ssl3 option and a SSL v3 ClientHello is received the ssl method would be set to NULL which could later result in a NULL pointer dereference. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 17th October 2014 by Frank Schmirler. The fix was developed by Kurt Roeckx. ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572) ========================================================== Severity: Low An OpenSSL client will accept a handshake using an ephemeral ECDH ciphersuite using an ECDSA certificate if the server key exchange message is omitted. This effectively removes forward secrecy from the ciphersuite. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) ============================================================== Severity: Low An OpenSSL client will accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. DH client certificates accepted without verification [Server] (CVE-2015-0205) ============================================================================= Severity: Low An OpenSSL server will accept a DH certificate for client authentication without the certificate verify message. This effectively allows a client to authenticate without the use of a private key. This only affects servers which trust a client certificate authority which issues certificates containing DH keys: these are extremely rare and hardly ever encountered. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. Certificate fingerprints can be modified (CVE-2014-8275) ======================================================== Severity: Low OpenSSL accepts several non-DER-variations of certificate signature algorithm and signature encodings. OpenSSL also does not enforce a match between the signature algorithm between the signed and unsigned portions of the certificate. By modifying the contents of the signature algorithm or the encoding of the signature, it is possible to change the certificate's fingerprint. This does not allow an attacker to forge certificates, and does not affect certificate verification or OpenSSL servers/clients in any other way. It also does not affect common revocation mechanisms. Only custom applications that rely on the uniqueness of the fingerprint (e.g. certificate blacklists) may be affected. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. One variant of this issue was discovered by Antti Karjalainen and Tuomo Untinen from the Codenomicon CROSS program and reported to OpenSSL on 1st December 2014 by NCSC-FI Vulnerability Co-ordination. Another variant was independently reported to OpenSSL on 12th December 2014 by Konrad Kraszewski from Google. Further analysis was conducted and fixes were developed by Stephen Henson of the OpenSSL core team. Bignum squaring may produce incorrect results (CVE-2014-3570) ============================================================= Severity: Low Bignum squaring (BN_sqr) may produce incorrect results on some platforms, including x86_64. This bug occurs at random with a very low probability, and is not known to be exploitable in any way, though its exact impact is difficult to determine. The following has been determined: *) The probability of BN_sqr producing an incorrect result at random is very low: 1/2^64 on the single affected 32-bit platform (MIPS) and 1/2^128 on affected 64-bit platforms. *) On most platforms, RSA follows a different code path and RSA operations are not affected at all. For the remaining platforms (e.g. OpenSSL built without assembly support), pre-existing countermeasures thwart bug attacks [1]. *) Static ECDH is theoretically affected: it is possible to construct elliptic curve points that would falsely appear to be on the given curve. However, there is no known computationally feasible way to construct such points with low order, and so the security of static ECDH private keys is believed to be unaffected. *) Other routines known to be theoretically affected are modular exponentiation, primality testing, DSA, RSA blinding, JPAKE and SRP. No exploits are known and straightforward bug attacks fail - either the attacker cannot control when the bug triggers, or no private key material is involved. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 2nd November 2014 by Pieter Wuille (Blockstream) who also suggested an initial fix. Further analysis was conducted by the OpenSSL development team and Adam Langley of Google. The final fix was developed by Andy Polyakov of the OpenSSL core team. [1] http://css.csail.mit.edu/6.858/2013/readings/rsa-bug-attacks.pdf Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv_20150108.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUrpY9AAoJENnE0m0OYESReyMH/1e6o6yRRKVKUUV7wvkoGreO rqdvmG0dRmtPFKvuWlDO6+6nLtBorj5B/Ebqkd+oPfQhZ9is2xyrCIRT1jwqiHPA w35fwEWMD8P1Fpq/hqBVE4QF3zSflS13GIuOBc1Q8dR7JO9TN+xXYy3TkLXzyDOR jSRtqUq2QaHevlpZU2e9olErpQX9mvcOd31JHs8aFyt/hbWsxiY1EUbU7CUfKC5L 4BicWJl4v/OKsy3Ctxx0ajtYE7bbPCElWDwzHaI+FF5pnC6MlI9fUy97fELmniEy tIIxgH9YK0YAnDBoHEH3w5NZtI1qgrhRIasuk9sS7J5ILTB44X9hgQDqnZUVMfA= =7bjl -----END PGP SIGNATURE----- From weber at infotech.de Thu Jan 8 17:16:08 2015 From: weber at infotech.de (Christian Weber) Date: Thu, 08 Jan 2015 18:16:08 +0100 Subject: [openssl-users] What does EC_KEY_get0_public_key deliver? Message-ID: <54AEBB58.8060306@infotech.de> Dear OpenSSL-Users, recently i found a pitfall using EC_KEY_get0_public_key(key->pkey.ec). The function just returns a copy to a pointer to key->pub_key which is a EC_POINT pointer. The key itself is taken from a certificate using EVP_PKEY *key = X509_get_pubkey(cert); Fine, i assumed, these must be coordinates of the publich key in the elements X and Y! Both are BIGNUMS as expected. BUT instead i got some tranformed coordinates. Finally i got the coordinates by using EC_POINT_point2hex() with the propoer group and converting its output. There seems to be no instantly accessible BIGNUM-pair represesentation of a ECDSA public key, which i would like to gain access to. What am i missing? Thanks in advance -- Chris From graeme.perrow at sap.com Thu Jan 8 18:54:55 2015 From: graeme.perrow at sap.com (Perrow, Graeme) Date: Thu, 8 Jan 2015 18:54:55 +0000 Subject: [openssl-users] Build failure in 1.0.1k on Windows Message-ID: <6378BFFB8601BD438AD9AF3CA610548E56CA8F30@DEWDFEMB16B.global.corp.sap> I just downloaded 1.0.1k and when trying to build it on Windows (using Visual Studio 10.0), I get a compile error: .\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier .\crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in levels of indirection from 'int' The problem is this block in cversion.c: if (t == SSLEAY_CFLAGS) { #ifdef CFLAGS return(cflags); #else return("compiler: information not available"); #endif } There is no "cflags" variable anywhere. I suspect this should be "return (CFLAGS);", and making this change to the source does make the compile succeed. I'm not sure how it compiles as-is on Linux but it does. Graeme Perrow -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jan 8 21:43:15 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 08 Jan 2015 21:43:15 +0000 Subject: [openssl-users] What does EC_KEY_get0_public_key deliver? In-Reply-To: <54AEBB58.8060306@infotech.de> References: <54AEBB58.8060306@infotech.de> Message-ID: <54AEF9F3.9060604@openssl.org> On 08/01/15 17:16, Christian Weber wrote: > Dear OpenSSL-Users, > > recently i found a pitfall using EC_KEY_get0_public_key(key->pkey.ec). > The function just returns a copy to a pointer to key->pub_key which is a > EC_POINT pointer. > The key itself is taken from a certificate using EVP_PKEY *key = > X509_get_pubkey(cert); > > Fine, i assumed, these must be coordinates of the publich key in the > elements X and Y! > Both are BIGNUMS as expected. How are you accessing the elements X and Y? The internal representation could be transformed and you should make sure you are using the correct functions to access them, i.e. one of: EC_POINT_get_affine_coordinates_GFp or EC_POINT_get_affine_coordinates_GF2m Which one to use depends on whether you are using a prime or binary curve. Matt From matt at openssl.org Thu Jan 8 21:50:42 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 08 Jan 2015 21:50:42 +0000 Subject: [openssl-users] openssl-1.0.1k - undeclared identifier In-Reply-To: References: Message-ID: <54AEFBB2.1040101@openssl.org> On 08/01/15 18:19, Guy wrote: > Hello, > > I try to buld openssl-1.0.1k with Visual Studio... > > PERL Configure VC-WIN32... > ms\do_nasm > NMAKE -f ms\ntdll.mak > > and have one error: > > .\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier > This is a known issue with the Windows build and there is a patch in git already. See commit 56cd7404 Matt From layer at franz.com Thu Jan 8 20:47:51 2015 From: layer at franz.com (Kevin Layer) Date: Thu, 08 Jan 2015 12:47:51 -0800 Subject: [openssl-users] OpenSSL version 1.0.1k released In-Reply-To: <20150108153933.GA29291@openssl.org> References: <20150108153933.GA29291@openssl.org> Message-ID: <20040.1420750071@franz.com> Anyone having trouble building on Windows? cl /Fotmp32dll\cversion.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -DMK1MF_BUILD -DMK1MF_PLATFORM_VC_WIN32 -c .\crypto\cversion.c cversion.c .\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier .\crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in levels of indirection from 'int ' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. This is on Windows Server 2008 with Windows Server 2003 R2 Platform SDK and Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Yes, I realize that it's an old compiler, but 1.0.1j built fine with it. From layer at franz.com Thu Jan 8 21:12:35 2015 From: layer at franz.com (Kevin Layer) Date: Thu, 08 Jan 2015 13:12:35 -0800 Subject: [openssl-users] OpenSSL version 1.0.1k released In-Reply-To: <20150108153933.GA29291@openssl.org> References: <20150108153933.GA29291@openssl.org> Message-ID: <21952.1420751555@franz.com> With a more modern 64-bit MS compiler, I still get a failure. I see that Cygwin released theirs, so I'm guessing this is a MS compiler issue. cl /Fotmp32dll\cversion.obj -Iinc32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -DMK1MF_BUILD -DMK1MF_PLATFORM_VC_WIN64A -c .\crypto\cversion.c cversion.c crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in levels of indirection from 'int' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64 and the same Microsoft Platform SDK for Windows Server 2003 R2. Help? Thanks. From scott_n at xypro.com Thu Jan 8 22:35:34 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 8 Jan 2015 22:35:34 +0000 Subject: [openssl-users] OpenSSL version 1.0.1k released In-Reply-To: <21952.1420751555@franz.com> References: <20150108153933.GA29291@openssl.org> <21952.1420751555@franz.com> Message-ID: The C4047 is just a warning. The C2065 is a known issue, per Matt. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kevin Layer Sent: Thursday, January 08, 2015 1:13 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL version 1.0.1k released With a more modern 64-bit MS compiler, I still get a failure. I see that Cygwin released theirs, so I'm guessing this is a MS compiler issue. cl /Fotmp32dll\cversion.obj -Iinc32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -DMK1MF_BUILD -DMK1MF_PLATFORM_VC_WIN64A -c .\crypto\cversion.c cversion.c crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in levels of indirection from 'int' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64 and the same Microsoft Platform SDK for Windows Server 2003 R2. Help? Thanks. _______________________________________________ openssl-users mailing list openssl-users at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-users From gvanem at yahoo.no Thu Jan 8 22:51:08 2015 From: gvanem at yahoo.no (Gisle Vanem) Date: Thu, 08 Jan 2015 22:51:08 +0000 Subject: [openssl-users] [Bulk] Build failure in 1.0.1k on Windows In-Reply-To: <6378BFFB8601BD438AD9AF3CA610548E56CA8F30@DEWDFEMB16B.global.corp.sap> References: <6378BFFB8601BD438AD9AF3CA610548E56CA8F30@DEWDFEMB16B.global.corp.sap> Message-ID: <54AF09DC.6000306@yahoo.no> Perrow, Graeme wrote: > I just downloaded 1.0.1k and when trying to build it on Windows (using Visual Studio 10.0), I get a compile error: > > .\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier > > .\crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in levels of indirection from 'int' (you should avoid such long lines). 'cflags' should be automatically generated by the util/mkbuildinf.pl script and included via crypto/buildinf.h (which is included in cversion.c). It's a total mess. Here, crypto/buildinf*.h looks like: #ifndef MK1MF_BUILD /* auto-generated by util/mkbuildinf.pl for crypto/cversion.c */ #define CFLAGS /* * Generate CFLAGS as an array of individual characters. This is a * workaround for the situation where CFLAGS gets too long for a C90 string * literal */ static const char cflags[] = { 'c','o','m','p','i','l','e','r',':',' ',' ','"','-','D','O','P','E','N', 'S','S','L','_','S','Y','S','N','A','M','E','_','W','I','N','3','2',' ', '-','D','_','W','I','N','3','2',' ','-','D','W','I','N','N','T',' ','-', 'D','D','S','O','_','W','I','N','3','2',' ','-','D','O','P','E','N','S', -------- Nice and readable, no? -- --gv From weber at infotech.de Fri Jan 9 00:05:29 2015 From: weber at infotech.de (Christian Weber) Date: Fri, 9 Jan 2015 01:05:29 +0100 Subject: [openssl-users] What does EC_KEY_get0_public_key deliver? In-Reply-To: <54AEF9F3.9060604@openssl.org> References: <54AEBB58.8060306@infotech.de> <54AEF9F3.9060604@openssl.org> Message-ID: Thanks Matt, i just assumed the BIGNUMs were the coordinates without any projection - obviously that assumption was wrong - mislead by the funtions name. However, we're operating on brainpool curves, so the latter function should do the job. I'll lookup the parameters and try tomorrow. MfG -- Chris Am 08.01.2015 um 22:43 schrieb Matt Caswell : > > > On 08/01/15 17:16, Christian Weber wrote: >> Dear OpenSSL-Users, >> >> recently i found a pitfall using EC_KEY_get0_public_key(key->pkey.ec). >> The function just returns a copy to a pointer to key->pub_key which is a >> EC_POINT pointer. >> The key itself is taken from a certificate using EVP_PKEY *key = >> X509_get_pubkey(cert); >> >> Fine, i assumed, these must be coordinates of the publich key in the >> elements X and Y! >> Both are BIGNUMS as expected. > > How are you accessing the elements X and Y? The internal representation > could be transformed and you should make sure you are using the correct > functions to access them, i.e. one of: > > EC_POINT_get_affine_coordinates_GFp > or > EC_POINT_get_affine_coordinates_GF2m > > Which one to use depends on whether you are using a prime or binary curve. > > Matt > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Fri Jan 9 00:11:11 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 09 Jan 2015 00:11:11 +0000 Subject: [openssl-users] What does EC_KEY_get0_public_key deliver? In-Reply-To: References: <54AEBB58.8060306@infotech.de> <54AEF9F3.9060604@openssl.org> Message-ID: <54AF1C9F.3080502@openssl.org> On 09/01/15 00:05, Christian Weber wrote: > Thanks Matt, i just assumed the BIGNUMs were the coordinates without any projection - obviously that assumption was wrong - mislead by the funtions name. > What interests me is to how you accessed the BIGNUMs in the first place! The EC_POINT structure is opaque and is defined in an internal header file!! Applications shouldn't be reaching into those. Matt From oyljerry at gmail.com Fri Jan 9 02:45:54 2015 From: oyljerry at gmail.com (Jerry OELoo) Date: Fri, 9 Jan 2015 10:45:54 +0800 Subject: [openssl-users] How to construct certificate chain when missing intermediate CA Message-ID: Hi All: I am using X509_STORE_CTX_get1_chain() to get web site's full certificate chain. Now I am encounter an issue that some web site does not return intermediate CA certificate but only web site leaf certificate. For example. https://globaltrade.usbank.com Below is certificate I get. Subject: /C=US/ST=Minnesota/L=St. Paul/O=U.S. Bank/OU=ISS/CN=globaltrade.usbank.com Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 As my environment missing "VeriSign Class 3 Secure Server CA - G3" certificate. When open web site in Browsers (Chrome on windows), I can see certificate chain is built successfully, I think this is because browser should recognize "VeriSign Class 3 Secure Server CA - G3" this intermediate CA, and automatically installed crt into system. So my question is how can I achieve same as browsers with openssl, with openssl I can get error info. But where can I use program to download VeriSign G3 certificate and installed automatically, then I can build full certificate chain. Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S. Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[20] Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S. Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[27] Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S. Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[21] -- Rejoice,I Desire! From dongsheng.song at gmail.com Fri Jan 9 03:32:30 2015 From: dongsheng.song at gmail.com (Dongsheng Song) Date: Fri, 9 Jan 2015 11:32:30 +0800 Subject: [openssl-users] [openssl-announce] OpenSSL version 1.0.1k released In-Reply-To: <20150108153933.GA29291@openssl.org> References: <20150108153933.GA29291@openssl.org> Message-ID: test failure on custom build: perl Configure ^ no-comp no-dso no-idea no-ssl2 no-ssl3 no-psk no-srp ^ --prefix=D:/var/pool/openssl-win32 ^ VC-WIN32 ... D:\var\tmp\openssl-1.0.1k>nmake -f ms\ntdll.mak ... D:\var\tmp\openssl-1.0.1k>nmake -f ms\nt.mak test Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 Copyright (C) Microsoft Corporation. All rights reserved. cd out32 ..\ms\test rsa_test PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok destest Doing cbcm Doing ecb Doing ede ecb Doing cbc Doing desx cbc Doing ede cbc Doing pcbc Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done Doing ofb Doing ofb64 Doing ede_ofb64 Doing cbc_cksum Doing quad_cksum input word alignment test 0 1 2 3 output word alignment test 0 1 2 3 fast crypt test ideatest 'ideatest' is not recognized as an internal or external command, operable program or batch file. problems..... On Thu, Jan 8, 2015 at 11:39 PM, OpenSSL wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > OpenSSL version 1.0.1k released > =============================== > > OpenSSL - The Open Source toolkit for SSL/TLS > http://www.openssl.org/ > > The OpenSSL project team is pleased to announce the release of > version 1.0.1k of our open source toolkit for SSL/TLS. For details > of changes and known issues see the release notes at: > > http://www.openssl.org/news/openssl-1.0.1-notes.html > > OpenSSL 1.0.1k is available for download via HTTP and FTP from the > following master locations (you can find the various FTP mirrors under > http://www.openssl.org/source/mirror.html): > > * http://www.openssl.org/source/ > * ftp://ftp.openssl.org/source/ > > The distribution file name is: > > o openssl-1.0.1k.tar.gz > Size: 4434910 > MD5 checksum: d4f002bd22a56881340105028842ae1f > SHA1 checksum: 19d818e202558c212a9583fcdaf876995a633ddf > > The checksums were calculated using the following commands: > > openssl md5 openssl-1.0.1k.tar.gz > openssl sha1 openssl-1.0.1k.tar.gz > > Yours, > > The OpenSSL Project Team. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUro4+AAoJENnE0m0OYESRxuQH/2TFznmtvL92IMO6rjeCClYM > bBqxvIaVs/l7sflcsENo67HNCn0/RmblmfULVY96Pvoin7z19wMyEFL+3NSM1w8v > HkX2mRz23V8PEDxn23f3i1ltCCZgc+aQyKoOf6Rbo4WHxgIHKXdKqm8dhyVj6ODw > s2Go3TvaUNtG1BoW6AJtr1ZHosq+WKaOjq5yiRdFb1o/00GipSOb6gRsT2qJHEXS > NpFEJm1CRguJ7qe3SPgu7gGyQ34MVl9jO1onRlMqsE4anvZBtm5sK97YXRrc4fqK > 0E/SO1sW+mz359fHJMYmYnefG0hs1+KNnA1ydEfLLrf1Bc8Lqft37rN0cVfKdzg= > =oLV9 > -----END PGP SIGNATURE----- > _______________________________________________ > openssl-announce mailing list > openssl-announce at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-announce From weber at infotech.de Fri Jan 9 10:55:46 2015 From: weber at infotech.de (Christian Weber) Date: Fri, 09 Jan 2015 11:55:46 +0100 Subject: [openssl-users] What does EC_KEY_get0_public_key deliver? In-Reply-To: <54AF1C9F.3080502@openssl.org> References: <54AEBB58.8060306@infotech.de> <54AEF9F3.9060604@openssl.org> <54AF1C9F.3080502@openssl.org> Message-ID: <54AFB3B2.8080802@infotech.de> Am 09.01.2015 um 01:11 schrieb Matt Caswell: On 09/01/15 00:05, Christian Weber wrote: >> Thanks Matt, i just assumed the BIGNUMs were the coordinates without any projection - obviously that assumption was wrong - mislead by the funtions name. >> > What interests me is to how you accessed the BIGNUMs in the first place! > The EC_POINT structure is opaque and is defined in an internal header > file!! Applications shouldn't be reaching into those. > > Matt Actually i imported the internal header so the structure was known. I marked the import as HACK to access exactly that EC_POINT structure. The hack was carried out because of the lack of knowledge about how to access the public key. I yust did not understand the intention for hiding the EC_POINT structure and didn't find information about how to access the coordinate values which i need to compare with coordinates from other sources (XML Dsig, Element ) or placing them elsewhere. So could you please give a hint or a pointer to where the intended access can be found? BTW: How does one find out which type of ECC is being used (binary or prime)? BTW2: Which compact representation of any public key would you recommend (for program internal comparisons)? Surely i will ban the internal header from my sources as they are not neccessary. Chris From matt at openssl.org Fri Jan 9 11:06:11 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 09 Jan 2015 11:06:11 +0000 Subject: [openssl-users] What does EC_KEY_get0_public_key deliver? In-Reply-To: <54AFB3B2.8080802@infotech.de> References: <54AEBB58.8060306@infotech.de> <54AEF9F3.9060604@openssl.org> <54AF1C9F.3080502@openssl.org> <54AFB3B2.8080802@infotech.de> Message-ID: <54AFB623.90401@openssl.org> On 09/01/15 10:55, Christian Weber wrote: > Am 09.01.2015 um 01:11 schrieb Matt Caswell: On 09/01/15 00:05, > Christian Weber wrote: >>> Thanks Matt, i just assumed the BIGNUMs were the coordinates without >>> any projection - obviously that assumption was wrong - mislead by the >>> funtions name. >>> >> What interests me is to how you accessed the BIGNUMs in the first place! >> The EC_POINT structure is opaque and is defined in an internal header >> file!! Applications shouldn't be reaching into those. >> >> Matt > Actually i imported the internal header so the structure was known. I > marked the import as HACK to access exactly that EC_POINT structure. The > hack was carried out because of the lack of knowledge about how to > access the public key. > > I yust did not understand the intention for hiding the EC_POINT > structure and didn't find information about how to access the coordinate > values which i need to compare with coordinates from other sources (XML > Dsig, Element ) or placing them elsewhere. > > So could you please give a hint or a pointer to where the intended > access can be found? All access is via the EC_POINT_* functions which are described here: https://www.openssl.org/docs/crypto/EC_POINT_new.html and here: https://www.openssl.org/docs/crypto/EC_POINT_add.html > > BTW: How does one find out which type of ECC is being used (binary or > prime)? Use the function EC_METHOD_get_field_type described here: https://www.openssl.org/docs/crypto/EC_GFp_simple_method.html > BTW2: Which compact representation of any public key would you recommend > (for program internal comparisons)? I wouldn't worry about the internal representation at all. If you have the co-ordinates of a point you want to compare against then construct the point using EC_POINT_new, and set its co-ords using one of the various functions for doing so. Then use EC_POINT_cmp. > > Surely i will ban the internal header from my sources as they are not > neccessary. Please do! They are internal for a reason, and may change without notice. Matt From jb-openssl at wisemo.com Fri Jan 9 12:30:25 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 09 Jan 2015 13:30:25 +0100 Subject: [openssl-users] How to construct certificate chain when missing intermediate CA In-Reply-To: References: Message-ID: <54AFC9E1.8050607@wisemo.com> On 09/01/2015 03:45, Jerry OELoo wrote: > Hi All: > I am using X509_STORE_CTX_get1_chain() to get web site's full certificate chain. > Now I am encounter an issue that some web site does not return > intermediate CA certificate but only web site leaf certificate. > > For example. https://globaltrade.usbank.com > > Below is certificate I get. > > Subject: /C=US/ST=Minnesota/L=St. Paul/O=U.S. > Bank/OU=ISS/CN=globaltrade.usbank.com > Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of > use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure > Server CA - G3 > > As my environment missing "VeriSign Class 3 Secure Server CA - G3" certificate. > > When open web site in Browsers (Chrome on windows), I can see > certificate chain is built successfully, I think this is because > browser should recognize "VeriSign Class 3 Secure Server CA - G3" this > intermediate CA, and automatically installed crt into system. > > So my question is how can I achieve same as browsers with openssl, > with openssl I can get error info. But where can I use program to > download VeriSign G3 certificate and installed automatically, then I > can build full certificate chain. > > Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S. > Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[20] > Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S. > Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[27] > Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S. > Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[21] > > The trick is that many (not all) certificates now include an "AuthorityInformation Access" (AIA) extension which (optionally) gives a download URL for the next certificate in the chain in case the browser does not have a local copy. This is the same extension which also (in another optional field) provides the URL of an OCSP revocation checking server. So in some clients (at least Internet Explorer 9+), the procedure for each certificate is: 1. Using the full Issuer DN (which is a complex ASN.1 structure), put them in the same form (already done because that part of the certificate has to be in the strict DER format), then do a binary compare for identity against the full Subject DN in all the certificates received from the other end. 2. If this fails, do the same against all the certificates in your local catalog of trusted root CAs. 3. If this fails, do the same against all the certificates in your local catalog of known Intermediary CAs. 4. If this fails, do the same against all the certificates in your local cache of previously downloaded certificates. 5. If this fails, look for an AIA extension in the cert and check if that extension includes a certificate download URL, then download from that URL to an in memory variable. If the validation ultimately succeeds, save that downloaded certificate from memory to your local cache. OpenSSL 1.0.1 and older include functions to do steps 1 (if the other end sent the certificates in the order needed) and 2. That code may be coerced into doing steps 3 and 4 by putting the intermediary certificates into the root store and checking if a certificate is self-signed to decide if it is trusted or just a potentially unverified intermediary. OpenSSL 1.0.2 beta apparently includes better code for most of these steps than 1.0.1. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Fri Jan 9 12:38:13 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 09 Jan 2015 13:38:13 +0100 Subject: [openssl-users] [openssl-announce] OpenSSL version 1.0.1k released In-Reply-To: References: <20150108153933.GA29291@openssl.org> Message-ID: <54AFCBB5.8060200@wisemo.com> On 09/01/2015 04:32, Dongsheng Song wrote: > test failure on custom build: > > perl Configure ^ > no-comp no-dso no-idea no-ssl2 no-ssl3 no-psk no-srp ^ > --prefix=D:/var/pool/openssl-win32 ^ > VC-WIN32 > ... > > D:\var\tmp\openssl-1.0.1k>nmake -f ms\ntdll.mak > ... > > D:\var\tmp\openssl-1.0.1k>nmake -f ms\nt.mak test > > Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > cd out32 > ..\ms\test > rsa_test > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > destest > Doing cbcm > Doing ecb > Doing ede ecb > Doing cbc > Doing desx cbc > Doing ede cbc > Doing pcbc > Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done > Doing ofb > Doing ofb64 > Doing ede_ofb64 > Doing cbc_cksum > Doing quad_cksum > input word alignment test 0 1 2 3 > output word alignment test 0 1 2 3 > fast crypt test > ideatest > 'ideatest' is not recognized as an internal or external command, > operable program or batch file. > problems..... I guess it then has no idea what that test is (hint, hint). The Windows build scripts (unlike the POSIX build scripts) are not completelyadapted to the configured build options, and thus include tests for featuresyou have decided not to build. This is because the syntax differences between POSIX make and Microsoft nmake are too big to automatically do a complete translation inside the Configure.pl script. So the script cheats and reads out the primary lists of files to compile and thenjust outputs simplistic nmake makefiles (such as nt.mak and ntdll.mak) based on those lists. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From engineermike at mindspring.com Fri Jan 9 16:36:49 2015 From: engineermike at mindspring.com (engineermike) Date: Fri, 9 Jan 2015 11:36:49 -0500 Subject: [openssl-users] How to leave the list Message-ID: <03dc01d02c2a$772f46e0$658dd4a0$@mindspring.com> My apologies to the group for the interruption but can someone please tell me how to get off these lists? I have made several attempts and they all come back with the same failed results. I would simply like to be removed from all the lists since I am no longer involved in this area of work. Thank you in advance. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjl at viptalk.net Fri Jan 9 16:40:50 2015 From: cjl at viptalk.net (Chris L) Date: Fri, 9 Jan 2015 08:40:50 -0800 Subject: [openssl-users] How to leave the list In-Reply-To: <03dc01d02c2a$772f46e0$658dd4a0$@mindspring.com> References: <03dc01d02c2a$772f46e0$658dd4a0$@mindspring.com> Message-ID: <8F84D38C-C821-48E3-8D53-0CAB68F295EE@viptalk.net> lulz. mta.openssl.org?s cert is expired. > On Jan 9, 2015, at 8:36 AM, engineermike wrote: > > My apologies to the group for the interruption but can someone please tell me how to get off these lists? I have made several attempts and they all come back with the same failed results. I would simply like to be removed from all the lists since I am no longer involved in this area of work. > Thank you in advance. > Mike > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Fri Jan 9 16:41:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 9 Jan 2015 11:41:59 -0500 Subject: [openssl-users] How to leave the list In-Reply-To: <03dc01d02c2a$772f46e0$658dd4a0$@mindspring.com> References: <03dc01d02c2a$772f46e0$658dd4a0$@mindspring.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675C7D@USMBX1.msg.corp.akamai.com> https://mta.openssl.org (we're replacing the certificates) click on the list(s) and then near the bottom of the page is an unsubscribe button. But I removed you directly so this is for the benefit of everyone else:) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jan 9 16:46:39 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 9 Jan 2015 11:46:39 -0500 Subject: [openssl-users] How to leave the list In-Reply-To: <8F84D38C-C821-48E3-8D53-0CAB68F295EE@viptalk.net> References: <03dc01d02c2a$772f46e0$658dd4a0$@mindspring.com> <8F84D38C-C821-48E3-8D53-0CAB68F295EE@viptalk.net> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675C86@USMBX1.msg.corp.akamai.com> > lulz. mta.openssl.org?s cert is expired. No, it's the wrong domain name. We're working on fixing it. From amiralex32 at gmail.com Fri Jan 9 19:42:30 2015 From: amiralex32 at gmail.com (Amir Reda) Date: Fri, 9 Jan 2015 21:42:30 +0200 Subject: [openssl-users] GCM Message-ID: dear all i'm trying to use AES-GCM model for encryption i use a sample code for that and my problem is ret = EVP_DecryptFinal_ex(ctx, plaintext + len, &len); ret all the time is 0 this means that the plaintext is not trustworthy. encryption function int Server::AuthenticationEncryption(unsigned char plaintext[], int ptextsize, unsigned char aad[], int aadlen, unsigned char key[],int keysize, unsigned char iv[],int ivsize, unsigned char ciphertext[], unsigned char tag[]) { int len; int ciphertext_len; EVP_CIPHER_CTX *ctx; ctx = EVP_CIPHER_CTX_new(); //Initialize the encryption operation if (1 == EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL)) { cout<<"success inttialize"< 0) { cout<<"success final decryption"< From matt at openssl.org Fri Jan 9 20:41:48 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 09 Jan 2015 20:41:48 +0000 Subject: [openssl-users] GCM In-Reply-To: References: Message-ID: <54B03D0C.6080502@openssl.org> On 09/01/15 19:42, Amir Reda wrote: > dear all > i'm trying to use AES-GCM model for encryption i use a sample code for that > > and my problem is > > ret = EVP_DecryptFinal_ex(ctx, plaintext + len, &len); > > ret all the time is 0 this means that > > the plaintext is not trustworthy. > > encryption function > > //get the tag > EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag); You should check the return value of this function here. You also haven't free'd up your ctx. > //add the tag > if (!EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag)) This is wrong. You need to use EVP_CTRL_GCM_SET_TAG. > { > cout<<"success adding tag"< } > else > { > cout<<"something wrong"< } > //finalize the Decryption > int ret = 1; > ret = EVP_DecryptFinal_ex(ctx, plaintext + len, &len); > > cout<<" ret value is "< > if (ret > 0) > { > cout<<"success final decryption"< plaintext_len += len; > cout<<"palin text is "< return plaintext_len; > > } > else > { > cout<<"decrypt fail"< return -1; > } > return ret; Again you need to clean up your ctx. Matt From noloader at gmail.com Fri Jan 9 21:07:51 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 9 Jan 2015 16:07:51 -0500 Subject: [openssl-users] GCM In-Reply-To: References: Message-ID: On Fri, Jan 9, 2015 at 2:42 PM, Amir Reda wrote: > dear all > i'm trying to use AES-GCM model for encryption i use a sample code for that > Also see the OpenSSL's wiki page on authenticated encryption: http://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption. It provides an AES/GCM example. Jeff From postmaster at openssl.org Sat Jan 10 11:34:47 2015 From: postmaster at openssl.org (MAILER-DAEMON) Date: Sat, 10 Jan 2015 17:04:47 +0530 Subject: [openssl-users] *****SPAM***** Message-ID: <20150110113449.0F3BD20923@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Your message could not be delivered [...] Content analysis details: (14.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "MAILER-DAEMON" Subject: Date: Sat, 10 Jan 2015 17:04:47 +0530 Size: 40032 URL: From rsalz at akamai.com Mon Jan 12 15:05:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Jan 2015 10:05:35 -0500 Subject: [openssl-users] [openssl-announce] Pas de courriel In-Reply-To: <808054015.494618.1421058706557.JavaMail.yahoo@jws100122.mail.ne1.yahoo.com> References: <808054015.494618.1421058706557.JavaMail.yahoo@jws100122.mail.ne1.yahoo.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675FA7@USMBX1.msg.corp.akamai.com> You are not on any mailing lists at openssl.org. perhaps under a different name? -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From: Philippe Jeanbaptiste [mailto:p_jeanbaptiste at yahoo.com] Sent: Monday, January 12, 2015 5:32 AM To: openssl-users at openssl.org; openssl-announce at openssl.org Subject: Re: [openssl-announce] Pas de courriel Same for me: I already asked you several time to withdraw me from your mailing list. Thank you. On Friday, January 9, 2015 5:48 AM, Dominique Bourget wrote: Bonjour, Retirez mon adresse de vos listes. Je ne veux plus recevoir ces avis. Dominique Bourget ________________________________ [cid:~WRD000.jpg] L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast. www.avast.com _______________________________________________ openssl-announce mailing list openssl-announce at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: From shinelight at shininglightpro.com Mon Jan 12 15:29:59 2015 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Mon, 12 Jan 2015 08:29:59 -0700 Subject: [openssl-users] Please release updated tarballs Message-ID: <54B3E877.80107@shininglightpro.com> None of the latest tarballs compile on Windows. Applying the 1.0.x patch to fix the 'cflags' issue would violate the default build only rule of the binary release process. Also, found an issue with 0.9.8zd not found in 0.9.8zc: ---- cl /Fotmp32dll\ecs_vrf.obj -Iinc32 -Itmp32dll -D_USE_32BIT_TIME_T /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DAES_ASM -DBN_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_CMS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_KRB5 -DOPENSSL_NO_DYNAMIC_ENGINE -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\ecdsa\ecs_vrf.c ecs_vrf.c tmp32dll\cryptlib.h(68) : error C2220: warning treated as error - no 'object' file generated tmp32dll\cryptlib.h(68) : warning C4005: 'BIO_FLAGS_UPLINK' : macro redefinition inc32\openssl/bio.h(180) : see previous definition of 'BIO_FLAGS_UPLINK' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.EXE"' : return code '0x2' Stop. ---- -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From lgrosenthal at 2rosenthals.com Mon Jan 12 16:00:16 2015 From: lgrosenthal at 2rosenthals.com (Lewis Rosenthal) Date: Mon, 12 Jan 2015 11:00:16 -0500 Subject: [openssl-users] [openssl-announce] Pas de courriel In-Reply-To: <54B3B6B3.3060404@certi.org.br> References: <808054015.494618.1421058706557.JavaMail.yahoo@jws100122.mail.ne1.yahoo.com> <54B3B6B3.3060404@certi.org.br> Message-ID: <54B3EF90.2050200@2rosenthals.com> On 01/12/2015 06:57 AM, Gabriel Marques wrote: > For all the openssl list subscribers: > The openssl-announce is a standard e-mail list based on MailMan. So to > unsubscribe just access > https://mta.openssl.org/mailman/options/openssl-announce > > And follow the un-subscription instructions - no need to notify the > entire list to say you don't want to receive more messages. > > att, > Gabriel. > ...or just read the message headers and either unsubscribe via http (https) or via email. The links are there in *every* message. Cheers -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress IRS Circular 230 Disclosure applies see www.2rosenthals.com ------------------------------------------------------------- From elns at xs4all.nl Mon Jan 12 21:57:04 2015 From: elns at xs4all.nl (Erik Leunissen) Date: Mon, 12 Jan 2015 22:57:04 +0100 Subject: [openssl-users] Retrieve OpenSSL version from C library Message-ID: <54B44330.8000901@xs4all.nl> Hi, Does the OpenSSL C library have a function that returns the OpenSSL version? Thanks in advance for your help, Erik Leunissen. From elns at xs4all.nl Mon Jan 12 22:09:28 2015 From: elns at xs4all.nl (Erik Leunissen) Date: Mon, 12 Jan 2015 23:09:28 +0100 Subject: [openssl-users] Retrieve OpenSSL version from C library In-Reply-To: <54B44330.8000901@xs4all.nl> References: <54B44330.8000901@xs4all.nl> Message-ID: <54B44618.7080200@xs4all.nl> On 12/01/15 22:57, Erik Leunissen wrote: > Hi, > > Does the OpenSSL C library have a function that returns the OpenSSL > version? > Never mind. I found it just after sending this post. #include const char *SSLeay_version(int type); Erik. > > Thanks in advance for your help, > > Erik Leunissen. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jonetsu at teksavvy.com Tue Jan 13 00:51:31 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Mon, 12 Jan 2015 19:51:31 -0500 Subject: [openssl-users] Error in untarring FIPS 2.0.9 file Message-ID: <20150112195131.16ea95b9@mevla> Hello, There is an untarring error with file. Here are the details. File size: 1425056 Jan 4 18:50 openssl-fips-2.0.9.tar.gz md5sum test OK with: c8256051d7a76471c6ad4fb771404e60 The error: % tar xvfz openssl-fips-2.0.9.tar.gz [...] openssl-fips-2.0.9/util/ssleay.num openssl-fips-2.0.9/util/tab_num.pl openssl-fips-2.0.9/util/x86asm.sh tar: A lone zero block at 14880 Is there something wrong with the archive ? Thanks. From gayathri.annur at gmail.com Tue Jan 13 06:42:49 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Tue, 13 Jan 2015 12:12:49 +0530 Subject: [openssl-users] Issues whiles doing direct upgrade from 0.9.8l to 1.0.1j Message-ID: Hi, I am using openssl- 0.9.8l and able to compile the openssl in fips mode. Now planning to upgrade to latest version - 1.0.1j. openssl-fips version is 1_2 and not changed this library. But getting the following error while compiling openssl 1.0.1j with openssl-fips 1_2 in fips mode d1_lib.c:274:4: error: #error Code needs update for DTLS_method() support beyond DTLS1_VERSION. make[3]: [depend] Error 1 (ignored) .. include/openssl/fips_rand.h:61: error: expected declaration specifiers or '...' before 'FIPS_RAND_SIZE_T' include/openssl/fips_rand.h:62: error: expected declaration specifiers or '...' before 'FIPS_RAND_SIZE_T' include/openssl/fips_rand.h:63: error: expected declaration specifiers or '...' before 'FIPS_RAND_SIZE_T' ... fips_err.h:74: error: 'FIPS_F_DH_INIT' undeclared here (not in a function) fips_err.h:75: error: 'FIPS_F_DRBG_RESEED' undeclared here (not in a function) fips_err.h:77: error: 'FIPS_F_DSA_BUILTIN_PARAMGEN2' undeclared here (not in a function) My RHEL version : Red Hat Enterprise Linux Server release 5.3 Could you please help me to resolve this issue. Thanks, Gayathri -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jan 13 09:08:35 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jan 2015 09:08:35 +0000 Subject: [openssl-users] Issues whiles doing direct upgrade from 0.9.8l to 1.0.1j In-Reply-To: References: Message-ID: <54B4E093.3080303@openssl.org> On 13/01/15 06:42, Gayathri Manoj wrote: > Hi, > > I am using openssl- 0.9.8l and able to compile the openssl in fips > mode. Now planning to upgrade to latest version - 1.0.1j. > openssl-fips version is 1_2 and not changed this library. You need to also upgrade your FIPS version to 2.0. Version 1.2 is compatible with OpenSSL 0.9.8 only. Matt From matt at openssl.org Tue Jan 13 09:10:21 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jan 2015 09:10:21 +0000 Subject: [openssl-users] Please release updated tarballs In-Reply-To: <54B3E877.80107@shininglightpro.com> References: <54B3E877.80107@shininglightpro.com> Message-ID: <54B4E0FD.4010101@openssl.org> On 12/01/15 15:29, Thomas J. Hruska wrote: > None of the latest tarballs compile on Windows. Applying the 1.0.x > patch to fix the 'cflags' issue would violate the default build only > rule of the binary release process. > > Also, found an issue with 0.9.8zd not found in 0.9.8zc: There is an official fix for this issue on the way (currently in review). Matt From gayathri.annur at gmail.com Tue Jan 13 09:43:02 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Tue, 13 Jan 2015 15:13:02 +0530 Subject: [openssl-users] Issues whiles doing direct upgrade from 0.9.8l to 1.0.1j In-Reply-To: <54B4E093.3080303@openssl.org> References: <54B4E093.3080303@openssl.org> Message-ID: Thanks Matt. On Tue, Jan 13, 2015 at 2:38 PM, Matt Caswell wrote: > > > On 13/01/15 06:42, Gayathri Manoj wrote: > > Hi, > > > > I am using openssl- 0.9.8l and able to compile the openssl in fips > > mode. Now planning to upgrade to latest version - 1.0.1j. > > openssl-fips version is 1_2 and not changed this library. > > You need to also upgrade your FIPS version to 2.0. Version 1.2 is > compatible with OpenSSL 0.9.8 only. > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jan 13 13:16:02 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jan 2015 13:16:02 +0000 Subject: [openssl-users] Error in untarring FIPS 2.0.9 file In-Reply-To: <20150112195131.16ea95b9@mevla> References: <20150112195131.16ea95b9@mevla> Message-ID: <54B51A92.8040307@openssl.org> On 13/01/15 00:51, jonetsu at teksavvy.com wrote: > Hello, > > There is an untarring error with file. Here are the details. > > File size: > > 1425056 Jan 4 18:50 openssl-fips-2.0.9.tar.gz > > md5sum test OK with: > > c8256051d7a76471c6ad4fb771404e60 > > The error: > > % tar xvfz openssl-fips-2.0.9.tar.gz > > [...] > openssl-fips-2.0.9/util/ssleay.num > openssl-fips-2.0.9/util/tab_num.pl > openssl-fips-2.0.9/util/x86asm.sh > tar: A lone zero block at 14880 > > Is there something wrong with the archive ? No. "Recent versions of GNU tar expect a pair of zero blocks at the end of the file by default. If GNU tar encounters a lone zero block, even at the end, this is interpreted by GNU tar as a bad archive." (from http://www-01.ibm.com/support/docview.wss?uid=swg21270445) if you use: tar ixvfz openssl-fips-2.0.9.tar.gz the problem goes away. Matt From matt at openssl.org Tue Jan 13 13:29:23 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jan 2015 13:29:23 +0000 Subject: [openssl-users] Please release updated tarballs In-Reply-To: <54B4E0FD.4010101@openssl.org> References: <54B3E877.80107@shininglightpro.com> <54B4E0FD.4010101@openssl.org> Message-ID: <54B51DB3.30306@openssl.org> On 13/01/15 09:10, Matt Caswell wrote: > > > On 12/01/15 15:29, Thomas J. Hruska wrote: >> None of the latest tarballs compile on Windows. Applying the 1.0.x >> patch to fix the 'cflags' issue would violate the default build only >> rule of the binary release process. >> >> Also, found an issue with 0.9.8zd not found in 0.9.8zc: > > There is an official fix for this issue on the way (currently in review). > The official fix for this issue is in commit 94e5cf3 for 1.0.0, and 56abaa1 for 0.9.8. Matt From JLaundree at zoll.com Tue Jan 13 15:43:33 2015 From: JLaundree at zoll.com (John Laundree) Date: Tue, 13 Jan 2015 15:43:33 +0000 Subject: [openssl-users] Looking for ASKDFVS (NIST 800-135) support Message-ID: <02FD6BF65B9B854BA49784A11B009BD312979A32@AUSP07DAG0102.hostedmail.local> I am looking for test vectors and a test suite to support FIPS KDF testing using openSSL FIPS version 2.0.7 in conjunction with OpenSSL 1.0.1e. Specifically, I am looking to do TLS KDF testing. I am new to openSSL/FIPS community and was expecting to find KDF test vectors similar to what is provided at http://opensslfoundation.com/testing/validation-2.0/testvectors/?C=M;O=D and supporting tests in the openSSL FIPS codebase. I see a few Vendors have been certified with KDF TLS using openSSL. So I guess my question boils down to this... Is KDF test generation using openSSL a vendor exercise (i.e. model off of openSSL t1_enc.c code)? Or did I miss something along the way? Any pointers/advice is appreciated. Thanks. jl -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Jan 13 19:50:25 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 13 Jan 2015 14:50:25 -0500 Subject: [openssl-users] OpenSSL coding style published Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> The OpenSSL coding style document is now available on our web site: https://www.openssl.org/about/codingstyle.txt It is derived from the Linux Kernel coding style, and we are grateful to them for providing such an excellent document that we could use as our base. Because it is derived from the GPL'd kernel style, the OpenSSL coding style will not be part of the distribution. As Matt mentioned in earlier mail, we will be reformatting all release branches. See his message[1] for sample output and pointers to the script. The target date for doing this is "very soon." :) /r$ [1] https://mta.openssl.org/pipermail/openssl-dev/2015-January/000299.html -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjsvance at gmail.com Tue Jan 13 22:29:24 2015 From: cjsvance at gmail.com (Christopher Vance) Date: Wed, 14 Jan 2015 09:29:24 +1100 Subject: [openssl-users] Error in untarring FIPS 2.0.9 file In-Reply-To: <54B51A92.8040307@openssl.org> References: <20150112195131.16ea95b9@mevla> <54B51A92.8040307@openssl.org> Message-ID: In ancient times tar used a blocksize of 10240 bytes (or 20 records of 512 bytes), particularly for tape. I'm pretty sure I sometimes had to zero pad out to a multiple of 10240 bytes, even when there was no tape involved. On Wed, Jan 14, 2015 at 12:16 AM, Matt Caswell wrote: > > > On 13/01/15 00:51, jonetsu at teksavvy.com wrote: > > Hello, > > > > There is an untarring error with file. Here are the details. > > > > File size: > > > > 1425056 Jan 4 18:50 openssl-fips-2.0.9.tar.gz > > > > md5sum test OK with: > > > > c8256051d7a76471c6ad4fb771404e60 > > > > The error: > > > > % tar xvfz openssl-fips-2.0.9.tar.gz > > > > [...] > > openssl-fips-2.0.9/util/ssleay.num > > openssl-fips-2.0.9/util/tab_num.pl > > openssl-fips-2.0.9/util/x86asm.sh > > tar: A lone zero block at 14880 > > > > Is there something wrong with the archive ? > > No. > > "Recent versions of GNU tar expect a pair of zero blocks at the end of > the file by default. If GNU tar encounters a lone zero block, even at > the end, this is interpreted by GNU tar as a bad archive." > (from http://www-01.ibm.com/support/docview.wss?uid=swg21270445) > > if you use: > > tar ixvfz openssl-fips-2.0.9.tar.gz > > the problem goes away. > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Christopher Vance -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Wed Jan 14 02:33:49 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Tue, 13 Jan 2015 21:33:49 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps Message-ID: <20150113213349.4f85c1ce@mevla> Hello, A system running in FIPS can have several applications using libssl. openvpn and openswan are two. There can be 3rd party web servers. So on. Is there any 'library magic' these days that would prevent modifying each and every application to add a FIPS_mode_set() call and error handling ? I guess there isn't although I'm not risking anything in asking :) So basically every app that uses libssl will have to be modified to add a FIPS_mode_set() call near the beginning. Is that right ? Thanks for any comments and suggestions ! Regards. From 84.le0n at gmail.com Wed Jan 14 07:58:40 2015 From: 84.le0n at gmail.com (84.le0n) Date: Wed, 14 Jan 2015 08:58:40 +0100 Subject: [openssl-users] OpenSSL coding style published In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> Message-ID: <64004470-5889-496E-BD55-B3C44120DFAD@gmail.com> +1 There's a typo "Somtimes" in chapter 16. Eng. Gabriele Pongelli AVVERTENZE AI SENSI DEL D.LGS. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e negli eventuali files allegati, sono da considerarsi strettamente riservati. Il loro utilizzo ? consentito esclusivamente al destinatario del messaggio, per le finalit? indicate nel messaggio stesso. Qualora riceveste per errore questo messaggio, Vi preghiamo cortesemente di darcene notizia all'indirizzo e-mail di cui sopra e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema; costituisce comportamento contrario ai principi dettati dal D.lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalit? diverse. This electronic transmission is strictly confidential and intended solely for the addresses. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error, please notify us and delete the received data as soon as possible. Il giorno 13/gen/2015, alle ore 20:50, Salz, Rich ha scritto: > The OpenSSL coding style document is now available on our web site: > > https://www.openssl.org/about/codingstyle.txt > > It is derived from the Linux Kernel coding style, and we are grateful to them for providing such an excellent document that we could use as our base. Because it is derived from the GPL?d kernel style, the OpenSSL coding style will not be part of the distribution. > > As Matt mentioned in earlier mail, we will be reformatting all release branches. See his message[1] for sample output and pointers to the script. The target date for doing this is ?very soon.? J > > /r$ > [1] https://mta.openssl.org/pipermail/openssl-dev/2015-January/000299.html > > -- > Principal Security Engineer, Akamai Technologies > IM: rsalz at jabber.me Twitter: RichSalz > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bird_112 at hotmail.com Wed Jan 14 12:35:09 2015 From: bird_112 at hotmail.com (jack seth) Date: Wed, 14 Jan 2015 06:35:09 -0600 Subject: [openssl-users] Generating large DH parameters Message-ID: I am trying to generate a 16384 bit DH file for testing purposes. Is it necessary to have a '.rnd' in existence before trying to generate this file? I generated one which took 4 days to do but the computer had a .rnd file. I am currently trying to generate another on a system WITHOUT the .rnd file and it has been going 3 WEEKS so far. Did I just get lucky with the first DH file and it really can take this long (or longer) to make this file or does openssl really need the .rnd file to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jan 14 13:27:55 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Jan 2015 13:27:55 +0000 Subject: [openssl-users] Generating large DH parameters In-Reply-To: References: Message-ID: <54B66EDB.6040908@openssl.org> On 14/01/15 12:35, jack seth wrote: > I am trying to generate a 16384 bit DH file for testing purposes. Is > it necessary to have a '.rnd' in existence before trying to generate > this file? I generated one which took 4 days to do but the computer had > a .rnd file. I am currently trying to generate another on a system > WITHOUT the .rnd file and it has been going 3 WEEKS so far. Did I just > get lucky with the first DH file and it really can take this long (or > longer) to make this file or does openssl really need the .rnd file to > do this? The purpose of the .rnd file is to seed the random number generator with entropy before you start. The built-in OpenSSL PRNG will attempt to seed itself from various different sources dependent on the platform that you are on, e.g. if you have a "/dev/urandom" then it will try to use it. Some platforms may have very restricted access to entropy sources, and on those platforms a .rnd file might be particularly useful. Assuming you are using a relatively modern desktop machine this is unlikely to be a problem for you. If the PRNG has not been seeded with sufficient entropy then it will fail with the "PRNG not seeded" error: https://www.openssl.org/support/faq.html#USER1 The fact that you have not seen that error means that the PRNG believes it has been sufficiently seeded. The method that was used to seed the PRNG will not have a subsequent impact on its performance. In other words, the presence or otherwise of the .rnd file will not impact the performance once seeding is complete. The reason it is taking so long is that 16384 bits is GIGANTIC! Matt From dpb795795 at gmail.com Wed Jan 14 13:29:08 2015 From: dpb795795 at gmail.com (Deepak) Date: Wed, 14 Jan 2015 18:59:08 +0530 Subject: [openssl-users] Assembler Optimizations in 'crypto' on Windows Message-ID: Dear OpenSSL User, I am working on porting 0.9.8h based 'OpenSSL customization' to 1.0.1. Earlier this code was using 'cpp' as input parameter to the Perl scripts. 1. What option shall I use now for Windows? As per documentation, nasm will be the only supported assembler. But currently both masm (option win32) and nasm (option win32n) work. 2. Why nasm is prefered over masm? Maybe ml.exe is better since it comes from ms. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bird_112 at hotmail.com Wed Jan 14 14:23:13 2015 From: bird_112 at hotmail.com (jack seth) Date: Wed, 14 Jan 2015 08:23:13 -0600 Subject: [openssl-users] Generating large DH parameters In-Reply-To: <54B66EDB.6040908@openssl.org> References: , <54B66EDB.6040908@openssl.org> Message-ID: Thanks for the explanation. So I guess I just got lucky with the first one. :) Do you have any kind of estimate of how long it will take to generate? > Date: Wed, 14 Jan 2015 13:27:55 +0000 > From: matt at openssl.org > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Generating large DH parameters > > > > On 14/01/15 12:35, jack seth wrote: > > I am trying to generate a 16384 bit DH file for testing purposes. Is > > it necessary to have a '.rnd' in existence before trying to generate > > this file? I generated one which took 4 days to do but the computer had > > a .rnd file. I am currently trying to generate another on a system > > WITHOUT the .rnd file and it has been going 3 WEEKS so far. Did I just > > get lucky with the first DH file and it really can take this long (or > > longer) to make this file or does openssl really need the .rnd file to > > do this? > > The purpose of the .rnd file is to seed the random number generator with > entropy before you start. The built-in OpenSSL PRNG will attempt to seed > itself from various different sources dependent on the platform that you > are on, e.g. if you have a "/dev/urandom" then it will try to use it. > Some platforms may have very restricted access to entropy sources, and > on those platforms a .rnd file might be particularly useful. Assuming > you are using a relatively modern desktop machine this is unlikely to be > a problem for you. > > If the PRNG has not been seeded with sufficient entropy then it will > fail with the "PRNG not seeded" error: > https://www.openssl.org/support/faq.html#USER1 > > The fact that you have not seen that error means that the PRNG believes > it has been sufficiently seeded. The method that was used to seed the > PRNG will not have a subsequent impact on its performance. > > In other words, the presence or otherwise of the .rnd file will not > impact the performance once seeding is complete. > > The reason it is taking so long is that 16384 bits is GIGANTIC! > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jan 14 14:53:17 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Jan 2015 09:53:17 -0500 Subject: [openssl-users] OpenSSL coding style published In-Reply-To: <64004470-5889-496E-BD55-B3C44120DFAD@gmail.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> <64004470-5889-496E-BD55-B3C44120DFAD@gmail.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC65F@USMBX1.msg.corp.akamai.com> > There's a typo "Somtimes" in chapter 16. Thanks. Will push a fix sometime soon From matt at openssl.org Wed Jan 14 15:32:34 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Jan 2015 15:32:34 +0000 Subject: [openssl-users] Forthcoming OpenSSL releases and reformat Message-ID: <54B68C12.5000507@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The OpenSSL Project are pleased to make the following announcements: - - There will be new releases made available on Thursday 15th January for versions 1.0.1, 1.0.0 and 0.9.8. These will be bug fix only releases to address build problems with the current releases on the Windows and OpenVMS platforms. No new security issues will be included in these releases. - - The whole OpenSSL codebase will be reformatted according to the newly published OpenSSL coding style (https://www.openssl.org/about/codingstyle.txt) on Wednesday 21st January. This will include the master, 1.0.2, 1.0.1, 1.0.0 and 0.9.8 branches. See [1] for further background information. - - Between the releases being made available on 15th January and the code reformat on 21st January the 1.0.1, 1.0.0 and 0.9.8 branches in the public repository will be frozen and no changes will be made (except in the case of very high priority fixes). - - OpenSSL 1.0.2 will be released on Thursday 22nd January. Yours The OpenSSL Project Team [1] https://mta.openssl.org/pipermail/openssl-dev/2015-January/000299.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUtowSAAoJENnE0m0OYESRjr0H/3ui088oz8ZDcHEkhXoF1Pd/ bJStjZPtWUq4BJTTKq/GTTK7TGsjW+z+OwXFuLOX6ZfvVTG0aMpCGEU4OT7PO2zt NC76X56bTA+sFrJt65Ks3xMZ4pppBRq6irSJsvihEb1rWiAGDlTTjJJLKfgP76Xc ZxHnQ4LKmWcqqZmuK+XFqkitf6DuVMNlPa6yJ9jjbq6gSibxSNvhbu+qTfH2M30g 9X854pWKj5j76RLmDvFBPqP+sGHNBhs45THZO7BuGPQV5lJzRvnJxQKreAcHAyhq BihHEdsk9wKMKJNjrcVgfKSulx3PLvAIn8mZW9CIuxmEfn9LKsGyrJvwJLBk5DY= =d482 -----END PGP SIGNATURE----- From marquess at opensslfoundation.com Wed Jan 14 15:35:47 2015 From: marquess at opensslfoundation.com (Steve Marquess) Date: Wed, 14 Jan 2015 10:35:47 -0500 Subject: [openssl-users] Platinum Sponsorship by Oracle Message-ID: <54B68CD3.1040400@opensslfoundation.org> I am pleased to announce Oracle Corporation (http://www.oracle.com) as the third Platinum Sponsor of the OpenSSL project, and the first such sponsor from the United States. For several years, Oracle has provided financial support in the form of commercial funding of platform validations for the OpenSSL FIPS Object Module v2.0 (certificate #1747), the most widely used FIPS 140-2 validated cryptographic module and the only one freely available under an open source license. Without financial support from Oracle and other FIPS module users, the successful completion and continued maintenance of that module would not have been possible. Thank you Oracle! -Steve M. -- Steve Marquess OpenSSL Software Foundation Inc. 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From skneizys at ferrilli.com Wed Jan 14 16:32:45 2015 From: skneizys at ferrilli.com (Steven Kneizys) Date: Wed, 14 Jan 2015 11:32:45 -0500 Subject: [openssl-users] Assembler Optimizations in 'crypto' on Windows In-Reply-To: References: Message-ID: Just my opinion ... but ... While nasm is the only supported assembler, I have been able to get masm to work but I often have to tweak the perl code a bit. Every few months I have been testing and reporting my findings to the openssl-dev group about my results. When possible folks seem to be able to incorporate changes that help make things better on a variety of isssues folks submit patches for. And, one recent 64 bit build required no tweaks using ml64.exe so it is possible to use it sometimes. However, there are some other really high priorities with getting the openssl product as safe and reliable as possible. The support cannot be for all available tools and nasm is the best choice. Nasm allows a number of platforms that masm does not, it is open source so any issues can be addressed quickly. For just windows I would like masm to work, but I have used both and haven't been disappointed. The main problem I have is with auditors, sometimes they ask about where an executable like openssl comes from, was it obtained from the web as a binary or built, and if built was it built via tools downloaded (and possibly binary) or from the vendor (such as HP, IBM, MS, etc.) The only reason I can see at this point to try use masm is if you have a mandate to use it and don't mind some possible hours of frustration as you work through any issues, but my advice is to download nasm and give it a try. It is free and for me quite reliable. -- Steve Kneizys Senior Business Process Engineer @ Ferrilli web: http://www.ferrilli.com/ On Wed, Jan 14, 2015 at 8:29 AM, Deepak wrote: > Dear OpenSSL User, > > I am working on porting 0.9.8h based 'OpenSSL customization' to 1.0.1. > > Earlier this code was using 'cpp' as input parameter to the Perl scripts. > > 1. What option shall I use now for Windows? > > As per documentation, nasm will be the only supported assembler. But > currently both masm (option win32) and nasm (option win32n) work. > > 2. Why nasm is prefered over masm? Maybe ml.exe is better since it comes > from ms. > > Thank you. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jan 14 16:43:55 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 14 Jan 2015 16:43:55 +0000 Subject: [openssl-users] Generating large DH parameters In-Reply-To: References: <54B66EDB.6040908@openssl.org> Message-ID: <20150114164355.GS7322@mournblade.imrryr.org> On Wed, Jan 14, 2015 at 08:23:13AM -0600, jack seth wrote: > Thanks for the explanation. So I guess I just got lucky with > the first one. :) Do you have any kind of estimate of how long > it will take to generate? The density of strong primes is conjectured to be ~1.3*n/(ln(n))^2. For 16k bit primes you're looking at one number out of 100 million. For 2k bit primes the density is 64 times larger. In addition to density-related factor of 64, one needs to take into account the increased cost of testing the primality of each candidate. I don't know how that scales with "log n" in OpenSSL, but it is surely at least linear. So this gives you a factor of at least 512 for the run-time of generating DH 2k vs DH 16k. DO NOT USE 16k bit prime DH groups. Even 4k bit and definitely anything larger is essentially impractical. -- Viktor. From noloader at gmail.com Thu Jan 15 04:35:01 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 14 Jan 2015 23:35:01 -0500 Subject: [openssl-users] EVP_DigestSignInit failed, error 0x0000000d? Message-ID: What does it mean when EVP_DigestSignInit fails with an error code of 0x0000000d? On failure, the code is being fetched with ERR_get_error(). ---------- $ /usr/local/ssl/bin/openssl errstr 0x0d error:0000000D:lib(0):func(0):ASN1 lib ---------- I see its declared in evp.h, but I don't see a body anywhere. $ grep -R EVP_DigestSignInit * apps/dgst.c: r = EVP_DigestSignInit(mctx, &pctx, md, NULL, sigkey); apps/req.c: if (!EVP_DigestSignInit(ctx, &pkctx, md, NULL, pkey)) ... crypto/evp/evp.h:int EVP_DigestSignInit(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx, ... From erafaloff at gmail.com Thu Jan 15 05:03:00 2015 From: erafaloff at gmail.com (Eric R.) Date: Thu, 15 Jan 2015 05:03:00 +0000 Subject: [openssl-users] SSL3_GET_CLIENT_HELLO:required cipher missing Message-ID: For the past week I've been noticing many entries like this in our nginx error logs: SSL_do_handshake() failed (SSL: error:1408A0D7:SSL routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking What does the error "required cipher missing" mean exactly? Some of our users reported that their browser gave them an SSL connection error and then it went away. Others can no longer connect to our site at all. I've had a look at the OpenSSL source code and I think the error is related to checking that the server still supports the last cipher a session used. Is this correct? The only change I can think of that may affect our list of available ciphers was an update to the latest version of OpenSSL that CentOS 5 provided back in November. That was two months ago though, and other than that I can't think of what could be causing this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpb795795 at gmail.com Thu Jan 15 08:21:17 2015 From: dpb795795 at gmail.com (Deepak) Date: Thu, 15 Jan 2015 13:51:17 +0530 Subject: [openssl-users] Assembler Optimizations in 'crypto' on Windows In-Reply-To: References: Message-ID: On Jan 14, 2015 10:14 PM, "Steven Kneizys" wrote: > > Just my opinion ... but ... > > While nasm is the only supported assembler, I have been able to get masm to work but I often have to tweak the perl code a bit. Every few months I have been testing and reporting my findings to the openssl-dev group about my results. When possible folks seem to be able to incorporate changes that help make things better on a variety of isssues folks submit patches for. And, one recent 64 bit build required no tweaks using ml64.exe so it is possible to use it sometimes. However, there are some other really high priorities with getting the openssl product as safe and reliable as possible. The support cannot be for all available tools and nasm is the best choice. > > Nasm allows a number of platforms that masm does not, it is open source so any issues can be addressed quickly. For just windows I would like masm to work, but I have used both and haven't been disappointed. The main problem I have is with auditors, sometimes they ask about where an executable like openssl comes from, was it obtained from the web as a binary or built, and if built was it built via tools downloaded (and possibly binary) or from the vendor (such as HP, IBM, MS, etc.) The only reason I can see at this point to try use masm is if you have a mandate to use it and don't mind some possible hours of frustration as you work through any issues, but my advice is to download nasm and give it a try. It is free and for me quite reliable. > > -- > Steve Kneizys > Senior Business Process Engineer @ Ferrilli > web: http://www.ferrilli.com/ > > On Wed, Jan 14, 2015 at 8:29 AM, Deepak wrote: >> >> Dear OpenSSL User, >> >> I am working on porting 0.9.8h based 'OpenSSL customization' to 1.0.1. >> >> Earlier this code was using 'cpp' as input parameter to the Perl scripts. >> >> 1. What option shall I use now for Windows? >> >> As per documentation, nasm will be the only supported assembler. But currently both masm (option win32) and nasm (option win32n) work. >> >> 2. Why nasm is prefered over masm? Maybe ml.exe is better since it comes from ms. >> >> Thank you. >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > Thank you for sharing the inputs. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Thu Jan 15 08:41:11 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 15 Jan 2015 03:41:11 -0500 Subject: [openssl-users] EVP_DigestVerifyFinal return code? Message-ID: According to the man pages on EVP_DigestVerifyFinal (https://www.openssl.org/docs/crypto/EVP_DigestVerifyInit.html): EVP_DigestVerifyInit() and EVP_DigestVerifyUpdate() return 1 for success and 0 or a negative value for failure... I have an unexplained failure in EVP_DigestVerifyInit (i.e., its not returning 1). Looking at apps/dgst.c, around line 580: if(sigin) { EVP_MD_CTX *ctx; BIO_get_md_ctx(bp, &ctx); i = EVP_DigestVerifyFinal(ctx, sigin, (unsigned int)siglen); if(i > 0) BIO_printf(out, "Verified OK\n"); else if(i == 0) { BIO_printf(out, "Verification Failure\n"); return 1; } else { BIO_printf(bio_err, "Error Verifying Data\n"); ERR_print_errors(bio_err); return 1; } return 0; } So does EVP_DigestVerifyInit return 1 on success, or does it return something else? If its 1, then digst.c is wrong. If its something else (like >0), then the docs are wrong. Is anyone familiar with this function who can comment? From jonetsu at teksavvy.com Thu Jan 15 10:46:22 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Thu, 15 Jan 2015 05:46:22 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <20150113213349.4f85c1ce@mevla> References: <20150113213349.4f85c1ce@mevla> Message-ID: <20150115054622.52b28119@mevla> On Tue, 13 Jan 2015 21:33:49 -0500 "jonetsu at teksavvy.com" wrote: > So basically every app that uses libssl will have to be modified to > add a FIPS_mode_set() call near the beginning. Is that right ? Is there a way to automatically have the FIPS test executed when an application loads the library, w/o the application being modified ? Is such a way used at all ? From meissner at suse.de Thu Jan 15 10:52:55 2015 From: meissner at suse.de (Marcus Meissner) Date: Thu, 15 Jan 2015 11:52:55 +0100 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <20150115054622.52b28119@mevla> References: <20150113213349.4f85c1ce@mevla> <20150115054622.52b28119@mevla> Message-ID: <20150115105255.GB27946@suse.de> On Thu, Jan 15, 2015 at 05:46:22AM -0500, jonetsu at teksavvy.com wrote: > On Tue, 13 Jan 2015 21:33:49 -0500 > "jonetsu at teksavvy.com" wrote: > > > So basically every app that uses libssl will have to be modified to > > add a FIPS_mode_set() call near the beginning. Is that right ? > > Is there a way to automatically have the FIPS test executed when an > application loads the library, w/o the application being modified ? Is > such a way used at all ? This is actually mandated these days. The library should do this in its ELF constructor for instance. On Linux usually triggered by /proc/sys/crypto/fips_enabled containing "1" or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). Ciao, Marcus From matt at openssl.org Thu Jan 15 11:29:24 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Jan 2015 11:29:24 +0000 Subject: [openssl-users] SSL3_GET_CLIENT_HELLO:required cipher missing In-Reply-To: References: Message-ID: <54B7A494.8090006@openssl.org> On 15/01/15 05:03, Eric R. wrote: > For the past week I've been noticing many entries like this in our nginx > error logs: > > SSL_do_handshake() failed (SSL: error:1408A0D7:SSL > routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL > handshaking > > What does the error "required cipher missing" mean exactly? Some of our > users reported that their browser gave them an SSL connection error and > then it went away. Others can no longer connect to our site at all. I've > had a look at the OpenSSL source code and I think the error is related > to checking that the server still supports the last cipher a session > used. Is this correct? The only change I can think of that may affect > our list of available ciphers was an update to the latest version of > OpenSSL that CentOS 5 provided back in November. That was two months ago > though, and other than that I can't think of what could be causing this. It means that an attempt is being made to resume a session, however the list of ciphers that the client is sending in the ClientHello does not include the cipher that was negotiated in the original session. Matt From awilliam at redhat.com Thu Jan 15 12:52:18 2015 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 15 Jan 2015 04:52:18 -0800 Subject: [openssl-users] Behaviour of OpenSSL when CApath or CAfile contains a 'trusted certificate' with all uses rejected Message-ID: <1421326338.15361.213.camel@redhat.com> Whew, that was a long title! Hi, folks. I'm a Fedora QA person who's been poking at SSL stuff as a sort of sideline lately; please don't give me too much credit for my email address, I'm not one of RH's official security / SSL folks, so please be gentle when I'm wrong ;) This is all with OpenSSL 1.0.1k on Fedora Rawhide. Lately I've been trying to figure out if it's possible / desirable to switch to using the OpenSSL 'trusted certificate' format (the one whose PEM-encoded certificates have 'BEGIN TRUSTED CERTIFICATE' rather than 'BEGIN CERTIFICATE') for a distribution's trust store. The case I'm (currently) interested in is what exactly happens if you try to distrust a CA using the 'trusted certificate' system. To this end, I've been doing some tests. I'm using the certificate chain that's used by my personal domain (https://www.happyassassin.net ), so it should be quite easy to reproduce. My certificate is a StartCom level 2 cert; the root CA cert is http://www.startssl.com/certs/ca.pem and the intermediate CA cert is http://www.startssl.com/certs/sub.class2.server.ca.pem , my server certificate is attached for convenience or can easily be retrieved from...the server. I'm using Fedora's p11-kit-based trust store generation system. If I put ca.pem in /etc/pki/ca-trust/source/blacklist , run `update-ca- trust` and then `trust extract --format=openssl-directory --filter blacklist black` , what p11-kit does is generate a 'TRUSTED CERTIFICATE' format certificate file named StartCom_Certification_Authority.pem for the blacklisted CA and place it in the directory 'black' (if you actually try this you'll also get a few other files in there, for CAs that are blacklisted by system policy). (The '--filter blacklist' stops it also generating files for all the trusted CAs, just to keep things clean). It also generates the necessary hash symlinks for OpenSSL to treat the directory as a CApath, of course. If you run `openssl x509 -in black/StartCom_Certification_Authority.pem -noout -text`, you see how p11-kit tries to use the 'TRUSTED CERTIFICATE' extensions to indicate that the CA should not be trusted: No Trusted Uses. Rejected Uses: TLS Web Server Authentication, TLS Web Client Authentication, Code Signing, E-mail Protection, IPSec End System, IPSec Tunnel, IPSec User, Time Stamping So, hopefully that picture's clear? The intent is that if you use black/ as the CApath for validation, certs issued by that CA should not be trusted. For comparison, I have the directory white/ , which contains p11-kit's output for the same CA when whitelisted / trusted: Trusted Uses: E-mail Protection, TLS Web Server Authentication, Code Signing No Rejected Uses. In one of my test cases, this seems to work pretty well. I just try to connect to my server with s_client, using the two different CApaths. black: [adamw at adam tmp]$ openssl s_client -CApath black/ -connect www.happyassassin.net:443 ... verify error:num=28:certificate rejected verify return:0 ... Verify return code: 28 (certificate rejected) white: [adamw at adam tmp]$ openssl s_client -CApath white/ -connect www.happyassassin.net:443 ... verify return:1 ... Verify return code: 0 (ok) However, if I use 'openssl verify' (and provide the intermediate cert with -untrusted), it doesn't work as expected. No errors occur, even with the 'black' CApath. [adamw at adam tmp]$ openssl verify -CApath black/ -untrusted sub.class2.server.ca.pem www.happyassassin.net.crt www.happyassassin.net.crt: OK Even if I pass a purpose: [adamw at adam tmp]$ openssl verify -purpose sslserver -CApath black/ -untrusted sub.class2.server.ca.pem www.happyassassin.net.crt www.happyassassin.net.crt: OK The outputs of `openssl x509 -in white/StartCom_Certification_Authority.pem -noout -purpose` and `openssl x509 -in black/StartCom_Certification_Authority.pem -noout - purpose` are identical. I've been staring at the code and docs for this for several hours to try and figure out what the difference between the 'verify' and 's_client' paths is, and I finally had to sort of throw up my hands and admit defeat, and come and ask for help :) It seems to me that it must be the case, somehow, that on the 'openssl verify' path the root certificate just isn't run through X509_check_trust(). But I can't see why not. To my idiot eyes, verify.c's check() and ssl_cert.c's ssl_verify_cert_chain() look like they do more or less the same thing, and verify.c's verify_callback doesn't seem to suppress any errors. After a lot of searching I did satisfy myself that anything that goes through ssl3_connect() gets a default purpose and trust (it had been suggested on the RH bug that only consumers which explicitly set these would get one), but that doesn't explain why 'openssl verify' works even with a -purpose. If anyone can point out what I'm missing I'd be very grateful :) As well as my server cert I'll attach the 'black' and 'white' .pem files and the intermediate cert. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -------------- next part -------------- A non-text attachment was scrubbed... Name: www.happyassassin.net.crt Type: application/pkix-cert Size: 2748 bytes Desc: not available URL: -------------- next part -------------- -----BEGIN TRUSTED CERTIFICATE----- MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w +2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+ Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B 26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ 9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8 jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14wdKBQBggrBgEFBQcDAQYIKwYB BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwUGCCsGAQUFBwMGBggr BgEFBQcDBwYIKwYBBQUHAwgMIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5 -----END TRUSTED CERTIFICATE----- -------------- next part -------------- -----BEGIN TRUSTED CERTIFICATE----- MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w +2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+ Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B 26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ 9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8 jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14wQjAeBggrBgEFBQcDBAYIKwYB BQUHAwEGCCsGAQUFBwMDDCBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eQ== -----END TRUSTED CERTIFICATE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: sub.class2.server.ca.pem Type: application/x-x509-ca-cert Size: 2212 bytes Desc: not available URL: From erafaloff at gmail.com Thu Jan 15 14:00:36 2015 From: erafaloff at gmail.com (Eric R.) Date: Thu, 15 Jan 2015 14:00:36 +0000 Subject: [openssl-users] SSL3_GET_CLIENT_HELLO:required cipher missing References: <54B7A494.8090006@openssl.org> Message-ID: Thanks Matt. Would you have any guess as to why this is happening so frequently all of a sudden and disrupting traffic? It seems strange that it's so intermittent and only some users have the problem repeat for them. On Thu Jan 15 2015 at 6:30:56 AM Matt Caswell wrote: > > > On 15/01/15 05:03, Eric R. wrote: > > For the past week I've been noticing many entries like this in our nginx > > error logs: > > > > SSL_do_handshake() failed (SSL: error:1408A0D7:SSL > > routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL > > handshaking > > > > What does the error "required cipher missing" mean exactly? Some of our > > users reported that their browser gave them an SSL connection error and > > then it went away. Others can no longer connect to our site at all. I've > > had a look at the OpenSSL source code and I think the error is related > > to checking that the server still supports the last cipher a session > > used. Is this correct? The only change I can think of that may affect > > our list of available ciphers was an update to the latest version of > > OpenSSL that CentOS 5 provided back in November. That was two months ago > > though, and other than that I can't think of what could be causing this. > > It means that an attempt is being made to resume a session, however the > list of ciphers that the client is sending in the ClientHello does not > include the cipher that was negotiated in the original session. > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erafaloff at gmail.com Thu Jan 15 14:01:45 2015 From: erafaloff at gmail.com (Eric R.) Date: Thu, 15 Jan 2015 14:01:45 +0000 Subject: [openssl-users] SSL3_GET_CLIENT_HELLO:required cipher missing References: <54B7A494.8090006@openssl.org> Message-ID: Via our nginx config, we've been supporting TLSv1 with the following ciphers: AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5 On Thu Jan 15 2015 at 9:00:36 AM Eric R. wrote: > Thanks Matt. Would you have any guess as to why this is happening so > frequently all of a sudden and disrupting traffic? It seems strange that > it's so intermittent and only some users have the problem repeat for them. > > On Thu Jan 15 2015 at 6:30:56 AM Matt Caswell wrote: > >> >> >> On 15/01/15 05:03, Eric R. wrote: >> > For the past week I've been noticing many entries like this in our nginx >> > error logs: >> > >> > SSL_do_handshake() failed (SSL: error:1408A0D7:SSL >> > routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL >> > handshaking >> > >> > What does the error "required cipher missing" mean exactly? Some of our >> > users reported that their browser gave them an SSL connection error and >> > then it went away. Others can no longer connect to our site at all. I've >> > had a look at the OpenSSL source code and I think the error is related >> > to checking that the server still supports the last cipher a session >> > used. Is this correct? The only change I can think of that may affect >> > our list of available ciphers was an update to the latest version of >> > OpenSSL that CentOS 5 provided back in November. That was two months ago >> > though, and other than that I can't think of what could be causing this. >> >> It means that an attempt is being made to resume a session, however the >> list of ciphers that the client is sending in the ClientHello does not >> include the cipher that was negotiated in the original session. >> >> Matt >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.francis.jr at pobox.com Thu Jan 15 19:13:46 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Thu, 15 Jan 2015 14:13:46 -0500 Subject: [openssl-users] EVP_DigestVerifyFinal return code? In-Reply-To: References: Message-ID: > On Jan 15, 2015, at 3:41 AM, Jeffrey Walton wrote: > > According to the man pages on EVP_DigestVerifyFinal > (https://www.openssl.org/docs/crypto/EVP_DigestVerifyInit.html): > > EVP_DigestVerifyInit() and EVP_DigestVerifyUpdate() return 1 for > success and 0 or a negative value for failure... > > I have an unexplained failure in EVP_DigestVerifyInit (i.e., its not > returning 1). > > Looking at apps/dgst.c, around line 580: > > if(sigin) > { > EVP_MD_CTX *ctx; > BIO_get_md_ctx(bp, &ctx); > i = EVP_DigestVerifyFinal(ctx, sigin, (unsigned int)siglen); > if(i > 0) > BIO_printf(out, "Verified OK\n"); > else if(i == 0) > { > BIO_printf(out, "Verification Failure\n"); > return 1; > } > else > { > BIO_printf(bio_err, "Error Verifying Data\n"); > ERR_print_errors(bio_err); > return 1; > } > return 0; > } > > So does EVP_DigestVerifyInit return 1 on success, or does it return > something else? If its 1, then digst.c is wrong. If its something else > (like >0), then the docs are wrong. IIRC (from when I looked at it before replying on a different list to you), it only returns 1 on success and 0 on failure. I suspect the author of the apps code modified it to check for > 0, because a while back, it was determined that a few functions that used to only return 1 for success and 0 for failure were updated to return other > 0 values for success and some < 0 values for failure, which caused some of openssl apps to . This kind of check "future-proofs" the app code from such a future change. TOM > Is anyone familiar with this function who can comment? > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From awilliam at redhat.com Thu Jan 15 21:51:44 2015 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 15 Jan 2015 13:51:44 -0800 Subject: [openssl-users] Behaviour of OpenSSL when CApath or CAfile contains a 'trusted certificate' with all uses rejected In-Reply-To: <1421326338.15361.213.camel@redhat.com> References: <1421326338.15361.213.camel@redhat.com> Message-ID: <1421358704.15361.249.camel@redhat.com> On Thu, 2015-01-15 at 04:52 -0800, Adam Williamson wrote: > If anyone can point out what I'm missing I'd be very grateful :) So I think I may actually know more or less what's going on, now. Passing -purpose to `verify` seems to really enable only *purpose* checking. It doesn't actually enable any *trust* checking. I was thrown for a while because of this, in v3_purp.c: static X509_PURPOSE xstandard[] = { {X509_PURPOSE_SSL_CLIENT, X509_TRUST_SSL_CLIENT, 0, check_purpose_ssl_client, "SSL client", "sslclient", NULL}, {X509_PURPOSE_SSL_SERVER, X509_TRUST_SSL_SERVER, 0, check_purpose_ssl_server, "SSL server", "sslserver", NULL}, {X509_PURPOSE_NS_SSL_SERVER, X509_TRUST_SSL_SERVER, 0, check_purpose_ns_ssl_server, "Netscape SSL server", "nssslserver", NULL}, {X509_PURPOSE_SMIME_SIGN, X509_TRUST_EMAIL, 0, check_purpose_smime_sign, "S/MIME signing", "smimesign", NULL}, {X509_PURPOSE_SMIME_ENCRYPT, X509_TRUST_EMAIL, 0, check_purpose_smime_encrypt, "S/MIME encryption", "smimeencrypt", NULL}, {X509_PURPOSE_CRL_SIGN, X509_TRUST_COMPAT, 0, check_purpose_crl_sign, "CRL signing", "crlsign", NULL}, {X509_PURPOSE_ANY, X509_TRUST_DEFAULT, 0, no_check, "Any Purpose", "any", NULL}, {X509_PURPOSE_OCSP_HELPER, X509_TRUST_COMPAT, 0, ocsp_helper, "OCSP helper", "ocsphelper", NULL}, {X509_PURPOSE_TIMESTAMP_SIGN, X509_TRUST_TSA, 0, check_purpose_timestamp_sign, "Time Stamp signing", "timestampsign", NULL}, which clearly associates an X509_TRUST with each X509_PURPOSE. But then I noticed that nothing ever calls X509_PURPOSE_get_trust(). So it seems like that's kind of vestigial - the association between purpose and trust is written in, and there's a function to get the trust for a given purpose, but nothing *uses* it. In my test situation, pure purpose checking will never fail any of the certs in the chain for SSL server purposes, and that's not actually wrong: they *are* valid as far as the purpose checks go. When 's_client' fails, it fails when running X509_check_trust() on the root cert, which is pretty much what you'd expect. That wouldn't happen with 'verify', not even when you pass -purpose , because nothing sets a trust from the purpose, so X509_check_trust() never gets called in this bit of X509_verify_cert(): /* The chain extensions are OK: check trust */ if (param->trust > 0) ok = check_trust(ctx); because param->trust is 0, the default for x509 per the 'default_table[]' in x509_vpm.c. Right? Whereas when using s_client, param->trust gets set to X509_TRUST_SSL_CLIENT or X509_TRUST_SSL_SERVER because those are the defaults for 'ssl_client' and 'ssl_server' in default_table[] (and if you traced that back out all the way to ssl3_connect(), it seems to always read in the defaults for either ssl_client or ssl_server from that table, boy that was fun to figure out). Basically, it seems like you can't ever cause trust checking to happen when using 'verify'. I did throw some printf()s into X509_check_trust() and check_purpose_ssl_server() and indeed I see both sets of messages when using 's_client', but I only see the messages from check_purpose_ssl_server() when using 'verify', not the ones from X509_check_trust(). (I also now see on a careful read of x509_vfy.c that purpose checks are done on all of the untrusted certs in the chain, which is why they're not done on the root CA cert, and check_trust() in 1.0.1k is run on the last cert in the chain - presumably expected to be the root CA - while in master it's run on all trusted certs in the chain. That clears up my confusion about exactly what tests were being run on what certs). So, I think I more or less understand the behaviour I'm seeing now, and in practice, I *think* it'd be safe to say that p11-kit's approach should work correctly in practice, because real-world SSL clients will be going through the SSL bits and hence getting a correct default 'trust' parameter if they don't their own. Right? I'm guessing perhaps the PURPOSE -> TRUST associations were *intended* to enable trust checking in 'verify', but this just never got finished. They, and the X509_PURPOSE_get_trust() function, both seem to have turned up in commit d4cec6a13dfb2c1d1ddf66dff499aaf21bbbf002 , in 1999: ????New options to the -verify program which can be used for chain verification.????Extend the X509_PURPOSE structure to include shortnames for purposed and default????trust ids.????????Still need some extendable trust checking code and integration with the SSL and????S/MIME code. but I'm guessing that just never quite got finished off? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net From awilliam at redhat.com Fri Jan 16 07:44:36 2015 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 15 Jan 2015 23:44:36 -0800 Subject: [openssl-users] [PATCH] apps: when -purpose is passed, set matching trust param Message-ID: <1421394276-4896-1-git-send-email-awilliam@redhat.com> All the necessary bits are in place to make this possible, they just never got wired up. With this, for instance, when you use the 'verify' sub-command to verify a certificate chain with '-purpose sslserver', error 28 will occur if the root cert is not trusted for X509_TRUST_SSL_SERVER. This matches the behaviour of actual SSL client code (e.g. 's_client') more closely. This is a follow-up to my last couple of mails where I worked all this stuff out; it turns out it's actually (seemingly) pretty trivial to go ahead and hook up the appropriate trust param when -purpose is passed. I tested this in the setup described in my earlier emails; verify functions as expected in that case. --- apps/apps.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/apps/apps.c b/apps/apps.c index ac709a6..58a1b87 100644 --- a/apps/apps.c +++ b/apps/apps.c @@ -2383,7 +2383,7 @@ int args_verify(char ***pargs, int *pargc, ASN1_OBJECT *otmp = NULL; unsigned long flags = 0; int i; - int purpose = 0, depth = -1; + int purpose = 0, trust = 0, depth = -1; char **oldargs = *pargs; char *arg = **pargs, *argn = (*pargs)[1]; const X509_VERIFY_PARAM *vpm = NULL; @@ -2424,6 +2424,7 @@ int args_verify(char ***pargs, int *pargc, { xptmp = X509_PURPOSE_get0(i); purpose = X509_PURPOSE_get_id(xptmp); + trust = X509_PURPOSE_get_trust(xptmp); } } (*pargs)++; @@ -2564,6 +2565,9 @@ int args_verify(char ***pargs, int *pargc, if (purpose) X509_VERIFY_PARAM_set_purpose(*pm, purpose); + if (trust) + X509_VERIFY_PARAM_set_trust(*pm, trust); + if (depth >= 0) X509_VERIFY_PARAM_set_depth(*pm, depth); -- 2.2.1 From vladimir.zatsepin at gmail.com Fri Jan 16 08:05:02 2015 From: vladimir.zatsepin at gmail.com (Vladimir Zatsepin) Date: Fri, 16 Jan 2015 11:05:02 +0300 Subject: [openssl-users] Client certificate Message-ID: Hi there, I am developing some app using openssl 1.0.1e now and I have a little problem with my app. A client sets SSL-connection with server and tries to get some data from it. I use client authentication during the connection establishment. I have set my custom verify callback and now I can verify client certificate chain in my own way. But can I get the client certificate after handshake? Where is it located in SSL or SSL_CTX structs? I must get this on SSL_read/SSL_write methods level -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at convey.de Fri Jan 16 08:30:40 2015 From: ted at convey.de (=?windows-1252?Q?Bernhard_Fr=F6hlich?=) Date: Fri, 16 Jan 2015 09:30:40 +0100 Subject: [openssl-users] Client certificate In-Reply-To: References: Message-ID: <54B8CC30.3030206@convey.de> Am 16.01.2015 um 09:05 schrieb Vladimir Zatsepin: > Hi there, > > I am developing some app using openssl 1.0.1e now and I have a little > problem with my app. > A client sets SSL-connection with server and tries to get some data > from it. I use client authentication during the connection > establishment. I have set my custom verify callback and now I can > verify client certificate chain in my own way. > > But can I get the client certificate after handshake? Where is it > located in SSL or SSL_CTX structs? I must get this on > SSL_read/SSL_write methods level Maybe you're looking for SSL_get_peer_certificate? Hope it helps Ted ;) -- PGP Public Key Information Key ID = 7AFB8D26 Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 From arnaud.mouiche at invoxia.com Fri Jan 16 11:56:34 2015 From: arnaud.mouiche at invoxia.com (arnaud.mouiche at invoxia.com) Date: Fri, 16 Jan 2015 12:56:34 +0100 Subject: [openssl-users] Possible bug in DSA_verify() since CVE-2014-8275 patch (present in 1.0.1k and 1.0.1l) Message-ID: <54B8FC72.8010906@invoxia.com> Hi all. I was just checking the latest 1.0.1l version (running previously the 1.0.1i). some DSA signature check done with DSA_verify() are not working any more, for at least one private/public key I'm using. The public key was generated from the private key, long time ago, as usual with command "openssl dsa -in key.priv -out key.pub -pubout" So, it is not a forged key. Here is the various things I tried / see. I someone can tell me if this is an openssl issue, or simply the way I'm using openssl lib, I will appreciate. 1) I imagine first that old generated keys are no more valid one to enforce the CVE-2014-8275 warning, yet, generating a new public key with the new openssl version lead to the same issue. 2) I try the lastest openssl-1.0.1-stable-SNAP-20150116 sources, but the issue is still here 3) trying a public key in DER format (openssl dsa -in key.priv -out key.pub -pubout -outform DER), it doesn't change anything 4) if I revert CVE-2014-8275 patch https://github.com/openssl/openssl/commit/684400ce192dac51df3d3e92b61830a6ef90be3e, it fix my issue. 5) diging in the source code diff --git a/crypto/dsa/dsa_asn1.c b/crypto/dsa/dsa_asn1.c index 473af87..a018d52 100644 --- a/crypto/dsa/dsa_asn1.c +++ b/crypto/dsa/dsa_asn1.c @@ -184,17 +184,24 @@ int DSA_verify(int type, const unsigned char *dgst, int dgst_len, s = DSA_SIG_new(); if (s == NULL) return(ret); if (d2i_DSA_SIG(&s,&p,siglen) == NULL) goto err; /* Ensure signature uses DER and doesn't have trailing garbage */ derlen = i2d_DSA_SIG(s, &der); - if (derlen != siglen || memcmp(sigbuf, der, derlen)) + if (derlen != siglen || memcmp(sigbuf, der, derlen)) { + printf(" derlen=%d siglen=%d\n", derlen, siglen); goto err; + } ret=DSA_do_verify(dgst,dgst_len,s,dsa); err: it shows: derlen=47 siglen=48. this is the reason why it failed. 5) here is the public key -----BEGIN PUBLIC KEY----- MIIBtjCCASsGByqGSM44BAEwggEeAoGBAKeSlIE9Q3ijwBOsB4ObfZW8cSsvIyDO wioNBzZOEm8AoeOVc8xROEmWqvt7TBvM6OK46qNMJTLeHOiIXaRjqosQVWEb4D4l IVjMtjpQFDAzxPsJZv6EaW/jM2ZXe6tVBanCJW/gi1NgnXpIkA5ohRqPJ+nqPR8p OPbrBERrG1bzAhUAjDqhLrONrdvTe2HJJrB9V4An0BMCgYAF6vZzaZ4GEF8urI7b ChkD0+aQZIAXBal/cBJMHI94HeYtBThT25+whfiWtEPbc99NhNAHnvGyIDVECAjZ Rx1ZhV0Wn45UExCm7S7hHZY/I/jjoQRFvtMR0e4OqJXjIykx4r1SqXgZuO4M8Tv7 VzBLz6hhMqGZ7TqdqxqLH/cd9gOBhAACgYAlJlPWDNetO1TbO5OFfbl0rvTgIlZV yWnRtIlks35f/iPkb2a7PsRUXcosvblX7Lg5oheC2m68MaEDx16XMvPmHWmvaR16 /BnX6DZHMtNDNMW6o7sce/AMhnT0PGiB1SCuugTxSt32RdDgRFcNBKUUCr47Nyor dHdD2r/2/GQqpQ== -----END PUBLIC KEY----- 6) ... and the way I'm using DSA_verify() static enum dsa_verify_result dsa_verify_helper(const char *name, const unsigned char *digest, int digest_size, const unsigned char *signature, int signature_size) { DSA * dsa = NULL; char pubkey_path[128]; FILE *F = NULL; /* try to read a PEM formatted key */ snprintf(pubkey_path, sizeof(pubkey_path), "/share/pubkey/%s.pub", name ); F = fopen( pubkey_path, "rb" ); if (F) { if (PEM_read_DSA_PUBKEY( F, &dsa, PEM_def_callback, (void *)"" )) { dbg(" find a PEM pub key"); goto dsa_verify_helper_get_a_key; } fclose( F ); F = NULL; } /* try to read a DER formatted key */ snprintf(pubkey_path, sizeof(pubkey_path), "/share/pubkey/%s.pub.der", name ); F = fopen( pubkey_path, "rb" ); if (F) { if (d2i_DSA_PUBKEY_fp( F, &dsa )) { dbg(" find a DER pub key"); goto dsa_verify_helper_get_a_key; } } /* if we are here, we failed to read a pub key */ if (F) fclose( F ); return DSA_VERIFY_NO_PUBKEY; dsa_verify_helper_get_a_key: fclose( F ); int r = DSA_verify( 0, digest, digest_size, signature, signature_size, dsa ); DSA_free( dsa ); if (r == 1) { /* ok */ return DSA_VERIFY_OK; } else { return DSA_VERIFY_BAD; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Fri Jan 16 15:16:48 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 16 Jan 2015 10:16:48 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <54B7C084.1060404@openssl.com> References: <54B7C084.1060404@openssl.com> Message-ID: <54B92B60.1020206@openssl.com> On 01/15/2015 05:52 AM, Marcus Meissner wrote: > On Thu, Jan 15, 2015 at 05:46:22AM -0500, jonetsu at teksavvy.com > wrote: >> On Tue, 13 Jan 2015 21:33:49 -0500 "jonetsu at teksavvy.com" >> wrote: >> >>> So basically every app that uses libssl will have to be modified >>> to add a FIPS_mode_set() call near the beginning. Is that right >>> ? >> >> Is there a way to automatically have the FIPS test executed when >> an application loads the library, w/o the application being >> modified ? Is such a way used at all ? > > This is actually mandated these days. For *new* validations only, older modules (such as #1747) validated before the new I.G. 9.10 interpretation remain valid. You can find an old but still relevant discussion here: http://openssl.com/fips/ig95.html > On Linux usually triggered by /proc/sys/crypto/fips_enabled > containing "1" or the environment variable OPENSSL_FORCE_FIPS_MODE=1 > (at least for the certs done by SUSE and Redhat, which do not use the > container blob). That is (presumably) true for the proprietary RH and SUSE distros; not so for the open source based OpenSSL FIPS Object Module or other Linux distros. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Fri Jan 16 18:57:08 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 16 Jan 2015 18:57:08 +0000 Subject: [openssl-users] Possible bug in DSA_verify() since CVE-2014-8275 patch (present in 1.0.1k and 1.0.1l) In-Reply-To: <54B8FC72.8010906@invoxia.com> References: <54B8FC72.8010906@invoxia.com> Message-ID: <20150116185708.GA27053@openssl.org> On Fri, Jan 16, 2015, arnaud.mouiche at invoxia.com wrote: > Hi all. > > I was just checking the latest 1.0.1l version (running previously > the 1.0.1i). > some DSA signature check done with DSA_verify() are not working any > more, for at least one private/public key I'm using. > > The public key was generated from the private key, long time ago, as > usual with command "openssl dsa -in key.priv -out key.pub -pubout" > So, it is not a forged key. > > Here is the various things I tried / see. > I someone can tell me if this is an openssl issue, or simply the way > I'm using openssl lib, I will appreciate. > > 1) I imagine first that old generated keys are no more valid one to > enforce the CVE-2014-8275 warning, yet, > generating a new public key with the new openssl version lead to the > same issue. > No this should have no effect on previous keys. CVE-2014-8275 makes signature checking for DSA/ECDSA more strict and some invalid encodings are no longer tolerated. What produced the signature that is now being rejected? Is it OpenSSL or some other library? How are you obtaining the length of the signature? There are ways to workaround the stricter checks by reencoding the signature yourself or calling DSA_do_verify after decoding the signature yourself. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From arnaud.mouiche at invoxia.com Fri Jan 16 19:19:36 2015 From: arnaud.mouiche at invoxia.com (arnaud.mouiche at invoxia.com) Date: Fri, 16 Jan 2015 20:19:36 +0100 Subject: [openssl-users] Possible bug in DSA_verify() since CVE-2014-8275 patch (present in 1.0.1k and 1.0.1l) In-Reply-To: <20150116185708.GA27053@openssl.org> References: <54B8FC72.8010906@invoxia.com> <20150116185708.GA27053@openssl.org> Message-ID: <54B96448.7080707@invoxia.com> Le 16/01/2015 19:57, Dr. Stephen Henson a ?crit : > On Fri, Jan 16, 2015, arnaud.mouiche at invoxia.com wrote: > >> Hi all. >> >> I was just checking the latest 1.0.1l version (running previously >> the 1.0.1i). >> some DSA signature check done with DSA_verify() are not working any >> more, for at least one private/public key I'm using. >> >> The public key was generated from the private key, long time ago, as >> usual with command "openssl dsa -in key.priv -out key.pub -pubout" >> So, it is not a forged key. >> >> Here is the various things I tried / see. >> I someone can tell me if this is an openssl issue, or simply the way >> I'm using openssl lib, I will appreciate. >> >> 1) I imagine first that old generated keys are no more valid one to >> enforce the CVE-2014-8275 warning, yet, >> generating a new public key with the new openssl version lead to the >> same issue. >> > No this should have no effect on previous keys. > > CVE-2014-8275 makes signature checking for DSA/ECDSA more strict and some > invalid encodings are no longer tolerated. > > What produced the signature that is now being rejected? Is it OpenSSL or some > other library? How are you obtaining the length of the signature? DSA_verify() stops at the public key length check, and don't even check the signature. I'm only using openssl tools/lib - the private key was generate few years ago with openssl (don't remember the version) - the public key was generated with openssl with "openssl dsa -in key.priv -out key.pub -pubout" and the resulting public key file, is rejected by DSA_verify() (even if I'm using last 1.0.1l version to generate this public key file - the signature is DSA signing of a sha256 hash If you want to know about the signature, it was generating by signing the hash result > > There are ways to workaround the stricter checks by reencoding the signature > yourself or calling DSA_do_verify after decoding the signature yourself. I have no issue to hack my tools to make it work by calling DSA_do_verify() directly (ie. skipping the public key length) Yet, I worry about any other software (not mine) that may failed for the same reasons, whereas working fine before. Again, the public key was generated by openssl itself. It seems wrong that openssl didn't like it now. Regards, arnaud > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From ndadoun at teradici.com Fri Jan 16 21:23:59 2015 From: ndadoun at teradici.com (Nou Dadoun) Date: Fri, 16 Jan 2015 21:23:59 +0000 Subject: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) Message-ID: <3D8643BEB2666A4C93CD59524328691001414D6BED@sterexch02.teradici.local> We are currently using FIPS and non-FIPS builds of 0.9.8 where a configuration setting can select FIPS or non-FIPS mode, loads the appropriate build and populates a function table which is used by the code for OpenSSL functionality. We would like to update the non-FIPS build to a later version (e.g. 1.0.1) which has support for TLS 1.1/1.2 (etc.) which could then co-exist with the increasingly insecure but certified FIPS build in this way. Has anybody tried this? Any gotchas come to mind? E.g. does a canister need to be used for the non-FIPS? Are there any major API changes between the two (besides APIs and/or parameter values which have been added or extended)? Is this a crazy thing to do? Thanks in advance for any relevant comments! ... N From marquess at openssl.com Fri Jan 16 22:25:44 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 16 Jan 2015 17:25:44 -0500 Subject: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) In-Reply-To: <3D8643BEB2666A4C93CD59524328691001414D6BED@sterexch02.teradici.local> References: <3D8643BEB2666A4C93CD59524328691001414D6BED@sterexch02.teradici.local> Message-ID: <54B98FE8.3040400@openssl.com> On 01/16/2015 04:23 PM, Nou Dadoun wrote: > We are currently using FIPS and non-FIPS builds of 0.9.8 where a > configuration setting can select FIPS or non-FIPS mode, loads the > appropriate build and populates a function table which is used by > the code for OpenSSL functionality. > > We would like to update the non-FIPS build to a later version (e.g. > 1.0.1) which has support for TLS 1.1/1.2 (etc.) which could then > co-exist with the increasingly insecure but certified FIPS build in > this way. > > Has anybody tried this? Any gotchas come to mind? E.g. does a > canister need to be used for the non-FIPS? Are there any major API > changes between the two (besides APIs and/or parameter values which > have been added or extended)? Is this a crazy thing to do? > > Thanks in advance for any relevant comments! ... N If I'm following here, you want to deploy something that uses OpenSSL 1.0.1 either with or without the FIPS module, as decided at runtime. That's a common enough scenario: those customers who must use FIPS will want that, all others either won't want or don't care about FIPS (some of them very specifically won't want it, for understandable reasons). You don't need two separate builds, a single build of one set of libraries can be used for both purposes. We call that the "FIPS capable" OpenSSL: build openssl 1.0.1 with the "fips" build time option in the presence of a FIPS module. You wind up with the same libcrypto and libssl libraries that you know and love. That one set of libraries can be used for either purpose: use them without calling FIPS_mode_set() and they behave like stock 1.0.1. Call FIPS_mode_set() to enable the FIPS module of operation and your application will automatically be using the embedded FIPS module (with non-approved crypto operations disabled). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From steve at openssl.org Fri Jan 16 22:42:30 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 16 Jan 2015 22:42:30 +0000 Subject: [openssl-users] Possible bug in DSA_verify() since CVE-2014-8275 patch (present in 1.0.1k and 1.0.1l) In-Reply-To: <54B96448.7080707@invoxia.com> References: <54B8FC72.8010906@invoxia.com> <20150116185708.GA27053@openssl.org> <54B96448.7080707@invoxia.com> Message-ID: <20150116224230.GA22036@openssl.org> On Fri, Jan 16, 2015, arnaud.mouiche at invoxia.com wrote: > > > If you want to know about the signature, it was generating by signing the hash result > Do you have a code snippet of how you are generating the signature? That is the code which calls DSA_sign()? I can think of one way that could be wrong. If you are using DSA_size(key) as the signature length instead of the length returned by DSA_sign() that will fail under some circumstances. That's because DSA_size() returns the maximum length of the signature whereas DSA_sign() returns the actual length which may be less. I Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From beldmit at gmail.com Sat Jan 17 08:56:42 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 17 Jan 2015 11:56:42 +0300 Subject: [openssl-users] Check private key/certificate match Message-ID: Hello, is there any simple way to check that the private key matches the certificate using command line utility? Now I use pair of smime -sign/smime -verify commands. If there is no such a way, please consider this letter as a feature request :-) Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlmeetei at gmail.com Sat Jan 17 23:00:12 2015 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Sun, 18 Jan 2015 04:30:12 +0530 Subject: [openssl-users] Which openssl to use for `void SSL_set_cert_cb` Message-ID: I am on ubuntu 14.04 with root at deleisha:/Codespace/TackleBio# openssl version OpenSSL 1.0.1f 6 Jan 2014 and I am not use SSL_set_cert_cb, the ssl.h does not have declaration for this and I am not able to link. The particular code seems to committed on 2012 http://marc.info/?l=openssl-cvs&m=133521832004237 Which version of openSSL used I used for this? or is it ubunutu packaging issue -- Warm Regards --Dev OpenPegasus Developer "I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did," Steve Jobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From shathawa at e-z.net Sun Jan 18 05:19:00 2015 From: shathawa at e-z.net (Steven J. Hathaway) Date: Sat, 17 Jan 2015 21:19:00 -0800 Subject: [openssl-users] Case-sensitive cipher names are a bad idea In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7185A4D27F8@USMBX1.msg.corp.akamai.com> <24224.208.54.32.189.1408162139.squirrel@webmail.iinet.com> Message-ID: <54BB4244.7000906@e-z.net> On 8/15/2014 10:10 PM, Jeffrey Walton wrote: > On Sat, Aug 16, 2014 at 12:08 AM, wrote: >>> ... >> Even today with Unicode character set families, the ability to provide >> a global case-independent mapping becomes a massive problem. There are >> a variety of latin-like alphabets and greek alphabets, and even >> IBM EBCDIC encodings that are much unlike the US-ASCII character set. >> Even more problematic are the cyrillic, hebrew, aramaic, asian, and >> african alphabets. Do we need to accept transliteration to these >> various alphabetic schems? >> >> Traditionally, case-independence has been the conversion of US-ASCII >> and IBM EBCDIC encodings for named strings. In documentation languages, >> the use of various Unicode tablular character sets are used. >> >> How much of this above work needs to be accomplished so that >> name case-independent and character code table independence needs >> to be accomplished. Or should we just define a character encoding >> standard for the naming conventions and stick to the definitions? > I believe they are discussing strings like used in cipher suites (for > example, "RC4-MD5"). They are 8-bit clean. > > For the upcoming hostname matching gear, IDNs must be A-label form > from RFC 6125, section 6.4.2. > > Jeff > ______________________________________________________________________ > OpenSSL Projecthttp://www.openssl.org > User Support Mailing Listopenssl-users at openssl.org > Automated List Managermajordomo at openssl.org > The general practice is to use 7-bit US_ASCII encoding or a transcoding into one of the transparent EBCDIC encoding for some mainframes based on IBM technology. Case independence is easy if you restrict yourself to the above code tables. Once you move to UTF-8 which may require an "8-bit clean" transmission, the multi-byte content maps to a set of unicode characters in the range of 0x0001 - 0x10FFFF. There are a wide number of The older SIXBIT character system may still be in use on some systems, but is mostly obsolete. Steven J. Hathaway From valentin.bud at gmail.com Sun Jan 18 10:13:08 2015 From: valentin.bud at gmail.com (Valentin Bud) Date: Sun, 18 Jan 2015 12:13:08 +0200 Subject: [openssl-users] OpenSSL LogoType extension ASN1 encoding Message-ID: Hello everyone, I am trying to add the logotype extension to certificates under a private CA I am taking care of. The CA is built using OpenVPN's Easy-RSA 3 tool, though I think that doesn't matter in this situation. I have some questions regarding this matter. Before digging into details I will tell you the problem I want to solve. I have multiple different logos. Searching the Internet I have found an E-Mail from November 2010 [1]. Based on that information I have reached to the following snippet of configuration: cat ./exts # Logos 1.3.6.1.5.5.7.1.12 = ASN1:SEQUENCE:logotype_ext [logotype_ext] issuerLogo=EXPLICIT:1,IMPLICIT:1,SEQUENCE:logotype_indirect [logotype_indirect] refStructHash=SEQWRAP,SEQUENCE:HashAlgAndValue refStructURI=SEQWRAP,SEQUENCE:IA5String:http://logos.example.org/logo0.png [HashAlgAndValue] hashAlg=SEQUENCE:logo_algid hashValue=FORMAT:HEX,OCTETSTRING:9c2c672338e1a6615ccfa78097c0ed8681e3335d [logo_algid] capabilityID = OID:sha1 parameter = NULL I receive the following error when I try to issue a certificate using openssl. The same when I use the easyrsa wrapper script. $ openssl ca -in 10.req -out 10.crt -config openssl-1.0.cnf -extfile exts -days 3650 -batch Using configuration from openssl-1.0.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'DE' organizationName :ASN.1 12:'10' organizationalUnitName:ASN.1 12:'Cortex AG Trust Network' organizationalUnitName:ASN.1 12:'(c) Cortex AG - For authorized use only!' commonName :ASN.1 12:'Cortex AG Root Certification Authority' ERROR: adding extensions in section default 6987:error:22074074:X509 V3 routines:V3_GENERIC_EXTENSION:extension value error:/SourceCache/OpenSSL098/OpenSSL098-52/src/crypto/x509v3/v3_conf.c:282:value=SEQUENCE:logotype_ext I have tried changing SEQWRAP with SEQUENCE and also variations I have found in [1]. None of them worked. Can someone please tell me what am I doing wrong. Also I have a couple of logos I want to add to the certificate. How would I encode that in openssl.cnf? [1]: http://openssl.6102.n7.nabble.com/Logotype-encoding-td15882.html Thank you, Valentin Bud -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Jan 18 18:02:20 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 18 Jan 2015 18:02:20 +0000 Subject: [openssl-users] Check private key/certificate match In-Reply-To: References: Message-ID: <20150118180220.GC29286@mournblade.imrryr.org> On Sat, Jan 17, 2015 at 11:56:42AM +0300, Dmitry Belyavsky wrote: > Is there any simple way to check that the private key matches the > certificate using command line utility? Now I use pair of smime -sign/smime > -verify commands. Depends on what you call "simple". certspkihash=$( openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02X"' ) keyspkihash=$( openssl pkey -in key.pem -pubout -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02X"' ) if [ "$certspkihash" != "$keyspkihash" ]; then # Error key and cert don't match echo "The sky is falling" >&2 exit 1 fi # Good, key and cert match ... Obviously if the private key is password protected you'll be prompted for that password. The above does not involve any signatures, just compares the SHA2-256 digest of the public key in the certificate with the SHA2-256 digest of the public part of the key. AFAIK there is not a single command that does this at present. -- Viktor. From noloader at gmail.com Sun Jan 18 20:00:37 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 18 Jan 2015 15:00:37 -0500 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE Message-ID: In the code below from s3_both.c, what would cause the SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE)? I'm having trouble understanding the 'reuse_message', and what satisfies the condition 'tmp.message_type != mt' (i.e., what causes the failure). Jeff ========== long ssl3_get_message(SSL *s, int st1, int stn, int mt, long max, int *ok) { unsigned char *p; unsigned long l; long n; int i,al; if (s->s3->tmp.reuse_message) { s->s3->tmp.reuse_message=0; if ((mt >= 0) && (s->s3->tmp.message_type != mt)) { al=SSL_AD_UNEXPECTED_MESSAGE; SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); goto f_err; } *ok=1; s->init_msg = s->init_buf->data + 4; s->init_num = (int)s->s3->tmp.message_size; return s->init_num; } ... From noloader at gmail.com Sun Jan 18 20:13:10 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 18 Jan 2015 15:13:10 -0500 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE In-Reply-To: References: Message-ID: My bad... I think this is the code (from around line 500 in s3_both.c): /* s->init_num == 4 */ if ((mt >= 0) && (*p != mt)) { al=SSL_AD_UNEXPECTED_MESSAGE; SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); goto f_err; } What would cause this error on a client? On Sun, Jan 18, 2015 at 3:00 PM, Jeffrey Walton wrote: > In the code below from s3_both.c, what would cause the > SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE)? > > I'm having trouble understanding the 'reuse_message', and what > satisfies the condition 'tmp.message_type != mt' (i.e., what causes > the failure). > From matt at openssl.org Sun Jan 18 20:25:36 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 18 Jan 2015 20:25:36 +0000 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE In-Reply-To: References: Message-ID: <54BC16C0.7070004@openssl.org> On 18/01/15 20:13, Jeffrey Walton wrote: > My bad... I think this is the code (from around line 500 in s3_both.c): > > /* s->init_num == 4 */ > if ((mt >= 0) && (*p != mt)) > { > al=SSL_AD_UNEXPECTED_MESSAGE; > SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); > goto f_err; > } > > What would cause this error on a client? > The client has an internal state machine which tells it what message it should expect next from the server based on its current state. Only certain messages are legal at any one time. The variable mt holds the message type of the message it is expecting to receive. The variable p points into the message buffer for the message that it has actually received. If the message sent from the server doesn't match the one the client was expecting then you get this error. Matt From noloader at gmail.com Sun Jan 18 21:58:38 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 18 Jan 2015 16:58:38 -0500 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE In-Reply-To: <54BC16C0.7070004@openssl.org> References: <54BC16C0.7070004@openssl.org> Message-ID: On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell wrote: > > > On 18/01/15 20:13, Jeffrey Walton wrote: >> My bad... I think this is the code (from around line 500 in s3_both.c): >> >> /* s->init_num == 4 */ >> if ((mt >= 0) && (*p != mt)) >> { >> al=SSL_AD_UNEXPECTED_MESSAGE; >> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); >> goto f_err; >> } >> >> What would cause this error on a client? >> > > The client has an internal state machine which tells it what message it > should expect next from the server based on its current state. Only > certain messages are legal at any one time. The variable mt holds the > message type of the message it is expecting to receive. The variable p > points into the message buffer for the message that it has actually > received. If the message sent from the server doesn't match the one the > client was expecting then you get this error. Thanks Matt. Have you guys (the devs) seen this failure in the field during testing? If so, what's a typical configuration to cause it? Or what's the offending server message? The server is using OpenSSL 1.0.1e-fips 11 Feb 2013, Thu Nov 6 12:33:36 UTC 2014. The client is Android 5.0. Down level Android versions are OK. s_client is OK. Jeff From matt at openssl.org Sun Jan 18 23:13:17 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 18 Jan 2015 23:13:17 +0000 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE In-Reply-To: References: <54BC16C0.7070004@openssl.org> Message-ID: <54BC3E0D.10202@openssl.org> On 18/01/15 21:58, Jeffrey Walton wrote: > On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell wrote: >> >> >> On 18/01/15 20:13, Jeffrey Walton wrote: >>> My bad... I think this is the code (from around line 500 in s3_both.c): >>> >>> /* s->init_num == 4 */ >>> if ((mt >= 0) && (*p != mt)) >>> { >>> al=SSL_AD_UNEXPECTED_MESSAGE; >>> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); >>> goto f_err; >>> } >>> >>> What would cause this error on a client? >>> >> >> The client has an internal state machine which tells it what message it >> should expect next from the server based on its current state. Only >> certain messages are legal at any one time. The variable mt holds the >> message type of the message it is expecting to receive. The variable p >> points into the message buffer for the message that it has actually >> received. If the message sent from the server doesn't match the one the >> client was expecting then you get this error. > > Thanks Matt. > > Have you guys (the devs) seen this failure in the field during > testing? If so, what's a typical configuration to cause it? Or what's > the offending server message? No - I've not seen it. > > The server is using OpenSSL 1.0.1e-fips 11 Feb 2013, Thu Nov 6 > 12:33:36 UTC 2014. The client is Android 5.0. Down level Android > versions are OK. s_client is OK. So - just to clarify: Is the client openssl too? Which side is sending the alert? Having just reread your earlier comment I'm not clear if you meant the client sent the alert, or the client received the alert. Are you able to capture the handshake packets? Matt From Avery.A.Tarasov at SecurityEngineer.Pro Sun Jan 18 23:14:24 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Sun, 18 Jan 2015 18:14:24 -0500 Subject: [openssl-users] Is CRYPTO_set_locking_callback still needed if mutexes in threads are already being used to prevent race conditions? Message-ID: <1e85d7495153beb3ff4b2a957c594963@smtp.hushmail.com> Hi, I am developing a Windows C++ application that uses OpenSSL. The application has 2 threads created by CreateThread that perform SSL functions such as connecting to a website over HTTPS and sending/receiving data I am already using a mutex to prevent race conditions, like this: static HANDLE sslmutex=0; // global variable at top of file *inside thread #1:* while(1) { WaitForSingleObject(sslmutex,INFINITE); DoSsl(); ReleaseMutex(sslmutex); Sleep(1000); } *inside thread #2:* while(1) { WaitForSingleObject(sslmutex,INFINITE); DoSsl(); ReleaseMutex(sslmutex); Sleep(1000); } All SSL related code is in the DoSsl function including SSL_library_init(), sending/receiving data, and necessary clean up operations. Is it still necessary for me to use CRYPTO_set_locking_callback or is my code already thread safe? Any assistance greatly appreciated. Best Regards, -Avery -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Jan 19 00:35:09 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 18 Jan 2015 19:35:09 -0500 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE In-Reply-To: <54BC3E0D.10202@openssl.org> References: <54BC16C0.7070004@openssl.org> <54BC3E0D.10202@openssl.org> Message-ID: On Sun, Jan 18, 2015 at 6:13 PM, Matt Caswell wrote: > > > On 18/01/15 21:58, Jeffrey Walton wrote: >> On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell wrote: >>> >>> >>> On 18/01/15 20:13, Jeffrey Walton wrote: >>>> My bad... I think this is the code (from around line 500 in s3_both.c): >>>> >>>> /* s->init_num == 4 */ >>>> if ((mt >= 0) && (*p != mt)) >>>> { >>>> al=SSL_AD_UNEXPECTED_MESSAGE; >>>> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); >>>> goto f_err; >>>> } >>>> >>>> What would cause this error on a client? >>>> >>> >>> The client has an internal state machine which tells it what message it >>> should expect next from the server based on its current state. Only >>> certain messages are legal at any one time. The variable mt holds the >>> message type of the message it is expecting to receive. The variable p >>> points into the message buffer for the message that it has actually >>> received. If the message sent from the server doesn't match the one the >>> client was expecting then you get this error. >> >> Thanks Matt. >> >> Have you guys (the devs) seen this failure in the field during >> testing? If so, what's a typical configuration to cause it? Or what's >> the offending server message? > > No - I've not seen it. > >> >> The server is using OpenSSL 1.0.1e-fips 11 Feb 2013, Thu Nov 6 >> 12:33:36 UTC 2014. The client is Android 5.0. Down level Android >> versions are OK. s_client is OK. > > So - just to clarify: Is the client openssl too? Which side is sending > the alert? Having just reread your earlier comment I'm not clear if you > meant the client sent the alert, or the client received the alert. My bad... The Android 5.0 client uses OpenSSL too (but I'm not sure what version). Client and server are trying to negotiate TLS 1.2 with EC. The server closes the connection after it sends it ServerHello. The server selects TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA in its ServerHello. > Are you able to capture the handshake packets? Yes. Here's what's happening on the wire: * Three way handshake * ClientHello * Server ACK of previous client messages (1 each ACK, three different segments) * ServerHello * Client ACK of previous server messages (4 each ACK, four different segments) * Server closes connection I think what I'm seeing is artifacts of: * http://rt.openssl.org/Ticket/Display.html?id=3022&user=guest&password=guest * https://bugzilla.redhat.com/show_bug.cgi?id=1045363 I don't really know where to post a PCAP and not torture you with the download from file sharing gimmicks, so I'll defer. I'm open to non-gimmicky file sharing sites if you have a suggestion. Jeff From noloader at gmail.com Mon Jan 19 01:29:08 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 18 Jan 2015 20:29:08 -0500 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE In-Reply-To: References: <54BC16C0.7070004@openssl.org> <54BC3E0D.10202@openssl.org> Message-ID: On Sun, Jan 18, 2015 at 7:35 PM, Jeffrey Walton wrote: > On Sun, Jan 18, 2015 at 6:13 PM, Matt Caswell wrote: >> >> >> On 18/01/15 21:58, Jeffrey Walton wrote: >>> On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell wrote: >>>> >>>> >>>> On 18/01/15 20:13, Jeffrey Walton wrote: >>>>> My bad... I think this is the code (from around line 500 in s3_both.c): >>>>> >>>>> /* s->init_num == 4 */ >>>>> if ((mt >= 0) && (*p != mt)) >>>>> { >>>>> al=SSL_AD_UNEXPECTED_MESSAGE; >>>>> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); >>>>> goto f_err; >>>>> } >>>>> >>>>> What would cause this error on a client? >>>>> >>>> >>>> The client has an internal state machine which tells it what message it >>>> should expect next from the server based on its current state. Only >>>> certain messages are legal at any one time. The variable mt holds the >>>> message type of the message it is expecting to receive. The variable p >>>> points into the message buffer for the message that it has actually >>>> received. If the message sent from the server doesn't match the one the >>>> client was expecting then you get this error. >>> >>> Thanks Matt. >>> >>> Have you guys (the devs) seen this failure in the field during >>> testing? If so, what's a typical configuration to cause it? Or what's >>> the offending server message? >> >> No - I've not seen it. >> >>> >>> The server is using OpenSSL 1.0.1e-fips 11 Feb 2013, Thu Nov 6 >>> 12:33:36 UTC 2014. The client is Android 5.0. Down level Android >>> versions are OK. s_client is OK. >> >> So - just to clarify: Is the client openssl too? Which side is sending >> the alert? Having just reread your earlier comment I'm not clear if you >> meant the client sent the alert, or the client received the alert. > > My bad... The Android 5.0 client uses OpenSSL too (but I'm not sure > what version). Client and server are trying to negotiate TLS 1.2 with > EC. > * Three way handshake > * ClientHello > * Server ACK of previous client messages (1 each ACK, three different segments) > * ServerHello > * Client ACK of previous server messages (4 each ACK, four different segments) > * Server closes connection My bad again. The client closes the connection, not the server. The "4 each ACKs" cover up to bytes 5719 (Seq 195, ACK 5719). That's the `ServerHello`. Then the client performs an ACK, FIN on the same (Seq 195, ACK 5719). That's when the client begins processing the `ServerHello`. Looking at a "good" exchange (TLS 1.0 client with the server) and the "bad" exchange (TLS 1.2 client with the server), they look the same to me (modulo the different cipher suite). The Record Layer looks well formed, and the Handshake Protocol messages look well formed. And I don't see any extra bytes. The Server's Hello does have a renegotiation_info extension for TLS 1.2 that's missing from TLS 1.0. Is RI supposed to be empty? If it is, then I am seeing a length of 1 - the NULL byte. Jeff From NCarboni at ProDigitalSoftware.com Mon Jan 19 03:17:28 2015 From: NCarboni at ProDigitalSoftware.com (Noel Carboni) Date: Sun, 18 Jan 2015 22:17:28 -0500 Subject: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() Message-ID: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> Hello, this is my first post to this list. I'm a software developer. The product line I'm developing indirectly uses OpenSSL through a 3rd party library. Specifically, the library does a decryption of a license file right at the startup of our application. Trouble is, the OpenSSL startup is taking over 1 second on a modern computer running Windows 8.1 x64. 1 second doesn't sound like much, but that's time our user has to wait every time to see our user interface. The entire rest of our startup logic literally takes a few tens of milliseconds. It's making our application sluggish, and we need the license file verified before the application starts up. We tracked the delay down to OpenSSL's entropy gathering heap walking logic in the RAND_poll() function in rand_win.c. The Heap32First() and Heap32Next() Windows API calls are monstrously inefficient - each iteration taking a significant part of a second just to return a pointer to the first or next heap entry. Since the logic attempts to walk through the entire heap, it doesn't take many calls at all to exceed the MAXDELAY time of 1000 milliseconds (one full second). I have the impression, looking at the RAND_poll() code, that the MAXDELAY of 1000 milliseconds is a "watchdog" timeout meant to prevent a complete lockup under some unspecified condition, and it is not expected to be exercised in the normal case. Researching a bit further, MAXDELAY appears to have been added to RAND_Poll() some 5+ years ago. As a source of entropy, the number of bytes that COULD be "added" together by RAND_add() in the heap walking loop should be monstrous - millions or even billions. But in practice that's just not happening, since it's taking so long to get the pointers. It literally can just be a few thousands of bytes. So... Two things: 1. Since Heap32First() and Heap32Next() move glacially, not very many heap blocks are traversed in 1000 milliseconds (possibly only one or a handful on an average computer). This implies the heap walking loop is a VERY poor source of entropy given the amount of CPU time spent. I'm no expert on entropy, but this appears to reduce the security of the library. 2. The library in our case is being used in a client application where (unlike a server that starts OpenSSL up once and stays up) it's initialized every time the application is opened, and so the startup time is important. Can the watchdog timeout for the heap walk loop be reduced to something more reasonable? Say 100 milliseconds? It's pretty clear that if a more efficient method is implemented to walk through heap blocks, a LOT more entropy can be gathered in a LOT less time. Bear in mind also that computers are a LOT faster than they were even 5 years ago when the 1 second MAXDELAY timeout was first implemented. If need be, I can likely put together source code to accomplish the above. Thanks. -Noel Carboni ProDigital Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Jan 19 04:18:26 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 18 Jan 2015 23:18:26 -0500 Subject: [openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE In-Reply-To: <54BC16C0.7070004@openssl.org> References: <54BC16C0.7070004@openssl.org> Message-ID: On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell wrote: > > > On 18/01/15 20:13, Jeffrey Walton wrote: >> My bad... I think this is the code (from around line 500 in s3_both.c): >> >> /* s->init_num == 4 */ >> if ((mt >= 0) && (*p != mt)) >> { >> al=SSL_AD_UNEXPECTED_MESSAGE; >> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE); >> goto f_err; >> } >> >> What would cause this error on a client? >> > > The client has an internal state machine which tells it what message it > should expect next from the server based on its current state. Only > certain messages are legal at any one time. The variable mt holds the > message type of the message it is expecting to receive. The variable p > points into the message buffer for the message that it has actually > received. If the message sent from the server doesn't match the one the > client was expecting then you get this error. > Thanks again Matt. So it appears the Android client is using OpenSSL 1.0.0. It also appears the client advertizes the curve zoo, and the server selects secp521r1. I'd like to test with the server using only secp256r1. Is there a way to disable curves through a configuration file? I'd like to have the server only use the one curve. From noloader at gmail.com Mon Jan 19 05:02:05 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 19 Jan 2015 00:02:05 -0500 Subject: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() In-Reply-To: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> References: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> Message-ID: On Sun, Jan 18, 2015 at 10:17 PM, Noel Carboni wrote: > ... > Trouble is, the OpenSSL startup is taking over 1 second on a modern computer > running Windows 8.1 x64. > ... > > We tracked the delay down to OpenSSL's entropy gathering heap walking logic > in the RAND_poll() function in rand_win.c. The Heap32First() and > Heap32Next() Windows API calls are monstrously inefficient - each iteration > taking a significant part of a second just to return a pointer to the first > or next heap entry. Since the logic attempts to walk through the entire > heap, it doesn't take many calls at all to exceed the MAXDELAY time of 1000 > milliseconds (one full second). You should seed OpenSSL's random number generator directly using CryptGenRandom (and other entropy you might have). Once the generator is seeded, it won't attempt to auto-seed itself with the RAND_poll gear. Also see http://wiki.openssl.org/index.php/Random_Numbers. It advises that you seed the generator directly rather than depending on the library doing it through RAND_poll. Jeff From arnaud.mouiche at invoxia.com Mon Jan 19 13:31:54 2015 From: arnaud.mouiche at invoxia.com (arnaud.mouiche at invoxia.com) Date: Mon, 19 Jan 2015 14:31:54 +0100 Subject: [openssl-users] Possible bug in DSA_verify() since CVE-2014-8275 patch (present in 1.0.1k and 1.0.1l) In-Reply-To: <20150116224230.GA22036@openssl.org> References: <54B8FC72.8010906@invoxia.com> <20150116185708.GA27053@openssl.org> <54B96448.7080707@invoxia.com> <20150116224230.GA22036@openssl.org> Message-ID: <54BD074A.1000606@invoxia.com> Sorry, I didn't get my brain last friday. I was thinking the length enforcement concerns the public key, whereas it concerns the signature... stupid. Indeed, in the streaming format I'm using, signature is stored on a fixed size field which is equal to DSA_size(). padding with \x00 is used to complete the signature, and unfortunately, the real signature length was not stored, thinking it was redundant with the information stored in the ASN1 format. Thank you for helping me to point this flaw. arnaud Le 16/01/2015 23:42, Dr. Stephen Henson a ?crit : > On Fri, Jan 16, 2015, arnaud.mouiche at invoxia.com wrote: > >> >> If you want to know about the signature, it was generating by signing the hash result >> > Do you have a code snippet of how you are generating the signature? That is > the code which calls DSA_sign()? > > I can think of one way that could be wrong. If you are using DSA_size(key) as > the signature length instead of the length returned by DSA_sign() that will > fail under some circumstances. That's because DSA_size() returns the > maximum length of the signature whereas DSA_sign() returns the actual > length which may be less. I > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Mon Jan 19 14:24:35 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 19 Jan 2015 14:24:35 +0000 Subject: [openssl-users] Possible bug in DSA_verify() since CVE-2014-8275 patch (present in 1.0.1k and 1.0.1l) In-Reply-To: <54BD074A.1000606@invoxia.com> References: <54B8FC72.8010906@invoxia.com> <20150116185708.GA27053@openssl.org> <54B96448.7080707@invoxia.com> <20150116224230.GA22036@openssl.org> <54BD074A.1000606@invoxia.com> Message-ID: <20150119142435.GA22318@openssl.org> On Mon, Jan 19, 2015, arnaud.mouiche at invoxia.com wrote: > Indeed, in the streaming format I'm using, signature is stored on a > fixed size field which is equal to DSA_size(). > padding with \x00 is used to complete the signature, and > unfortunately, the real signature length was not stored, thinking it > was redundant with the information stored in the ASN1 format. > > Thank you for helping me to point this flaw. > Thanks for the update. The length information is encoded in the ASN.1 structrue but the fix for CVE-2014-8275 means that the supplied buffer length now has to be precise: it can't contain any trailing data. FYI it is possible to retrieve the "real length" of the DSA signature if you pad it in this way by decoding the result. Something like this (note: untested): const unsigned char *p = buf; DSA_SIG *s = d2i_DSA_SIG(NULL, &p, buflen); if (!s) /* Error */ DSA_SIG_free(s); real_sig_len = p - buf; Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From NCarboni at ProDigitalSoftware.com Mon Jan 19 15:48:54 2015 From: NCarboni at ProDigitalSoftware.com (Noel Carboni) Date: Mon, 19 Jan 2015 10:48:54 -0500 Subject: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() In-Reply-To: References: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> Message-ID: <001601d033ff$70ea3a60$52beaf20$@ProDigitalSoftware.com> > You should seed OpenSSL's random number generator directly using CryptGenRandom (and other entropy you might have). > Once the generator is seeded, it won't attempt to auto-seed itself with the RAND_poll gear. Thank you for that workaround advice, Jeff. I've passed it on to the folks using the library calls. The OpenSSL library developers might still want to consider alternate heap walk coding, if for no other reason than for those who use the library without having seen the wiki page mentioned and knowing they should seed it themselves. The library designers may feel the 1 second used in RAND_poll() is time well spent adding up memory blocks, when mostly it's just wasted. We measured a 1000 to 1 ratio between the time spent in Heap32Next() retrieving memory block pointers and the time spent accumulating entropy in RAND_add(). Thanks again. -Noel -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jeffrey Walton Sent: Mon, January 19, 2015 12:02 AM To: OpenSSL Users List Subject: Re: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() You should seed OpenSSL's random number generator directly using CryptGenRandom (and other entropy you might have). Once the generator is seeded, it won't attempt to auto-seed itself with the RAND_poll gear. Also see http://wiki.openssl.org/index.php/Random_Numbers. It advises that you seed the generator directly rather than depending on the library doing it through RAND_poll. Jeff From rsalz at akamai.com Mon Jan 19 16:45:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 19 Jan 2015 16:45:06 +0000 Subject: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() In-Reply-To: <001601d033ff$70ea3a60$52beaf20$@ProDigitalSoftware.com> References: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> <001601d033ff$70ea3a60$52beaf20$@ProDigitalSoftware.com> Message-ID: > The OpenSSL library developers might still want to consider alternate heap > walk coding See http://rt.openssl.org/Ticket/Display.html?id=3594 From NCarboni at ProDigitalSoftware.com Mon Jan 19 16:53:48 2015 From: NCarboni at ProDigitalSoftware.com (Noel Carboni) Date: Mon, 19 Jan 2015 11:53:48 -0500 Subject: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() In-Reply-To: References: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> <001601d033ff$70ea3a60$52beaf20$@ProDigitalSoftware.com> Message-ID: <001901d03408$84ce9c20$8e6bd460$@ProDigitalSoftware.com> > See http://rt.openssl.org/Ticket/Display.html?id=3594 As a new mailing list user, I don't seem to have an account capable of viewing that ticket. The login interface does not take my mailing list credentials. Can I assume it's a discussion of this very problem? If so, that's good. -Noel From skneizys at ferrilli.com Mon Jan 19 17:02:18 2015 From: skneizys at ferrilli.com (Steven Kneizys) Date: Mon, 19 Jan 2015 12:02:18 -0500 Subject: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() In-Reply-To: <001901d03408$84ce9c20$8e6bd460$@ProDigitalSoftware.com> References: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> <001601d033ff$70ea3a60$52beaf20$@ProDigitalSoftware.com> <001901d03408$84ce9c20$8e6bd460$@ProDigitalSoftware.com> Message-ID: It seems that user "guest" password "guest" allows one the ability to view it. On Mon, Jan 19, 2015 at 11:53 AM, Noel Carboni < NCarboni at prodigitalsoftware.com> wrote: > > See http://rt.openssl.org/Ticket/Display.html?id=3594 > > As a new mailing list user, I don't seem to have an account capable of > viewing that ticket. The login interface does not take my > mailing list credentials. Can I assume it's a discussion of this very > problem? If so, that's good. > > -Noel > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Steve Kneizys Senior Business Process Engineer @ Ferrilli Voice: (610) 256-1396 [For Emergency Service (888)864-3282] web: http://www.ferrilli.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From NCarboni at ProDigitalSoftware.com Mon Jan 19 17:11:00 2015 From: NCarboni at ProDigitalSoftware.com (Noel Carboni) Date: Mon, 19 Jan 2015 12:11:00 -0500 Subject: [openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll() In-Reply-To: References: <003e01d03396$7a196520$6e4c2f60$@ProDigitalSoftware.com> <001601d033ff$70ea3a60$52beaf20$@ProDigitalSoftware.com> <001901d03408$84ce9c20$8e6bd460$@ProDigitalSoftware.com> Message-ID: <001f01d0340a$eb5f40f0$c21dc2d0$@ProDigitalSoftware.com> Perfect! http://rt.openssl.org/Ticket/Display.html?id=3594 &user=guest&pass=guest Seems like the problem is well in hand. Thanks for the conversation, guys! -Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndadoun at teradici.com Mon Jan 19 17:42:28 2015 From: ndadoun at teradici.com (Nou Dadoun) Date: Mon, 19 Jan 2015 17:42:28 +0000 Subject: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) In-Reply-To: <54B98FE8.3040400@openssl.com> References: <3D8643BEB2666A4C93CD59524328691001414D6BED@sterexch02.teradici.local> <54B98FE8.3040400@openssl.com> Message-ID: <3D8643BEB2666A4C93CD59524328691001414D7252@sterexch02.teradici.local> The scenario that we're contemplating is having FIPS based on 0.9.8?? coexist with 1.0.1?? so the remapping at runtime would have to account for api differences within the two. This was really the upshot of my question. But I think I'm still a little confused about the FIPS-certification of OpenSSL 1.0.1??, I remember reading that some of the FIPS power on self-test requirements precluded a general FIPS certification, is that the case? What is the status of FIPS OpenSSL certification? (Is this written up anywhere?) Thanks again ... N -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess Sent: January-16-15 2:26 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) On 01/16/2015 04:23 PM, Nou Dadoun wrote: > We are currently using FIPS and non-FIPS builds of 0.9.8 where a > configuration setting can select FIPS or non-FIPS mode, loads the > appropriate build and populates a function table which is used by the > code for OpenSSL functionality. > > We would like to update the non-FIPS build to a later version (e.g. > 1.0.1) which has support for TLS 1.1/1.2 (etc.) which could then > co-exist with the increasingly insecure but certified FIPS build in > this way. > > Has anybody tried this? Any gotchas come to mind? E.g. does a > canister need to be used for the non-FIPS? Are there any major API > changes between the two (besides APIs and/or parameter values which > have been added or extended)? Is this a crazy thing to do? > > Thanks in advance for any relevant comments! ... N If I'm following here, you want to deploy something that uses OpenSSL 1.0.1 either with or without the FIPS module, as decided at runtime. That's a common enough scenario: those customers who must use FIPS will want that, all others either won't want or don't care about FIPS (some of them very specifically won't want it, for understandable reasons). You don't need two separate builds, a single build of one set of libraries can be used for both purposes. We call that the "FIPS capable" OpenSSL: build openssl 1.0.1 with the "fips" build time option in the presence of a FIPS module. You wind up with the same libcrypto and libssl libraries that you know and love. That one set of libraries can be used for either purpose: use them without calling FIPS_mode_set() and they behave like stock 1.0.1. Call FIPS_mode_set() to enable the FIPS module of operation and your application will automatically be using the embedded FIPS module (with non-approved crypto operations disabled). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From oyljerry at gmail.com Tue Jan 20 05:34:24 2015 From: oyljerry at gmail.com (Jerry OELoo) Date: Tue, 20 Jan 2015 13:34:24 +0800 Subject: [openssl-users] Read cer file failed Message-ID: Hi All: I am reading cer file into X509 object, http://SVRSecure-G3-aia.verisign.com/SVRSecureG3.cer cert = d2i_X509_fp(fp, NULL); it will return fail, as below Error: error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long Lib: asn1 encoding routines Func: ASN1_get_object Reason: header too long I use openssl to convert cer from DER format to PEM format it works fine, So I think it is a DER format file, but why d2i_X509_fp() read it failed. Thanks! -- Rejoice,I Desire! From gayathri.annur at gmail.com Tue Jan 20 09:12:16 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Tue, 20 Jan 2015 14:42:16 +0530 Subject: [openssl-users] ntp-kegen fails in OpenSSL 1.0.1e-FIPs Message-ID: Hi All, For doing ntp authentication, I have used ntp-keygen command to create the keys. But this is failing in fips enabled system with RSA_BUILTIN_KEYGEN:bad e value error. # ntp-keygen -S RSA -m 2048 -p serverpassword -c RSA-SHA1 -C aes-128-cbc Using OpenSSL version *OpenSSL 1.0.1e-fips* 11 Feb 2013 Using host cm-38 group cm-38 Generating RSA keys (2048 bits)... RSA generate keys fails error:04081065:rsa routines:RSA_BUILTIN_KEYGEN:bad e value Generating host key fails # Its working fine in OpenSSL 1.0.0-fips Thanks, Gayathri -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Tue Jan 20 13:57:06 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 20 Jan 2015 13:57:06 +0000 Subject: [openssl-users] Read cer file failed In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jerry OELoo > Sent: Tuesday, January 20, 2015 00:34 > To: openssl-users at openssl.org > Subject: [openssl-users] Read cer file failed > > I am reading cer file into X509 object, > http://SVRSecure-G3-aia.verisign.com/SVRSecureG3.cer > > cert = d2i_X509_fp(fp, NULL); > it will return fail, as below What's the platform? What are the parameters to the fopen that you used to get fp? -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From marquess at openssl.com Tue Jan 20 16:16:31 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 20 Jan 2015 11:16:31 -0500 Subject: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) In-Reply-To: <3D8643BEB2666A4C93CD59524328691001414D7252@sterexch02.teradici.local> References: <3D8643BEB2666A4C93CD59524328691001414D6BED@sterexch02.teradici.local> <54B98FE8.3040400@openssl.com> <3D8643BEB2666A4C93CD59524328691001414D7252@sterexch02.teradici.local> Message-ID: <54BE7F5F.3090709@openssl.com> On 01/19/2015 12:42 PM, Nou Dadoun wrote: > The scenario that we're contemplating is having FIPS based on 0.9.8?? > coexist with 1.0.1?? so the remapping at runtime would have to > account for api differences within the two. This was really the > upshot of my question. The 1.2 FIPS module ("FIPS based on 0.9.8") is not compatible with OpenSSL 1.0.1. You need the 2.0 FIPS module for that. > But I think I'm still a little confused about the FIPS-certification > of OpenSSL 1.0.1??,... It's "validation", not "certification". > I remember reading that some of the FIPS power on > self-test requirements precluded a general FIPS certification, is > that the case? ... I think you're conflating several issues here. What you're probably referring to is the fact that some new requirements for *new* FIPS 140-2 validations (IG 9.10 among them) mean that the source code for the 2.0 FIPS module can no longer be used as-is for new validations. Those new requirements have impacted those vendors desiring to pursue such "private label" or "copycat" validations, but has not affected the original 2.0 FIPS module that was used as the model for such private label validations. > What is the status of FIPS OpenSSL certification? > (Is this written up anywhere?) The OpenSSL FIPS Object Module v2.0, validation certificate #1747, remains available for use with (to date) 102 formally tested platforms: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From chris.hall.list at highwayman.com Tue Jan 20 17:19:37 2015 From: chris.hall.list at highwayman.com ('Chris Hall') Date: Tue, 20 Jan 2015 17:19:37 -0000 Subject: [openssl-users] EVP_aes_256_gcm -- receiving of tag Message-ID: <128701d034d5$479cef50$d6d6cdf0$@highwayman.com> I find that the EVP_aes_256_gcm for decrypt requires the Tag to be set before the first call of EVP_DecryptUpdate(), and EVP_DecryptFinal_ex() with then return 0 if the Tag is found to be incorrect. I was hoping to be able to get the Tag, by EVP_CTRL_GET_TAG, but the documentation say that only works for encryption. Is there a way of reaching into (or below) the EVP stuff, to (a) prevent EVP_DecryptFinal_ex() from requiring and checking the Tag, and (b) getting the Tag after EVP_DecryptFinal_ex() -- same like after EVP_EncryptFinal_ex() ? I ask because I have an application which encrypts an arbitrary amount of data and starts sending it before all of it has been encrypted. What I have found so far seems to require me to receive all the cipher-text, and only when the Tag (finally) arrives, can I start to decrypt :-( Thanks, Chris From ndadoun at teradici.com Tue Jan 20 20:00:39 2015 From: ndadoun at teradici.com (Nou Dadoun) Date: Tue, 20 Jan 2015 20:00:39 +0000 Subject: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) In-Reply-To: <54BE7F5F.3090709@openssl.com> References: <3D8643BEB2666A4C93CD59524328691001414D6BED@sterexch02.teradici.local> <54B98FE8.3040400@openssl.com> <3D8643BEB2666A4C93CD59524328691001414D7252@sterexch02.teradici.local> <54BE7F5F.3090709@openssl.com> Message-ID: <3D8643BEB2666A4C93CD59524328691001414D7A2C@sterexch02.teradici.local> Thanks for the clarification, a couple of short questions - We already have a "shim" to index into the function table that gets loaded after run-time selecting from the 0.9.8 FIPS vs non-FIPS dll to use. I imagined that we might have to "thicken" the shim to accommodate selection between 0.9.8-FIPS and 1.0.1 non-FIPS (unorthodox I know but a potential short term step forward). Couldn't they be made interchangeable with appropriate changes to the shim or is there some more fundamental incompatibility? I looked at the link you provided for OpenSSL FIPS Object Module v2.0, validation certificate #1747 (thanks very much for that); another interesting consideration but I was surprised to notice that omitted from the list of supported algorithms was any mention of SHA, is no variant of SHA supported at all? Thanks again ... N -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess Sent: January-20-15 8:17 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) On 01/19/2015 12:42 PM, Nou Dadoun wrote: > The scenario that we're contemplating is having FIPS based on 0.9.8?? > coexist with 1.0.1?? so the remapping at runtime would have to account > for api differences within the two. This was really the upshot of my > question. The 1.2 FIPS module ("FIPS based on 0.9.8") is not compatible with OpenSSL 1.0.1. You need the 2.0 FIPS module for that. > But I think I'm still a little confused about the FIPS-certification > of OpenSSL 1.0.1??,... It's "validation", not "certification". > I remember reading that some of the FIPS power on self-test > requirements precluded a general FIPS certification, is that the case? > ... I think you're conflating several issues here. What you're probably referring to is the fact that some new requirements for *new* FIPS 140-2 validations (IG 9.10 among them) mean that the source code for the 2.0 FIPS module can no longer be used as-is for new validations. Those new requirements have impacted those vendors desiring to pursue such "private label" or "copycat" validations, but has not affected the original 2.0 FIPS module that was used as the model for such private label validations. > What is the status of FIPS OpenSSL certification? > (Is this written up anywhere?) The OpenSSL FIPS Object Module v2.0, validation certificate #1747, remains available for use with (to date) 102 formally tested platforms: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From JLaundree at zoll.com Tue Jan 20 20:33:05 2015 From: JLaundree at zoll.com (John Laundree) Date: Tue, 20 Jan 2015 20:33:05 +0000 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 Message-ID: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> I want to use code like the following while in FIPS mode.... const EVP_MD *md md = EVP_md5(); so I can call HMAC() unsigned char *HMAC(const EVP_MD *evp_md, const void *key, int key_len, const unsigned char *d, size_t n, unsigned char *md, unsigned int *md_len); It appears that OPENSSL_NO_MD5 is defined so EVP_md5() is unavailable... I am new to openssl/FIPS and was wondering if there was another way to generate a HMAC MD5? Thanks in advance. jl -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.francis.jr at pobox.com Tue Jan 20 20:47:36 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Tue, 20 Jan 2015 15:47:36 -0500 Subject: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) In-Reply-To: <3D8643BEB2666A4C93CD59524328691001414D7A2C@sterexch02.teradici.local> References: <3D8643BEB2666A4C93CD59524328691001414D6BED@sterexch02.teradici.local> <54B98FE8.3040400@openssl.com> <3D8643BEB2666A4C93CD59524328691001414D7252@sterexch02.teradici.local> <54BE7F5F.3090709@openssl.com> <3D8643BEB2666A4C93CD59524328691001414D7A2C@sterexch02.teradici.local> Message-ID: > On Jan 20, 2015, at 3:00 PM, Nou Dadoun wrote: > > Thanks for the clarification, a couple of short questions - > > We already have a "shim" to index into the function table that gets loaded after run-time selecting from the 0.9.8 FIPS vs non-FIPS dll to use. I imagined that we might have to "thicken" the shim to accommodate selection between 0.9.8-FIPS and 1.0.1 non-FIPS (unorthodox I know but a potential short term step forward). Couldn't they be made interchangeable with appropriate changes to the shim or is there some more fundamental incompatibility? Probably, but I?d strongly recommend against what you?re doing. You should instead link only ONE library, and call FIPS_mode_set() when you want to use FIPS Approved mode, and do not call that when you do not want to use FIPS Approved mode. I?m not sure why you would do so much excess work for something that was provided for already with a single function call. If it?s because you want to switch between use of FIPS or not within the same process, then you?ve misunderstood what FIPS 140 validation is for, and you?re doing it wrong. Even with the strange (and loose) interpretations of FIPS 140 the government auditors approve. :) > I looked at the link you provided for OpenSSL FIPS Object Module v2.0, validation certificate #1747 (thanks very much for that); another interesting consideration but I was surprised to notice that omitted from the list of supported algorithms was any mention of SHA, is no variant of SHA supported at all? That?s the reference to SHS ? Secure Hashing Standard. See http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm for more info if you?d like. :) > Thanks again ? N TOM > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess > Sent: January-20-15 8:17 AM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) > > On 01/19/2015 12:42 PM, Nou Dadoun wrote: >> The scenario that we're contemplating is having FIPS based on 0.9.8?? >> coexist with 1.0.1?? so the remapping at runtime would have to account >> for api differences within the two. This was really the upshot of my >> question. > > The 1.2 FIPS module ("FIPS based on 0.9.8") is not compatible with OpenSSL 1.0.1. You need the 2.0 FIPS module for that. > >> But I think I'm still a little confused about the FIPS-certification >> of OpenSSL 1.0.1??,... > > It's "validation", not "certification". > >> I remember reading that some of the FIPS power on self-test >> requirements precluded a general FIPS certification, is that the case? >> ... > > I think you're conflating several issues here. What you're probably referring to is the fact that some new requirements for *new* FIPS 140-2 validations (IG 9.10 among them) mean that the source code for the 2.0 FIPS module can no longer be used as-is for new validations. Those new requirements have impacted those vendors desiring to pursue such "private label" or "copycat" validations, but has not affected the original 2.0 FIPS module that was used as the model for such private label validations. > >> What is the status of FIPS OpenSSL certification? >> (Is this written up anywhere?) > > The OpenSSL FIPS Object Module v2.0, validation certificate #1747, remains available for use with (to date) 102 formally tested platforms: > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at opensslfoundation.com > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From rsalz at akamai.com Tue Jan 20 21:10:00 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Jan 2015 21:10:00 +0000 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 In-Reply-To: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> References: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> Message-ID: <028a8d5a6db44e33935cb4b8f2261bfe@usma1ex-dag1mb2.msg.corp.akamai.com> Not possible; MD5 is not a legal FIPS digest. From dthompson at prinpay.com Tue Jan 20 21:43:47 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Tue, 20 Jan 2015 16:43:47 -0500 Subject: [openssl-users] Read cer file failed In-Reply-To: References: Message-ID: <008201d034fa$2dbec610$893c5230$@prinpay.com> > From: openssl-users On Behalf Of Jerry OELoo > Sent: Tuesday, January 20, 2015 00:34 > I am reading cer file into X509 object, > http://SVRSecure-G3-aia.verisign.com/SVRSecureG3.cer > > cert = d2i_X509_fp(fp, NULL); > it will return fail, as below > > Error: error:0D07207B:asn1 encoding routines:ASN1_get_object:header too > long Worked for me, although I observe the server is labelling content-type: text/plain when 2585 (confirmed by 5280) says application/pkix-cert . (I resolved 23.13.165.163 after CNAMEing through edgekey and akamaiedge, but another ISP I can look at got 23.61.69.163. YMMV.) I note this certificate contains a "control-Z" byte (hex 1A). Are you possibly running on Windows with the Microsoft C runtime and opening the file in text mode? Windows C treats 1A as terminating a text file, to be compatible with MS-DOS and before that CP/M. Windows C also tries to use MS-DOS line ending CRLF instead of LF in text files. To read and write the exact bytes of a file in Windows C, as is needed for DER objects, use binary mode. From oyljerry at gmail.com Wed Jan 21 02:49:20 2015 From: oyljerry at gmail.com (Jerry OELoo) Date: Wed, 21 Jan 2015 10:49:20 +0800 Subject: [openssl-users] Read cer file failed In-Reply-To: References: Message-ID: Thanks Michael's information. I am on Ubuntu OS, And I found that If I fopen file with rb, it will work fine. On Tue, Jan 20, 2015 at 9:57 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jerry OELoo >> Sent: Tuesday, January 20, 2015 00:34 >> To: openssl-users at openssl.org >> Subject: [openssl-users] Read cer file failed >> >> I am reading cer file into X509 object, >> http://SVRSecure-G3-aia.verisign.com/SVRSecureG3.cer >> >> cert = d2i_X509_fp(fp, NULL); >> it will return fail, as below > > What's the platform? What are the parameters to the fopen that you used to get fp? > > -- > Michael Wojcik > Technology Specialist, Micro Focus > > > > This message has been scanned for malware by Websense. www.websense.com > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Rejoice,I Desire! From pbellino at mrv.com Wed Jan 21 13:09:54 2015 From: pbellino at mrv.com (Philip Bellino) Date: Wed, 21 Jan 2015 13:09:54 +0000 Subject: [openssl-users] FIPS JCE cryptographic modules usage with Openssl-1.0.1j and openssl-fips-2.0.7 Message-ID: Hello, I apologize if this is not the correct forum for my questions, so here goes. 1. Are the RSA JSafeJCE and the IBM' IBMJESFIPS cryptographic modules being used widely against Openssl in FIPS mode? 2. If so, have these modules kept pace with the latest Openssl FIPS implementation. Thank you. Phil Bellino Principal Software Engineer | MRV Communications Inc. 300 Apollo Drive | Chelmsford, MA 01824 Phone: 978-674-6870 | Fax: 978-674-6799 www.mrv.com [MRV-email] [E-Banner] The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6563 bytes Desc: image001.png URL: From JLaundree at zoll.com Wed Jan 21 13:39:32 2015 From: JLaundree at zoll.com (John Laundree) Date: Wed, 21 Jan 2015 13:39:32 +0000 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 In-Reply-To: <028a8d5a6db44e33935cb4b8f2261bfe@usma1ex-dag1mb2.msg.corp.akamai.com> References: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> <028a8d5a6db44e33935cb4b8f2261bfe@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <02FD6BF65B9B854BA49784A11B009BD31298DAF9@AUSP07DAG0102.hostedmail.local> Ok, so I will naively ask the question "How does one do TLS 1.0/1.1 in FIPS mode? Or is this no longer allowed, i.e. TLS 1.2 only?" -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Tuesday, January 20, 2015 4:10 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 Not possible; MD5 is not a legal FIPS digest. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Wed Jan 21 14:27:58 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 21 Jan 2015 14:27:58 +0000 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 In-Reply-To: <02FD6BF65B9B854BA49784A11B009BD31298DAF9@AUSP07DAG0102.hostedmail.local> References: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> <028a8d5a6db44e33935cb4b8f2261bfe@usma1ex-dag1mb2.msg.corp.akamai.com> <02FD6BF65B9B854BA49784A11B009BD31298DAF9@AUSP07DAG0102.hostedmail.local> Message-ID: <20150121142758.GA18239@openssl.org> On Wed, Jan 21, 2015, John Laundree wrote: > > Ok, so I will naively ask the question "How does one do TLS 1.0/1.1 in FIPS mode? Or is this no longer allowed, i.e. TLS 1.2 only?" > The use of MD5 for TLS 1.0/1.1 is treated as an exception which is allowed in FIPS mode but general MD5 use is not. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Wed Jan 21 14:29:22 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 21 Jan 2015 14:29:22 +0000 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 In-Reply-To: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> References: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> Message-ID: <20150121142922.GB18239@openssl.org> On Tue, Jan 20, 2015, John Laundree wrote: > I want to use code like the following while in FIPS mode.... > > const EVP_MD *md > md = EVP_md5(); > > so I can call HMAC() > > unsigned char *HMAC(const EVP_MD *evp_md, const void *key, int key_len, > const unsigned char *d, size_t n, unsigned char *md, > unsigned int *md_len); > > It appears that OPENSSL_NO_MD5 is defined so EVP_md5() is unavailable... > I am new to openssl/FIPS and was wondering if there was another way to generate a HMAC MD5? > Are you sure EVP_md5() is unavailable? I wouldn't expect OpenSSL to compile if MD5 was disabled. EVP_md5() wont be present in the FIPS module (which doesn't implement it) but it should be present in libcrypto. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Wed Jan 21 14:52:42 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 21 Jan 2015 14:52:42 +0000 Subject: [openssl-users] EVP_aes_256_gcm -- receiving of tag In-Reply-To: <128701d034d5$479cef50$d6d6cdf0$@highwayman.com> References: <128701d034d5$479cef50$d6d6cdf0$@highwayman.com> Message-ID: <20150121145242.GA27716@openssl.org> On Tue, Jan 20, 2015, 'Chris Hall' wrote: > > I find that the EVP_aes_256_gcm for decrypt requires the Tag to be set > before the first call of EVP_DecryptUpdate(), and EVP_DecryptFinal_ex() > with then return 0 if the Tag is found to be incorrect. > Unless you're using an old version of OpenSSL you should be able to specify the tag after any EVP_DecryptUpdate calls but it still has to be before EVP_DecryptFinal(). This was addressed by commit 96f7fafa24313106b121782f1dcf7928dd0838ed Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From thomas.francis.jr at pobox.com Wed Jan 21 21:10:37 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Wed, 21 Jan 2015 16:10:37 -0500 Subject: [openssl-users] FIPS JCE cryptographic modules usage with Openssl-1.0.1j and openssl-fips-2.0.7 In-Reply-To: References: Message-ID: > On Jan 21, 2015, at 8:09 AM, Philip Bellino wrote: > > Hello, > > I apologize if this is not the correct forum for my questions, so here goes. > > > > 1. Are the RSA JSafeJCE and the IBM? IBMJESFIPS cryptographic modules being used widely against Openssl in FIPS mode? In what way do you mean ?against?? As in two (or more) programs communicating with one another, at least one of which uses OpenSSL and at least one of which uses one of the others? Or as in those modules being used in preference to OpenSSL? If the former, I?m not aware of anything in particular. However, it should be noted that the FIPS validations would mean the actual algorithm are compatible, so there?s no reason they couldn?t be used in such ways, assuming appropriate care is taken to use equivalent parameters, keys, etc. If the latter, I?m not sure if there?s any way to measure that, and any measurement is probably meaningless, taken in total ? it?d be more meaningful to make such determinations with respect to a particular type of application or a more specific customer space (although the latter is already pretty specific, since requiring FIPS 140 isn?t exactly a general customer thing). > 2. If so, have these modules kept pace with the latest Openssl FIPS implementation. I don?t quite follow. Those products are entirely separate from OpenSSL (and each other), and none of them affect any of the others. Indeed, because of the way validation testing is performed and interpreted, one implementation may have more onerous changes enforced than another. If you?re wondering about new interpretations that have caused changes in OpenSSL, and if those interpretations have also affected those implementations, you?d need to ask RSA and IBM. I doubt they?ll tell you anything other than the appropriate certificate numbers for their products, and let you look up the dates they were awarded, though. :) TOM > > > Thank you. > > > > > > > > > > Phil Bellino > > Principal Software Engineer | MRV Communications Inc. > > 300 Apollo Drive | Chelmsford, MA 01824 > > Phone: 978-674-6870 | Fax: 978-674-6799 > > www.mrv.com > > > > > > > > > > > > The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Avery.A.Tarasov at SecurityEngineer.Pro Thu Jan 22 05:36:08 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Thu, 22 Jan 2015 00:36:08 -0500 Subject: [openssl-users] Proper cleanup functions being called? Message-ID: <5cd580cd7a889d118ed6bf75962e95b0@smtp.hushmail.com> Hi All, I am using OpenSSL 1.0.1lin Win32 environment. At the beginning of my program I call SSL_library_init(); SSL_load_error_strings(); Those functions are only called once. Then I have 3 threads which can't possibly be run at the same time due to mutexes I'm setting with WaitForSingleObject and ReleaseMutex. Those 3 threads use these functions below and all variables in those threads are local to the threads (e.g. no globals). SSL_CTX_new SSL_CTX_set_verify SSL_CTX_set_cert_verify_callback BIO_new_connect BIO_do_connect SSL_new SSL_set_bio SSL_get_peer_certificate SSL_write SSL_read SSL_get_error (cleanup functions.. if conditions used to prevent double frees, etc.) X509_free SSL_shutdown SSL_free BIO_free SSL_CTX_free My questions are the following: 1) Am I correct that I only need to call the SSL_library_init(); and SSL_load_error_strings(); once at the beginning of the program , and not at the beginning of each thread? 2) Should I be doing any other cleanup functions within the threads? My program appears to work perfectly but a tool is complaining about memory leaks in _CRYPTO_malloc, _asn1_enc_save, _asn1_item_ex_d2i, _d2i_X509 Handle leaks _shmem_winpthreads_grab _pthread_register_pointer In fact I get memory leaks reported if I just do SSL_library_init(); alone Despite the reports of the leaks my program seems to run fine for days and stay consistent in memory used. But I'm feeling paranoid something just isn't quite right. Should I be doing any other cleanup operations? Thanks for the assistance. Best Regards, -Avery T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dthompson at prinpay.com Thu Jan 22 06:20:51 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Thu, 22 Jan 2015 01:20:51 -0500 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 In-Reply-To: <20150121142758.GA18239@openssl.org> References: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> <028a8d5a6db44e33935cb4b8f2261bfe@usma1ex-dag1mb2.msg.corp.akamai.com> <02FD6BF65B9B854BA49784A11B009BD31298DAF9@AUSP07DAG0102.hostedmail.local> <20150121142758.GA18239@openssl.org> Message-ID: <00a101d0360b$94253170$bc6f9450$@prinpay.com> > From: openssl-users On Behalf Of Dr. Stephen Henson > Sent: Wednesday, January 21, 2015 09:28 > On Wed, Jan 21, 2015, John Laundree wrote: > > > Ok, so I will naively ask the question "How does one do TLS 1.0/1.1 in FIPS > mode? Or is this no longer allowed, i.e. TLS 1.2 only?" > > The use of MD5 for TLS 1.0/1.1 is treated as an exception which is allowed in > FIPS mode but general MD5 use is not. > To be exact, as I read it, the TLS1.0/1.1 *PRF* *combines* MD5+SHA1 for handshake/keyexchange, and is Approved on the basis that the combination is secure even if MD5 is not. The SSL3 PRF combines them more weakly and isn't Approved so SSL3 protocol is prohibited. Suites using (pure) HMAC-MD5 for data are not Approved, in any protocol version. And as you say MD5 as such is not allowed anywhere. From chris.hall.list at highwayman.com Thu Jan 22 11:18:17 2015 From: chris.hall.list at highwayman.com ('Chris Hall') Date: Thu, 22 Jan 2015 11:18:17 -0000 Subject: [openssl-users] EVP_aes_256_gcm -- receiving of tag In-Reply-To: <20150121145242.GA27716@openssl.org> References: <128701d034d5$479cef50$d6d6cdf0$@highwayman.com> <20150121145242.GA27716@openssl.org> Message-ID: <017e01d03635$225a8a70$670f9f50$@highwayman.com> Dr. Stephen Henson wrote (on Wed 21-Jan-2015 at 14:53 +0000): > On Tue, Jan 20, 2015, 'Chris Hall' wrote: ... > > I find that the EVP_aes_256_gcm for decrypt requires the Tag to be > > set before the first call of EVP_DecryptUpdate(), and > > EVP_DecryptFinal_ex() with then return 0 if the Tag is found to > > be incorrect. > Unless you're using an old version of OpenSSL you should be able to > specify the tag after any EVP_DecryptUpdate calls but it still has to > be before EVP_DecryptFinal(). > > This was addressed by commit 96f7fafa24313106b121782f1dcf7928dd0838ed Thanks. It's very kind of EVP_DecryptFinal() to check the Tag, but I could do with a way of getting hold of the Tag generated. In particular, I want to append signed copy of the Tag to the message, so the receiver may not even know what the Tag is. I suppose I could send the Tag between the encrypted message and the trailing signature, but I don't particularly want to reveal the Tag. Also, this is messing with the message format to fit the library ! Thanks, Chris From michel.sales at OnLine.fr Thu Jan 22 12:07:57 2015 From: michel.sales at OnLine.fr (Michel SALES) Date: Thu, 22 Jan 2015 13:07:57 +0100 Subject: [openssl-users] Proper cleanup functions being called? In-Reply-To: <5cd580cd7a889d118ed6bf75962e95b0@smtp.hushmail.com> References: <5cd580cd7a889d118ed6bf75962e95b0@smtp.hushmail.com> Message-ID: <000601d0363c$0f8c1240$2ea436c0$@sales@OnLine.fr> 1) Am I correct that I only need to call the SSL_library_init(); and SSL_load_error_strings(); once at the beginning of the program , and not at the beginning of each thread? Yes 2) Should I be doing any other cleanup functions within the threads? Yes, ERR_remove_state() Should I be doing any other cleanup operations ? Probably some of (before exiting main thread only) : EVP_cleanup(); ERR_free_strings(); CRYPTO_cleanup_all_ex_data(); ENGINE_cleanup(); CONF_modules_unload( 1 ); CONF_modules_free(); sk_SSL_COMP_free( SSL_COMP_get_compression_methods()); RAND_cleanup(); Hope it helps, Michel. De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Avery A. Tarasov Envoy? : jeudi 22 janvier 2015 06:36 ? : openssl-users at openssl.org Objet : [openssl-users] Proper cleanup functions being called? Hi All, I am using OpenSSL 1.0.1l in Win32 environment. At the beginning of my program I call SSL_library_init(); SSL_load_error_strings(); Those functions are only called once. Then I have 3 threads which can't possibly be run at the same time due to mutexes I'm setting with WaitForSingleObject and ReleaseMutex. Those 3 threads use these functions below and all variables in those threads are local to the threads (e.g. no globals). SSL_CTX_new SSL_CTX_set_verify SSL_CTX_set_cert_verify_callback BIO_new_connect BIO_do_connect SSL_new SSL_set_bio SSL_get_peer_certificate SSL_write SSL_read SSL_get_error (cleanup functions.. if conditions used to prevent double frees, etc.) X509_free SSL_shutdown SSL_free BIO_free SSL_CTX_free My questions are the following: 1) Am I correct that I only need to call the SSL_library_init(); and SSL_load_error_strings(); once at the beginning of the program , and not at the beginning of each thread? 2) Should I be doing any other cleanup functions within the threads? My program appears to work perfectly but a tool is complaining about memory leaks in _CRYPTO_malloc, _asn1_enc_save, _asn1_item_ex_d2i, _d2i_X509 Handle leaks _shmem_winpthreads_grab _pthread_register_pointer In fact I get memory leaks reported if I just do SSL_library_init(); alone Despite the reports of the leaks my program seems to run fine for days and stay consistent in memory used. But I'm feeling paranoid something just isn't quite right. Should I be doing any other cleanup operations? Thanks for the assistance. Best Regards, -Avery T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldgibbons at avaya.com Thu Jan 22 12:42:29 2015 From: ldgibbons at avaya.com (Gibbons, Lee D (Doug)) Date: Thu, 22 Jan 2015 12:42:29 +0000 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 In-Reply-To: <00a101d0360b$94253170$bc6f9450$@prinpay.com> References: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> <028a8d5a6db44e33935cb4b8f2261bfe@usma1ex-dag1mb2.msg.corp.akamai.com> <02FD6BF65B9B854BA49784A11B009BD31298DAF9@AUSP07DAG0102.hostedmail.local> <20150121142758.GA18239@openssl.org> <00a101d0360b$94253170$bc6f9450$@prinpay.com> Message-ID: NIST addresses TLS 1.0-1.2 KDFs in SP 800-135rev1. For 140-2 validation the KDF would be tested via NIST's ASKDFVS. For those riding on the shirttails of #1747, note that the TLS KDF component is implemented in the FIPS-capable OpenSSL library code *outside* of the FIPS Object Module. Though the TLS KDF algorithm may in general be Approved, the OpenSSL FIPS Object Module does not appear to provide a validated TLS KDF. I don't see a CVL cert for TLS KDF listed in #1747. Doug Gibbons -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dave Thompson Sent: Wednesday, January 21, 2015 11:21 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 > From: openssl-users On Behalf Of Dr. Stephen Henson > Sent: Wednesday, January 21, 2015 09:28 > On Wed, Jan 21, 2015, John Laundree wrote: > > > Ok, so I will naively ask the question "How does one do TLS 1.0/1.1 > > in FIPS > mode? Or is this no longer allowed, i.e. TLS 1.2 only?" > > The use of MD5 for TLS 1.0/1.1 is treated as an exception which is > allowed in > FIPS mode but general MD5 use is not. > To be exact, as I read it, the TLS1.0/1.1 *PRF* *combines* MD5+SHA1 for handshake/keyexchange, and is Approved on the basis that the combination is secure even if MD5 is not. The SSL3 PRF combines them more weakly and isn't Approved so SSL3 protocol is prohibited. Suites using (pure) HMAC-MD5 for data are not Approved, in any protocol version. And as you say MD5 as such is not allowed anywhere. _______________________________________________ openssl-users mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=LlsENUS4HI1fg4eMsTxoSOs4zCv38ATLKf-JAHPNl7Q&m=QTOtp0d9KSfYrkzv8qkvuAeqCnPPdxocPR9NO4Au94o&s=08xVu7r1MvSU4yef2ePC4MW_OpSkYmSBF0NjkrWTOew&e= From dave.mclellan at emc.com Thu Jan 22 17:35:55 2015 From: dave.mclellan at emc.com (mclellan, dave) Date: Thu, 22 Jan 2015 12:35:55 -0500 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others Message-ID: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> Hi. I'm running openssl CLI 1.0.1j (for example) on a bunch of different unix platforms. On all of them, the default missing /usr/local/ssl/openssl.cnf causes a warning, but the CLI continues to initialize and opens the command line. We've known about this behavior since first incorporating 1.0.1c years ago); this is no big deal. Except for AIX: on all our AIX machines of varying versions, the missing /usr/local/ssl/openssl.cnf raises a permission error, and openssl CLI refuses to run. openssl version 1152921504606846944:error:0200100D:system library:fopen:Permission denied:bss_file.c:169:fopen('/usr/local/ssl/openssl.cnf','rb') 1152921504606846944:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:174: 1152921504606846944:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199: None of the hosts we've visited have /usr/local/ssl, not to mention the actual default file. In fact, on some, even non-AIX hosts, permissions would suggest that the permission should be returned. Should this be happening? Is AIX simply less forgiving, and returns a more serious error. Or is the openssl CLI handling the missing file differently on AIX? Thanks for any enlightenment shareable. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclellan at emc.com +-+-+-+-+-+-+-+-+- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jan 22 18:22:19 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 22 Jan 2015 18:22:19 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> Message-ID: <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> > None of the hosts we've visited have /usr/local/ssl, not to mention the actual default file. ?In fact, on some, even non-AIX hosts, permissions would suggest that the permission should be returned. Not sure what that last sentence means. > Should this be happening? Is AIX simply less forgiving, and returns? a more serious error.?? Or is the openssl CLI handling the missing file differently on AIX? I can well believe that AIX is, exactly that, less forgiving and returns different error codes than many other Unices. There is no AIX-specific code in openssl around file access. Trying "ls -ld" on /usr and /usr/local and /usr/local/ssl and checking errno might be interesting. From JLaundree at zoll.com Thu Jan 22 20:25:15 2015 From: JLaundree at zoll.com (John Laundree) Date: Thu, 22 Jan 2015 20:25:15 +0000 Subject: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 In-Reply-To: References: <02FD6BF65B9B854BA49784A11B009BD31298DA59@AUSP07DAG0102.hostedmail.local> <028a8d5a6db44e33935cb4b8f2261bfe@usma1ex-dag1mb2.msg.corp.akamai.com> <02FD6BF65B9B854BA49784A11B009BD31298DAF9@AUSP07DAG0102.hostedmail.local> <20150121142758.GA18239@openssl.org> <00a101d0360b$94253170$bc6f9450$@prinpay.com> Message-ID: <02FD6BF65B9B854BA49784A11B009BD31298DCA2@AUSP07DAG0102.hostedmail.local> Thanks to all that replied to this thread. I now understand and was able to generate my TLS KDF test. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Gibbons, Lee D (Doug) Sent: Thursday, January 22, 2015 7:42 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 NIST addresses TLS 1.0-1.2 KDFs in SP 800-135rev1. For 140-2 validation the KDF would be tested via NIST's ASKDFVS. For those riding on the shirttails of #1747, note that the TLS KDF component is implemented in the FIPS-capable OpenSSL library code *outside* of the FIPS Object Module. Though the TLS KDF algorithm may in general be Approved, the OpenSSL FIPS Object Module does not appear to provide a validated TLS KDF. I don't see a CVL cert for TLS KDF listed in #1747. Doug Gibbons -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dave Thompson Sent: Wednesday, January 21, 2015 11:21 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] HMAC-MD5 OpenSSL 1.0.1e and FIPS 2.0.7 > From: openssl-users On Behalf Of Dr. Stephen Henson > Sent: Wednesday, January 21, 2015 09:28 > On Wed, Jan 21, 2015, John Laundree wrote: > > > Ok, so I will naively ask the question "How does one do TLS 1.0/1.1 > > in FIPS > mode? Or is this no longer allowed, i.e. TLS 1.2 only?" > > The use of MD5 for TLS 1.0/1.1 is treated as an exception which is > allowed in > FIPS mode but general MD5 use is not. > To be exact, as I read it, the TLS1.0/1.1 *PRF* *combines* MD5+SHA1 for handshake/keyexchange, and is Approved on the basis that the combination is secure even if MD5 is not. The SSL3 PRF combines them more weakly and isn't Approved so SSL3 protocol is prohibited. Suites using (pure) HMAC-MD5 for data are not Approved, in any protocol version. And as you say MD5 as such is not allowed anywhere. _______________________________________________ openssl-users mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=LlsENUS4HI1fg4eMsTxoSOs4zCv38ATLKf-JAHPNl7Q&m=QTOtp0d9KSfYrkzv8qkvuAeqCnPPdxocPR9NO4Au94o&s=08xVu7r1MvSU4yef2ePC4MW_OpSkYmSBF0NjkrWTOew&e= _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From dave.mclellan at emc.com Thu Jan 22 20:00:08 2015 From: dave.mclellan at emc.com (mclellan, dave) Date: Thu, 22 Jan 2015 15:00:08 -0500 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <56A41A14DF41784FA3CA37EF5760F2751F07B56807@MX30A.corp.emc.com> Thank you Rich. The sentence you couldn't understand is my bad, s/b: "In fact, on some, even non-AIX hosts, permissions would suggest that the permission error should be returned." Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclellan at emc.com +-+-+-+-+-+-+-+-+- -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Thursday, January 22, 2015 1:22 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others > None of the hosts we've visited have /usr/local/ssl, not to mention the actual default file. In fact, on some, even non-AIX hosts, permissions would suggest that the permission should be returned. Not sure what that last sentence means. > Should this be happening? Is AIX simply less forgiving, and returns a more serious error. Or is the openssl CLI handling the missing file differently on AIX? I can well believe that AIX is, exactly that, less forgiving and returns different error codes than many other Unices. There is no AIX-specific code in openssl around file access. Trying "ls -ld" on /usr and /usr/local and /usr/local/ssl and checking errno might be interesting. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Jan 22 21:15:42 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 22 Jan 2015 21:15:42 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <56A41A14DF41784FA3CA37EF5760F2751F07B56807@MX30A.corp.emc.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <56A41A14DF41784FA3CA37EF5760F2751F07B56807@MX30A.corp.emc.com> Message-ID: (Apologies for the top-post; Outlook does not deal properly with HTML email.) If open, called by fopen, actually is setting EPERM, then one of the following should be true: - /usr/local/ssl/openssl.cnf exists but the user does not have read permission on it - Either /usr/local or /usr/local/ssl exists and is a directory, but the user does not have *execute* permission on it Note that *read* permission on the directories is not necessary to open a file contained therein. Read permission on a directory is only required to enumerate the directory contents (for ls, find, etc). Execute permission on a directory, on the other hand, is traversal permission, and you need traversal permission along the path to open a file. There are some other possibilities, such as ACLs (not commonly used in AIX, but available). Users who don't have traverse permission for /usr itself would have a hard time getting this far, so we can probably rule that out. A run under truss might be enlightening. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of mclellan, dave Sent: Thursday, January 22, 2015 15:00 To: openssl-users at openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others Thank you Rich. The sentence you couldn't understand is my bad, s/b: "In fact, on some, even non-AIX hosts, permissions would suggest that the permission error should be returned." Dave This message has been scanned for malware by Websense. www.websense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.mclellan at emc.com Thu Jan 22 21:22:59 2015 From: dave.mclellan at emc.com (mclellan, dave) Date: Thu, 22 Jan 2015 16:22:59 -0500 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <56A41A14DF41784FA3CA37EF5760F2751F07B56807@MX30A.corp.emc.com> Message-ID: <56A41A14DF41784FA3CA37EF5760F2751F07B56829@MX30A.corp.emc.com> Thanks very much. Most appreciated. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclellan at emc.com +-+-+-+-+-+-+-+-+- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Thursday, January 22, 2015 4:16 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others (Apologies for the top-post; Outlook does not deal properly with HTML email.) If open, called by fopen, actually is setting EPERM, then one of the following should be true: - /usr/local/ssl/openssl.cnf exists but the user does not have read permission on it - Either /usr/local or /usr/local/ssl exists and is a directory, but the user does not have *execute* permission on it [[Dave] ] I believe this is the case; the x bit was not on /usr/local I think. I no longer have access to the host (owned by someone else). Note that *read* permission on the directories is not necessary to open a file contained therein. Read permission on a directory is only required to enumerate the directory contents (for ls, find, etc). Execute permission on a directory, on the other hand, is traversal permission, and you need traversal permission along the path to open a file. There are some other possibilities, such as ACLs (not commonly used in AIX, but available). Users who don't have traverse permission for /usr itself would have a hard time getting this far, so we can probably rule that out. A run under truss might be enlightening. [[Dave] ] oh yeah, I had thought of trying truss. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of mclellan, dave Sent: Thursday, January 22, 2015 15:00 To: openssl-users at openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others Thank you Rich. The sentence you couldn't understand is my bad, s/b: "In fact, on some, even non-AIX hosts, permissions would suggest that the permission error should be returned." Dave This message has been scanned for malware by Websense. www.websense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Jan 22 20:50:03 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 22 Jan 2015 20:50:03 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich > Sent: Thursday, January 22, 2015 13:22 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes > failure on AIX, warning on all others > > > > Should this be happening? Is AIX simply less forgiving, and returns? a more > serious error.?? Or is the openssl CLI handling the missing file differently on > AIX? > > I can well believe that AIX is, exactly that, less forgiving and returns different > error codes than many other Unices. I can't. The behavior of fopen is defined by ISO 9899 and the Single UNIX Specfication, which AIX has adhered to for well over a decade. Let's see: ----- (152 mww) aix61v1:/home/devel/mww - cat testc.c #include #include int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); perror("fopen"); return 0;} (153 mww) aix61v1:/home/devel/mww - make testc cc -O testc.c -o testc (154 mww) aix61v1:/home/devel/mww - ./testc fopen: No such file or directory ----- fopen (well, open, called by fopen) is setting errno to ENOENT, just as one would expect. And while I'm at it: ----- (169 mww) aix61v1:/home/devel/mww/OpenSSL-101g/ssl/Integration/main/openssl/multi/32/openssl/apps - ./openssl WARNING: can't open config file: /usr/local/ssl/openssl.cnf OpenSSL> quit ----- Not seeing the problem here (and I've never seen it before, and none of our customers have reported it). This appears to be unique to the OP's environment. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From rsalz at akamai.com Thu Jan 22 21:36:52 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 22 Jan 2015 21:36:52 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> > I can't. The behavior of fopen is defined by ISO 9899 and the Single UNIX > Specfication, which AIX has adhered to for well over a decade. I meant no disrespect to big blue :) I worked there for a half-decade, and also with them on standards for a lot longer... > int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); perror("fopen"); And what happens if some of the directories on the path don't exist? From Michael.Wojcik at microfocus.com Thu Jan 22 22:33:37 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 22 Jan 2015 22:33:37 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich > Sent: Thursday, January 22, 2015 16:37 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes > failure on AIX, warning on all others > > > I can't. The behavior of fopen is defined by ISO 9899 and the Single > > UNIX Specfication, which AIX has adhered to for well over a decade. > > I meant no disrespect to big blue :) I worked there for a half-decade, and > also with them on standards for a lot longer... > > > int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); > > perror("fopen"); > > And what happens if some of the directories on the path don't exist? Depends on which of the following happens first: - open(2) encounters a missing directory: ENOENT. - open(2) encounters a non-traversable directory: EACCES. (I wrote "EPERM" in an earlier note, but I don't think that's even a real errno value name. Duh.) - open(2) gets all the way to the file but doesn't have sufficient permission: ENOENT. - Some other I/O error occurs (broken NFS mount, etc): some other errno value, or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets fopen set EACCES, EINTR (if open is "slow" and gets interrupted by a signal), EISDIR, ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should only happen for file creation), ENOTDIR (if you have a non-directory as a non-terminal path component), ENXIO (trying to open a special node in an unsupported way), EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY. A quick look at apps/openssl.c suggests that it'll abort if it gets anything other than CONF_R_NO_SUCH_FILE from ERR_GET_REASON(ERR_peek_last_error()) after NCONF_load fails. That doesn't clarify things much, though I'd suggest that it might be worth suppressing this behavior via an option. If the user knows there's no configuration file, the following should work (under suitable shells): OPENSSL_CONF=/dev/null openssl ... Just let openssl open /dev/null as its config file. It'll get EOF immediately (as if openssl.cnf existed and was empty) and should trundle along happily. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From Avery.A.Tarasov at SecurityEngineer.Pro Thu Jan 22 23:58:53 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Thu, 22 Jan 2015 18:58:53 -0500 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l Message-ID: I have a fairly simple Win32 application (.cpp file source code attached) that uses OpenSSL 1.0.1l to send some GET requests in 2 threads. I am getting reports of Handle Leaks in C++ memory validator (see logs at bottom of email), but I can't find what is wrong with my code (if anything). The app appears to function perfectly and the memory doesn't appear to rise in task manager.. but I'm still worried about the Handle Leak reports. * It should be noted that even if I get rid of the threads all together and just call 2 functions for the GET requests, I still get these same leak reports. So I don't think its a thread related problem. Also, the reason I'm not using CRYPTO_set_locking_callback is because I am already using WaitForSingleObject and ReleaseMutex to make sure its impossible for two threads to be running at the same time. Unless I'm missing something, CRYPTO_set_locking_callback is not needed due to the way I coded this. Can someone please verify if the code is thread safe, and comment regarding what might be causing these handle leaks? Maybe it is nothing to be worried about -- not sure.. Are there any other problems you see in the code? Perhaps missing cleanup functions? Or is everything OK and I'm just over analyzing this? Thanks for any tips! Best Regards, -Avery Address / Handle: 0x0000C001 shmem-win32.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:01:45:503ms) Sequence: 11 sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] sslleak.exe _fc_key_init_once : [unwind-sjlj.c Line 0] sslleak.exe _main : [crt0_c.c Line 0] sslleak.exe ___tmainCRTStartup : [crtexe.c Line 0] kernel32.dll BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0] ntdll.dll RtlInitializeExceptionChain : [{FUNC}RtlInitializeExceptionChain Line 0] Address / Handle: 0x0000C00F shmem-win32.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:02:29:683ms) Sequence: 97 sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] Address / Handle: 0x0000C016 shmem.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:03:02:693ms) Sequence: 143 sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] Address / Handle: 0x0000C009 shmem.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:03:22:364ms) Sequence: 61 sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe _mutex_static_init : [mutex.c Line 0] sslleak.exe _pop_pthread_mem : [thread.c Line 0] sslleak.exe _pop_pthread_mem : [thread.c Line 0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #include #include #include #include #include #include #include #include HANDLE sslmutex=0; int checks(X509_STORE_CTX *c, void *v) { return 1; } void SSLGO_111() { SSL_CTX *myct; myct = SSL_CTX_new(TLSv1_2_method()); if(myct==NULL) { ERR_remove_state(0); return; } SSL_CTX_set_verify(myct,SSL_VERIFY_PEER, NULL); SSL_CTX_set_cert_verify_callback(myct, checks, "K"); std::string http_resp; std::string headers="GET /111 HTTP/1.1\r\nHost: removed.com\r\nAccept: */*\r\nUser-Agent: Test\r\n\r\n"; X509 *pcc=0; SSL *thessl=0; BIO *bcc = NULL; char buf[513]; int ret; bcc = BIO_new_connect("removed.com:443"); if (!bcc) { goto sslend; } if (BIO_do_connect(bcc)<=0) { goto sslend; } thessl=SSL_new(myct); if (!thessl ) { goto sslend; } SSL_set_bio(thessl, bcc, bcc); if (SSL_connect(thessl)<=0) { goto sslend; } pcc=SSL_get_peer_certificate(thessl); if(pcc==NULL) { goto sslend; } ret=SSL_write(thessl, headers.c_str(),headers.length()); if(ret<0) { goto sslend; } while(1) { memset(buf,0x0,sizeof(buf)); int r=SSL_read(thessl,buf,512); switch(SSL_get_error(thessl,r)) { case SSL_ERROR_SYSCALL: goto sslend; case SSL_ERROR_ZERO_RETURN: goto sslend; case SSL_ERROR_NONE: http_resp+=buf; break; default: ; } } sslend: if(pcc) { X509_free(pcc); } if (thessl) { SSL_shutdown(thessl); SSL_free(thessl); } else if (bcc) { BIO_free(bcc); } if(myct) { SSL_CTX_free(myct); } ERR_remove_state(0); } void SSLGO_222() { SSL_CTX *myct; myct = SSL_CTX_new(TLSv1_2_method()); if(myct==NULL) { ERR_remove_state(0); return; } SSL_CTX_set_verify(myct,SSL_VERIFY_PEER, NULL); SSL_CTX_set_cert_verify_callback(myct, checks, "K"); std::string http_resp; std::string headers="GET /222 HTTP/1.1\r\nHost: removed.com\r\nAccept: */*\r\nUser-Agent: Test\r\n\r\n"; X509 *pcc=0; SSL *thessl=0; BIO *bcc = NULL; char buf[513]; int ret; bcc = BIO_new_connect("removed.com:443"); if (!bcc) { goto sslend; } if (BIO_do_connect(bcc)<=0) { goto sslend; } thessl=SSL_new(myct); if (!thessl ) { goto sslend; } SSL_set_bio(thessl, bcc, bcc); if (SSL_connect(thessl)<=0) { goto sslend; } pcc=SSL_get_peer_certificate(thessl); if(pcc==NULL) { goto sslend; } ret=SSL_write(thessl, headers.c_str(),headers.length()); if(ret<0) { goto sslend; } while(1) { memset(buf,0x0,sizeof(buf)); int r=SSL_read(thessl,buf,512); switch(SSL_get_error(thessl,r)) { case SSL_ERROR_SYSCALL: goto sslend; case SSL_ERROR_ZERO_RETURN: goto sslend; case SSL_ERROR_NONE: http_resp+=buf; break; default: ; } } sslend: if(pcc) { X509_free(pcc); } if (thessl) { SSL_shutdown(thessl); SSL_free(thessl); } else if (bcc) { BIO_free(bcc); } if(myct) { SSL_CTX_free(myct); } ERR_remove_state(0); } DWORD __stdcall thread1(LPVOID l) { while(1) { WaitForSingleObject(sslmutex,INFINITE); SSLGO_222(); ReleaseMutex(sslmutex); Sleep(100); } } DWORD __stdcall thread2(LPVOID l) { while(1) { WaitForSingleObject(sslmutex,INFINITE); SSLGO_111(); ReleaseMutex(sslmutex); Sleep(100); } } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { DWORD t1; DWORD t2; sslmutex=CreateMutex(NULL,false,NULL); if(sslmutex==NULL) { return 0; } SSL_library_init(); SSL_load_error_strings(); HANDLE h1=0; HANDLE h2=0; h1=CreateThread(0,0,thread1,0,0,&t1); if(h1==0) { return 0; } h2=CreateThread(0,0,thread2,0,0,&t1); if(h2==0) { return 0; } while(1) { Sleep(1000); } // IMPORTANT ****************** // Even if I do this and comment out the 2 CreateThreads above, I still get the same Handle Leak reports... so it doesn't appear to be anything relate to // a thread problem /* while(1) { SSLGO_111(); SSLGO_222(); Sleep(1000); } */ } From Kai.Koehne at theqtcompany.com Fri Jan 23 09:03:30 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Fri, 23 Jan 2015 09:03:30 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Michael Wojcik > Sent: Thursday, January 22, 2015 11:34 PM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes > failure on AIX, warning on all others > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > > Behalf Of Salz, Rich > > Sent: Thursday, January 22, 2015 16:37 > > To: openssl-users at openssl.org > > Subject: Re: [openssl-users] missing default > > /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all > > others > > > > > I can't. The behavior of fopen is defined by ISO 9899 and the Single > > > UNIX Specfication, which AIX has adhered to for well over a decade. > > > > I meant no disrespect to big blue :) I worked there for a > > half-decade, and also with them on standards for a lot longer... > > > > > int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); > > > perror("fopen"); > > > > And what happens if some of the directories on the path don't exist? > > Depends on which of the following happens first: > > - open(2) encounters a missing directory: ENOENT. > - open(2) encounters a non-traversable directory: EACCES. (I wrote "EPERM" > in an earlier note, but I don't think that's even a real errno value name. Duh.) > - open(2) gets all the way to the file but doesn't have sufficient permission: > ENOENT. > - Some other I/O error occurs (broken NFS mount, etc): some other errno > value, or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets > fopen set EACCES, EINTR (if open is "slow" and gets interrupted by a signal), > EISDIR, ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should > only happen for file creation), ENOTDIR (if you have a non-directory as a non- > terminal path component), ENXIO (trying to open a special node in an > unsupported way), EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY. > > A quick look at apps/openssl.c suggests that it'll abort if it gets anything other > than CONF_R_NO_SUCH_FILE from > ERR_GET_REASON(ERR_peek_last_error()) after NCONF_load fails. That > doesn't clarify things much, though I'd suggest that it might be worth > suppressing this behavior via an option. This reminds me of http://rt.openssl.org/Ticket/Display.html?id=2644&user=guest&pass=guest , though it's in another code path ... Over time I met at least 4 other people who ran into exactly this issue on Windows, so if I'd have any votes to give to a bug report, it would be this one :) Regards Kai From dave.mclellan at emc.com Fri Jan 23 13:16:40 2015 From: dave.mclellan at emc.com (mclellan, dave) Date: Fri, 23 Jan 2015 08:16:40 -0500 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <56A41A14DF41784FA3CA37EF5760F2751F07B5686F@MX30A.corp.emc.com> Thanks again. I had returned to the conf_def.c file and saw the logic that essentially summarizes your detailed sequence. The workaround you suggested of specifying OPENSSL_CONF is a variation of what I had given our QA team (the original reporter of the issue on AIX), and this indeed circumvented the issue. Thanks to all for all the interest in and traffic on this question. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclellan at emc.com +-+-+-+-+-+-+-+-+- -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Thursday, January 22, 2015 5:34 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Salz, Rich > Sent: Thursday, January 22, 2015 16:37 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] missing default > /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all > others > > > I can't. The behavior of fopen is defined by ISO 9899 and the Single > > UNIX Specfication, which AIX has adhered to for well over a decade. > > I meant no disrespect to big blue :) I worked there for a > half-decade, and also with them on standards for a lot longer... > > > int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); > > perror("fopen"); > > And what happens if some of the directories on the path don't exist? Depends on which of the following happens first: - open(2) encounters a missing directory: ENOENT. - open(2) encounters a non-traversable directory: EACCES. (I wrote "EPERM" in an earlier note, but I don't think that's even a real errno value name. Duh.) - open(2) gets all the way to the file but doesn't have sufficient permission: ENOENT. - Some other I/O error occurs (broken NFS mount, etc): some other errno value, or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets fopen set EACCES, EINTR (if open is "slow" and gets interrupted by a signal), EISDIR, ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should only happen for file creation), ENOTDIR (if you have a non-directory as a non-terminal path component), ENXIO (trying to open a special node in an unsupported way), EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY. A quick look at apps/openssl.c suggests that it'll abort if it gets anything other than CONF_R_NO_SUCH_FILE from ERR_GET_REASON(ERR_peek_last_error()) after NCONF_load fails. That doesn't clarify things much, though I'd suggest that it might be worth suppressing this behavior via an option. If the user knows there's no configuration file, the following should work (under suitable shells): OPENSSL_CONF=/dev/null openssl ... Just let openssl open /dev/null as its config file. It'll get EOF immediately (as if openssl.cnf existed and was empty) and should trundle along happily. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michael.Wojcik at microfocus.com Fri Jan 23 15:04:07 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 23 Jan 2015 15:04:07 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Koehne Kai > Sent: Friday, January 23, 2015 04:03 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes > failure on AIX, warning on all others > > This reminds me of > http://rt.openssl.org/Ticket/Display.html?id=2644&user=guest&pass=guest , > though it's in another code path ... Over time I met at least 4 other people > who ran into exactly this issue on Windows, so if I'd have any votes to give to > a bug report, it would be this one :) This is an interesting one because the problem is clear - the openssl utility exits if it gets any error other than "file doesn't exist" trying to open its configuration file - but the solution is not. Why not? Because the current behavior is failing-to-secure. The openssl utility doesn't know what's in the configuration file if it can't open it. There might be a security vulnerability if openssl can run without processing the configuration file. The existing logic allows for two cases: the configuration file is processed, and the configuration file doesn't exist (in which case we get a warning diagnostic but processing continues). Anything else is treated as a possible attack. Now, we might point out that the user can simply override the name of the configuration file, as I suggested in an earlier message (and Dave confirmed bypasses the issue). But it's conceivable that openssl is being run in a script which sets the OPENSSL_CONF environment variable, so the user can't force the configuration file. In my opinion, the risk here is small, and I'd favor expanding the conditions under which openssl emits the warning and continues, as bug 2644 suggests. But reasonable people could argue otherwise. Probably someone who's particularly bothered by this should submit a patch. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From Avery.A.Tarasov at SecurityEngineer.Pro Fri Jan 23 15:34:29 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Fri, 23 Jan 2015 10:34:29 -0500 Subject: [openssl-users] Is CRYPTO_set_locking_callback necessary in multi-threaded OpenSSL program that already uses mutexes to make sure threads can't run at the same time? Message-ID: I am using OpenSSL 1.0.1l in Win32 environment. In the main section of the program I initialize the SSL library and load the error strings. Then I create two threads that run concurrently. One sends GET requests to a website and the other sends POST requests to a website using SSL -- both threads do this in an infinite loop with a 100 millisecond pause. No variables are shared between the two threads. Everything is declared locally. I use a mutex to make sure it is impossible for the two threads to be running at the time (so basically each thread does its work between a WaitForSingleObject and ReleaseMutex call) In this situation, am I correct that there is no need to use CRYPTO_set_locking_callback ? My program has been running for 3+ days and never had a crash or error. Although the documention says this CRYPTO_set_locking_callback function is needed for mufti-threaded programs, I don't see why in the above situation it would be. Please advise. Thanks, -Avery -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Fri Jan 23 16:06:47 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 23 Jan 2015 16:06:47 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 23 January 2015 at 15:04, Michael Wojcik wrote: > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > > Of Koehne Kai > > Sent: Friday, January 23, 2015 04:03 > > To: openssl-users at openssl.org > > Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf > causes > > failure on AIX, warning on all others > > > > This reminds me of > > http://rt.openssl.org/Ticket/Display.html?id=2644&user=guest&pass=guest > , > > though it's in another code path ... Over time I met at least 4 other > people > > who ran into exactly this issue on Windows, so if I'd have any votes to > give to > > a bug report, it would be this one :) > > This is an interesting one because the problem is clear - the openssl > utility exits if it gets any error other than "file doesn't exist" trying > to open its configuration file - but the solution is not. > > The real problem isn't with openssl the utility. The problem (and it's a major one) is that this behaviour occurs when using openssl as a library and causes the application using openssl to terminate. This is appallingly bad practice for a library. > [snip > > Probably someone who's particularly bothered by this should submit a patch. > There's been a patch that's been ignored in the bug tracker for ages to at least minimise this problem on Windows by treating EACCESS the same as EPERM to handle the case of removable disks. Regards Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jan 23 16:14:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 16:14:47 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> > There's been a patch that's been ignored in the bug tracker for ages to at least minimise this problem on Windows by treating EACCESS the same as EPERM to handle the case of removable disks. Do you know the ticket number? I vaguely recall it but can't find immediately find it. I know when I looked at it I had cross-platform concerns. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From openssl-users at dukhovni.org Fri Jan 23 16:31:08 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 23 Jan 2015 16:31:08 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150123163108.GV8034@mournblade.imrryr.org> On Fri, Jan 23, 2015 at 04:06:47PM +0000, Richard Moore wrote: > > This is an interesting one because the problem is clear - the openssl > > utility exits if it gets any error other than "file doesn't exist" trying > > to open its configuration file - but the solution is not. > > The real problem isn't with openssl the utility. The problem (and it's a > major one) is that this behaviour occurs when using openssl as a library > and causes the application using openssl to terminate. This is appallingly > bad practice for a library. The documentation for OPENSSL_config() says that errors are silently ignored. However, the code (1.0.1) prints error messages to stderr and calls exit(1). That's a bug I think. Proposed fix below (leaving the stderr bits in place for now, but those also are questionable). There are also two mysterious exit(1) calls in the rsax engine. Worth taking a look at. -- Viktor. diff --git a/crypto/conf/conf_sap.c b/crypto/conf/conf_sap.c index d03de24..f8146bd 100644 --- a/crypto/conf/conf_sap.c +++ b/crypto/conf/conf_sap.c @@ -99,7 +99,6 @@ void OPENSSL_config(const char *config_name) ERR_print_errors(bio_err); BIO_free(bio_err); } - exit(1); } return; diff --git a/crypto/engine/eng_rsax.c b/crypto/engine/eng_rsax.c index 8362754..86ee9d8 100644 --- a/crypto/engine/eng_rsax.c +++ b/crypto/engine/eng_rsax.c @@ -434,10 +434,10 @@ static int mod_exp_pre_compute_data_512(UINT64 *m, struct mod_ctx_512 *data) BN_lshift(&two_512, BN_value_one(), 512); if (0 == (m[7] & 0x8000000000000000)) { - exit(1); + goto err; } if (0 == (m[0] & 0x1)) { /* Odd modulus required for Mont */ - exit(1); + goto err; } /* Precompute m1 */ From richmoore44 at gmail.com Fri Jan 23 17:01:22 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 23 Jan 2015 17:01:22 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: The ones I can find are: http://rt.openssl.org/Ticket/Display.html?id=3263 http://rt.openssl.org/Ticket/Display.html?id=2644 http://rt.openssl.org/Ticket/Display.html?id=3488 Two which seem to be suggesting the same fix. I'm also aware of bugs in the Qt bug tracker, my work's internal bug tracker and the curl bug tracker as a result of this, so I know it's not just a theoretical issue. Cheers Rich. On 23 January 2015 at 16:14, Salz, Rich wrote: > > There's been a patch that's been ignored in the bug tracker for ages to > at least minimise this problem on Windows by treating EACCESS the same as > EPERM to handle the case of removable disks. > > Do you know the ticket number? I vaguely recall it but can't find > immediately find it. I know when I looked at it I had cross-platform > concerns. > > -- > Principal Security Engineer, Akamai Technologies > IM: rsalz at jabber.me Twitter: RichSalz > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jan 23 17:22:22 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 17:22:22 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <66dc2f16cbc54a5094cd03b2df433100@usma1ex-dag1mb2.msg.corp.akamai.com> Thanks for the links. I understand it's a real issue. The concern is will windows return EACCESS for cases when there really is access denied? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Jan 23 17:26:42 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 23 Jan 2015 17:26:42 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <66dc2f16cbc54a5094cd03b2df433100@usma1ex-dag1mb2.msg.corp.akamai.com> References: <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> <66dc2f16cbc54a5094cd03b2df433100@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150123172641.GZ8034@mournblade.imrryr.org> On Fri, Jan 23, 2015 at 05:22:22PM +0000, Salz, Rich wrote: > Thanks for the links. I understand it's a real issue. The > concern is will windows return EACCESS for cases when there really > is access denied? I think we're asking the wrong questions here. Whatever the error, the decision to continue running or not is up to the application, not the library. Or are we talking about something other than OPENSSL_config() exiting when the config file cannot be read? -- Viktor. From rsalz at akamai.com Fri Jan 23 17:30:33 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 17:30:33 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <20150123172641.GZ8034@mournblade.imrryr.org> References: <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> <66dc2f16cbc54a5094cd03b2df433100@usma1ex-dag1mb2.msg.corp.akamai.com> <20150123172641.GZ8034@mournblade.imrryr.org> Message-ID: <7503b39a515a4b3b9c65483e55e40c8d@usma1ex-dag1mb2.msg.corp.akamai.com> > Or are we talking about something other than OPENSSL_config() exiting > when the config file cannot be read? It's a variant of this. File not existing is silently ignored. Windows will return EACCESS if the drive isn't ready, and that is not silently ignored. The concern is if windows will return EACCESS for real access problems. From richmoore44 at gmail.com Fri Jan 23 17:32:06 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 23 Jan 2015 17:32:06 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: <66dc2f16cbc54a5094cd03b2df433100@usma1ex-dag1mb2.msg.corp.akamai.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> <66dc2f16cbc54a5094cd03b2df433100@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 23 January 2015 at 17:22, Salz, Rich wrote: > Thanks for the links. I understand it's a real issue. The concern is > will windows return EACCESS for cases when there really is access denied? > > No, if it's file permissions you get EPERM. EACCESS is weirder things like opening a directory fopen(), see https://msdn.microsoft.com/en-us/library/5814770t.aspx Cheers Rich. > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jan 23 17:41:43 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 17:41:43 +0000 Subject: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others In-Reply-To: References: <56A41A14DF41784FA3CA37EF5760F2751F07B567D8@MX30A.corp.emc.com> <675c13d2d7d747159db2dc4410159e85@usma1ex-dag1mb2.msg.corp.akamai.com> <2768e6a0bfc94bd0939189e0e2a6453f@usma1ex-dag1mb2.msg.corp.akamai.com> <26b3019197fb4e11a63b0e6e4151e98b@usma1ex-dag1mb2.msg.corp.akamai.com> <66dc2f16cbc54a5094cd03b2df433100@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <7c7dc7eac4024cd38332e656f4000097@usma1ex-dag1mb2.msg.corp.akamai.com> > No, if it's file permissions you get EPERM. EACCESS is weirder things like opening a directory fopen(), see https://msdn.microsoft.com/en-us/library/5814770t.aspx Ah, thanks. Okay, we can fix that :) From michel.sales at OnLine.fr Sat Jan 24 10:34:48 2015 From: michel.sales at OnLine.fr (Michel SALES) Date: Sat, 24 Jan 2015 11:34:48 +0100 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l In-Reply-To: References: Message-ID: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> Hi, Just a quick answer : I didn't find any call to CloseHandle() function in your code. Best regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Avery.A.Tarasov at SecurityEngineer.Pro Sat Jan 24 21:34:14 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Sat, 24 Jan 2015 16:34:14 -0500 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l In-Reply-To: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> References: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> Message-ID: <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> Hi Michel, It doesn't appear to be related to that. I added CloseHandle's and got the same result. Here are my updated findings... The following simple program still causes the same Handle Leaks... Important findings: *1) * If SSL_library_init() and SSL_load_error_strings() are *removed* (which are the only 2 OpenSSL functions I'm using).... the handle leaks go away.. *2)* If SSL_library_init() and SSL_load_error_strings() are *kept* but the creation of the thread is *removed* -- no more handle leaks.. So the problem is something related to the combination of loading OpenSSL and creating a thread (even though that thread does nothing whatsoever related to OpenSSL). Very odd. DWORD __stdcall thread1(LPVOID l) { while(1) { Sleep(1000); } } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { * SSL_library_init();** // if these 2 lines removed ** SSL_load_error_strings(); **// no more handle leaks* DWORD t1; HANDLE h1=CreateThread(0,0,thread1,0,0,&t1); if(h1==0) { return 0; } CloseHandle(h1); *//if **SSL_library_init();***and *SSL_load_error_strings(); *are *kept *but this line is *removed... no more handle leaks* while(1) { Sleep(1000); } } Address / Handle: 0x0000C001 shmem-win32.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:01:45:503ms) Sequence: 11 sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] sslleak.exe _fc_key_init_once : [unwind-sjlj.c Line 0] sslleak.exe _main : [crt0_c.c Line 0] sslleak.exe ___tmainCRTStartup : [crtexe.c Line 0] kernel32.dll BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0] ntdll.dll RtlInitializeExceptionChain : [{FUNC}RtlInitializeExceptionChain Line 0] Address / Handle: 0x0000C00F shmem-win32.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:02:29:683ms) Sequence: 97 sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] Address / Handle: 0x0000C016 shmem.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:03:02:693ms) Sequence: 143 sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] Address / Handle: 0x0000C009 shmem.c sslleak.exe Atom 0 bytes Thread ID: 6736 1/22 18:48:09 990ms (Lifetime:00:03:22:364ms) Sequence: 61 sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe _mutex_static_init : [mutex.c Line 0] sslleak.exe _pop_pthread_mem : [thread.c Line 0] sslleak.exe _pop_pthread_mem : [thread.c Line 0] On 1/24/2015 5:34 AM, Michel SALES wrote: > > Hi, > > Just a quick answer : I didn't find any call to CloseHandle() function > in your code. > > Best regards, > > Michel. > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Sun Jan 25 09:48:12 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 25 Jan 2015 10:48:12 +0100 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l In-Reply-To: <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> References: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> Message-ID: <20150125094812.GA17453@roeckx.be> On Sat, Jan 24, 2015 at 04:34:14PM -0500, Avery A. Tarasov wrote: > > Important findings: > > *1) * If SSL_library_init() and SSL_load_error_strings() are *removed* > (which are the only 2 OpenSSL functions I'm using).... the handle leaks go > away.. > > *2)* If SSL_library_init() and SSL_load_error_strings() are *kept* but > the creation of the thread is *removed* -- no more handle leaks.. And that thread is clean up? You know a thread has a handle too? Kurt From michel.sales at OnLine.fr Sun Jan 25 11:05:48 2015 From: michel.sales at OnLine.fr (Michel SALES) Date: Sun, 25 Jan 2015 12:05:48 +0100 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l In-Reply-To: <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> References: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> Message-ID: <000601d0388e$e06bff70$a143fe50$@sales@OnLine.fr> Hi Avery, I am afraid your program demonstrates very little. If you load OpenSSL library, you have to call some of the OpenSSL free functions as indicated in a previous post, and if you create a thread, you have to call CloseHandle() : #include #include #include #include DWORD __stdcall thread1( LPVOID l ) { for( int i=0; i<7; i++ ) Sleep(1000); ERR_remove_state(0); return 0; } int main( int argc, char* argv[] ) { // _crtBreakAlloc = ...; SSL_library_init(); SSL_load_error_strings(); DWORD t1; HANDLE h1 = CreateThread( 0, 0, thread1, 0, 0, &t1 ); for( int i=0; i<7; i++ ) Sleep(1000); if( h1 ) { WaitForSingleObject( thread1, INFINITE ); CloseHandle( h1 ); } ERR_remove_state(0); EVP_cleanup(); ERR_free_strings(); CRYPTO_cleanup_all_ex_data(); sk_SSL_COMP_free( SSL_COMP_get_compression_methods()); _CrtDumpMemoryLeaks(); return 0; } Hope it helps, Michel De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Avery A. Tarasov Envoy??: samedi 24 janvier 2015 22:34 ??: openssl-users at openssl.org Objet?: Re: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l Hi Michel, It doesn't appear to be related to that.? I added CloseHandle's and got the same result. Here are my updated findings... The following simple program still causes the same Handle Leaks... Important findings: 1)? If ?? SSL_library_init() and SSL_load_error_strings() are removed (which are the only 2 OpenSSL functions I'm using).... the handle leaks go away.. 2)? If ?? SSL_library_init() and SSL_load_error_strings() are kept but the creation of the thread is removed? -- no more handle leaks.. So the problem is something related to the combination of loading OpenSSL and creating a thread (even though that thread does nothing whatsoever related to OpenSSL).? Very odd. DWORD __stdcall thread1(LPVOID l) { ??? while(1) ??? {?? Sleep(1000); ?? } } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { ???? SSL_library_init();?? // if these 2 lines removed ??? SSL_load_error_strings();? // no more handle leaks ??? DWORD t1; ??? ??? HANDLE h1=CreateThread(0,0,thread1,0,0,&t1);? if(h1==0)? {? return 0;???? }????? CloseHandle(h1);? //if? SSL_library_init(); and SSL_load_error_strings();? are kept? but this line is removed... no more handle leaks ??? while(1) ??? { ??? ??? Sleep(1000); ??? } } From rasjv at yandex.com Sun Jan 25 16:43:14 2015 From: rasjv at yandex.com (Serj) Date: Sun, 25 Jan 2015 19:43:14 +0300 Subject: [openssl-users] Hostname validation Message-ID: <7219711422204194@web29h.yandex.ru> Hello. What is the best way to make hostname validation? 1. http://wiki.openssl.org/index.php/Hostname_validation 2. X509_check_host that was added in OpenSSL 1.1.0. I don't know does the first one support wildcards or no! Seems to be: how does Curl_cert_hostcheck work - is the answer, but I don't know how it works. So, I think the second is better and more clearly? -- Best Regards, Serj From Avery.A.Tarasov at SecurityEngineer.Pro Sun Jan 25 16:57:07 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Sun, 25 Jan 2015 11:57:07 -0500 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l In-Reply-To: <000601d0388e$e06bff70$a143fe50$@sales@OnLine.fr> References: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> <000601d0388e$e06bff70$a143fe50$@sales@OnLine.fr> Message-ID: Hi Michel, In the code I sent over before, I was calling CloseHandle on the thread: HANDLE h1=CreateThread(0,0,thread1,0,0,&t1); if(h1==0) { return 0; }*CloseHandle(h1);* I modified the code you sent slightly so the cleanup functions all get reached. Still getting handle leaks (see info at bottom of the email thread). In the code below, I check the program for leaks once the MessageBox pops up after all the cleanup functions. Then there is a 20 second pause after which the program exits. The results are the same as before.. why is it that the program doesn't leak anymore if the creation of the thread is removed which essentially does nothing? Also why is it that if all the SSL functions are removed in the program, but the thread is still created the leaks go away? Something weird is going on. It is as if OpenSSL just doesn't like the CreateThread function being used (even if the thread doesn't do anything related to OpenSSL (tried modifying code in the thread to do nothing -- e.g. blank thread). Thanks for the help, all. for( int i=0; i<7; i++ ) Sleep(1000); CloseHandle( h1 ); ERR_remove_state(0); EVP_cleanup(); ERR_free_strings(); CRYPTO_cleanup_all_ex_data(); sk_SSL_COMP_free( SSL_COMP_get_compression_methods()); _CrtDumpMemoryLeaks(); *MessageBox*(0,"gothere","gothere",0); *// at this point Handle leaks are still being reported... see data below* Sleep(20000); Address / Handle: 0x0000C001 shmem-win32.c sslleak.exe Atom 0 bytes Thread ID: 14524 1/25 11:38:34 827ms (Lifetime:00:00:39:561ms) Sequence: 11 sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] sslleak.exe _fc_key_init_once : [unwind-sjlj.c Line 0] sslleak.exe ___tmainCRTStartup : [crtexe.c Line 0] kernel32.dll BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0] ntdll.dll RtlInitializeExceptionChain : [{FUNC}RtlInitializeExceptionChain Line 0] ntdll.dll RtlInitializeExceptionChain : [{FUNC}RtlInitializeExceptionChain Line 0] Address / Handle: 0x0000C004 shmem.c sslleak.exe Atom 0 bytes Thread ID: 14524 1/25 11:38:34 827ms (Lifetime:00:00:39:561ms) Sequence: 27 sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe _mutex_ref_init : [mutex.c Line 0] sslleak.exe _enterOnceObject : [thread.c Line 0] sslleak.exe ___tmainCRTStartup : [crtexe.c Line 0] kernel32.dll BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0] ntdll.dll RtlInitializeExceptionChain : [{FUNC}RtlInitializeExceptionChain Line 0] Address / Handle: 0x0000C00F shmem-win32.c sslleak.exe Atom 0 bytes Thread ID: 14524 1/25 11:38:34 827ms (Lifetime:00:00:39:561ms) Sequence: 97 sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] sslleak.exe ___shmem_grab : [shmem-win32.c Line 0] Address / Handle: 0x0000C009 shmem.c sslleak.exe Atom 0 bytes Thread ID: 14524 1/25 11:38:34 827ms (Lifetime:00:00:39:561ms) Sequence: 61 sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe _mutex_static_init : [mutex.c Line 0] sslleak.exe _pop_pthread_mem : [thread.c Line 0] sslleak.exe _pop_pthread_mem : [thread.c Line 0] Address / Handle: 0x0000C012 shmem.c sslleak.exe Atom 0 bytes Thread ID: 14524 1/25 11:38:34 842ms (Lifetime:00:00:39:546ms) Sequence: 112 sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0] sslleak.exe _rwlock_static_init : [rwlock.c Line 0] sslleak.exe _rwlock_static_init : [rwlock.c Line 0] On 1/25/2015 6:05 AM, Michel SALES wrote: > Hi Avery, > > I am afraid your program demonstrates very little. > > If you load OpenSSL library, you have to call some of the OpenSSL free > functions as indicated in a previous post, > and if you create a thread, you have to call CloseHandle() : > > #include > #include > > #include > #include > > DWORD __stdcall thread1( LPVOID l ) > { > for( int i=0; i<7; i++ ) > Sleep(1000); > ERR_remove_state(0); > return 0; > } > > int main( int argc, char* argv[] ) > { > // _crtBreakAlloc = ...; > > SSL_library_init(); > SSL_load_error_strings(); > > DWORD t1; > HANDLE h1 = CreateThread( 0, 0, thread1, 0, 0, &t1 ); > > for( int i=0; i<7; i++ ) Sleep(1000); > > if( h1 ) { > WaitForSingleObject( thread1, INFINITE ); > CloseHandle( h1 ); > } > > ERR_remove_state(0); > EVP_cleanup(); > ERR_free_strings(); > CRYPTO_cleanup_all_ex_data(); > sk_SSL_COMP_free( SSL_COMP_get_compression_methods()); > > _CrtDumpMemoryLeaks(); > > return 0; > } > > Hope it helps, > > Michel > > > De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de > Avery A. Tarasov > Envoy? : samedi 24 janvier 2015 22:34 > ? : openssl-users at openssl.org > Objet : Re: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL > 1.0.1l > > Hi Michel, > > It doesn't appear to be related to that. I added CloseHandle's and got the > same result. > > Here are my updated findings... The following simple program still causes > the same Handle Leaks... > > Important findings: > > 1) If SSL_library_init() and SSL_load_error_strings() are removed (which > are the only 2 OpenSSL functions I'm using).... the handle leaks go away.. > 2) If SSL_library_init() and SSL_load_error_strings() are kept but the > creation of the thread is removed -- no more handle leaks.. > > So the problem is something related to the combination of loading OpenSSL > and creating a thread (even though that thread does nothing whatsoever > related to OpenSSL). Very odd. > > DWORD __stdcall thread1(LPVOID l) > { > while(1) > { Sleep(1000); } > } > int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR > lpCmdLine, int nCmdShow) { > > > SSL_library_init(); // if these 2 lines removed > SSL_load_error_strings(); // no more handle leaks > DWORD t1; > > HANDLE h1=CreateThread(0,0,thread1,0,0,&t1); if(h1==0) { return > 0; } CloseHandle(h1); //if SSL_library_init(); and > SSL_load_error_strings(); are kept but this line is removed... no more > handle leaks > > > while(1) > { > Sleep(1000); > } > } > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasjv at yandex.com Sun Jan 25 17:06:34 2015 From: rasjv at yandex.com (Serj) Date: Sun, 25 Jan 2015 20:06:34 +0300 Subject: [openssl-users] Hostname validation In-Reply-To: <7219711422204194@web29h.yandex.ru> References: <7219711422204194@web29h.yandex.ru> Message-ID: <7259801422205594@web29h.yandex.ru> Hi, I found in CURL's sources that function: Curl_cert_hostcheck Seems to be it support wildcards and my question is still the same: what is the best way to make hostname validation? Maybe from practise somebody knows what is the better? CURLS's hostcheck.c: /* * Match a hostname against a wildcard pattern. * E.g. * "foo.host.com" matches "*.host.com". * * We use the matching rule described in RFC6125, section 6.4.3. * http://tools.ietf.org/html/rfc6125#section-6.4.3 * * In addition: ignore trailing dots in the host names and wildcards, so that * the names are used normalized. This is what the browsers do. * * Do not allow wildcard matching on IP numbers. There are apparently * certificates being used with an IP address in the CN field, thus making no * apparent distinction between a name and an IP. We need to detect the use of * an IP address and not wildcard match on such names. * * NOTE: hostmatch() gets called with copied buffers so that it can modify the * contents at will. */ static int hostmatch(char *hostname, char *pattern) { const char *pattern_label_end, *pattern_wildcard, *hostname_label_end; int wildcard_enabled; size_t prefixlen, suffixlen; struct in_addr ignored; #ifdef ENABLE_IPV6 struct sockaddr_in6 si6; #endif /* normalize pattern and hostname by stripping off trailing dots */ size_t len = strlen(hostname); if(hostname[len-1]=='.') hostname[len-1]=0; len = strlen(pattern); if(pattern[len-1]=='.') pattern[len-1]=0; pattern_wildcard = strchr(pattern, '*'); if(pattern_wildcard == NULL) return Curl_raw_equal(pattern, hostname) ? CURL_HOST_MATCH : CURL_HOST_NOMATCH; /* detect IP address as hostname and fail the match if so */ if(Curl_inet_pton(AF_INET, hostname, &ignored) > 0) return CURL_HOST_NOMATCH; #ifdef ENABLE_IPV6 else if(Curl_inet_pton(AF_INET6, hostname, &si6.sin6_addr) > 0) return CURL_HOST_NOMATCH; #endif /* We require at least 2 dots in pattern to avoid too wide wildcard match. */ wildcard_enabled = 1; pattern_label_end = strchr(pattern, '.'); if(pattern_label_end == NULL || strchr(pattern_label_end+1, '.') == NULL || pattern_wildcard > pattern_label_end || Curl_raw_nequal(pattern, "xn--", 4)) { wildcard_enabled = 0; } if(!wildcard_enabled) return Curl_raw_equal(pattern, hostname) ? CURL_HOST_MATCH : CURL_HOST_NOMATCH; hostname_label_end = strchr(hostname, '.'); if(hostname_label_end == NULL || !Curl_raw_equal(pattern_label_end, hostname_label_end)) return CURL_HOST_NOMATCH; /* The wildcard must match at least one character, so the left-most label of the hostname is at least as large as the left-most label of the pattern. */ if(hostname_label_end - hostname < pattern_label_end - pattern) return CURL_HOST_NOMATCH; prefixlen = pattern_wildcard - pattern; suffixlen = pattern_label_end - (pattern_wildcard+1); return Curl_raw_nequal(pattern, hostname, prefixlen) && Curl_raw_nequal(pattern_wildcard+1, hostname_label_end - suffixlen, suffixlen) ? CURL_HOST_MATCH : CURL_HOST_NOMATCH; } int Curl_cert_hostcheck(const char *match_pattern, const char *hostname) { char *matchp; char *hostp; int res = 0; if(!match_pattern || !*match_pattern || !hostname || !*hostname) /* sanity check */ ; else { matchp = strdup(match_pattern); if(matchp) { hostp = strdup(hostname); if(hostp) { if(hostmatch(hostp, matchp) == CURL_HOST_MATCH) res= 1; free(hostp); } free(matchp); } } return res; } From openssl-users at dukhovni.org Sun Jan 25 17:57:06 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 25 Jan 2015 17:57:06 +0000 Subject: [openssl-users] Hostname validation In-Reply-To: <7219711422204194@web29h.yandex.ru> References: <7219711422204194@web29h.yandex.ru> Message-ID: <20150125175706.GN8034@mournblade.imrryr.org> On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: > What is the best way to make hostname validation? > > 1. http://wiki.openssl.org/index.php/Hostname_validation > 2. X509_check_host that was added in OpenSSL 1.1.0. The X509_check_host() interface is also available in OpenSSL 1.0.2 released a few days ago https://www.openssl.org/docs/crypto/X509_check_host.html (the documentation should be updated to note the earlier availability). Starting with 1.0.2, you can also ask OpenSSL to automatically perform hostname checks during the SSL handshake on the application's behalf: https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html https://www.openssl.org/docs/ssl/SSL_set_verify.html Sadly, we're still lacking documentation of SSL_get0_param() which is needed for a complete SSL hostname check recipe: const char *servername; SSL *ssl; X509_VERIFY_PARAM *param; servername = "www.example.com"; ssl = SSL_new(...); param = SSL_get0_param(ssl); /* Enable automatic hostname checks */ X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); /* Configure a non-zero callback if desired */ SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); /* * Establish SSL connection, hostname should be checked * automatically test with a hostname that should not match, * the connection will fail (unless you specify a callback * that returns despite the verification failure. In that * case SSL_get_verify_status() can expose the problem after * connection completion. */ ... > I don't know does the first one support wildcards or no! Seems > to be: how does Curl_cert_hostcheck work - is the answer, but I > don't know how it works. Wildcard support is configured via the flags documented for X509_check_host(), the two most frequently useful are: X509_CHECK_FLAG_NO_WILDCARDS X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS -- Viktor. From michel.sales at OnLine.fr Sun Jan 25 18:49:21 2015 From: michel.sales at OnLine.fr (Michel SALES) Date: Sun, 25 Jan 2015 19:49:21 +0100 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l In-Reply-To: References: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> <000601d0388e$e06bff70$a143fe50$@sales@OnLine.fr> Message-ID: <001301d038cf$a1dee6f0$e59cb4d0$@sales@OnLine.fr> Hi Avery, > In the code I sent over before, I was calling CloseHandle on the thread: > HANDLE h1=CreateThread(0,0,thread1,0,0,&t1);? if(h1==0)?{?return 0;?}?CloseHandle(h1); Yes, but you were trying to close the handle of a thread which was still running ! I have not checked what happens in this case. I am not sure to fully understand what your are doing now, but with the modified version I've sent to you, _CrtDumpMemoryLeaks() doesn't report any problem on my Windows 7 64 bits machine. Just another quick idea : why not try _beginthread() instead of CreateThread() ? Michel From Avery.A.Tarasov at SecurityEngineer.Pro Sun Jan 25 20:34:14 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Sun, 25 Jan 2015 15:34:14 -0500 Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l In-Reply-To: <001301d038cf$a1dee6f0$e59cb4d0$@sales@OnLine.fr> References: <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr> <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com> <000601d0388e$e06bff70$a143fe50$@sales@OnLine.fr> <001301d038cf$a1dee6f0$e59cb4d0$@sales@OnLine.fr> Message-ID: <0d853b585dee5b0122b8891fb29b2f78@smtp.hushmail.com> Hi Michel, I actually already tried _beginthread but got the same results. CrtDumpMemoryLeaks also reports no problems for me. I guess the tool I was using for leak detection just has some bugs in it. Thanks again for your help. Best Regards, -Avery On 1/25/2015 1:49 PM, Michel SALES wrote: > Hi Avery, > >> In the code I sent over before, I was calling CloseHandle on the thread: >> HANDLE h1=CreateThread(0,0,thread1,0,0,&t1); if(h1==0) { return > 0; } CloseHandle(h1); > > Yes, but you were trying to close the handle of a thread which was still > running ! > I have not checked what happens in this case. > > I am not sure to fully understand what your are doing now, but with the > modified version I've sent to you, _CrtDumpMemoryLeaks() doesn't report any > problem on my Windows 7 64 bits machine. > > Just another quick idea : why not try _beginthread() instead of > CreateThread() ? > > Michel > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasjv at yandex.com Mon Jan 26 10:03:16 2015 From: rasjv at yandex.com (Serj) Date: Mon, 26 Jan 2015 13:03:16 +0300 Subject: [openssl-users] Hostname validation In-Reply-To: <20150125175706.GN8034@mournblade.imrryr.org> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> Message-ID: <5985561422266596@web20h.yandex.ru> 25.01.2015, 20:59, "Viktor Dukhovni" : > ?On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: >> ??What is the best way to make hostname validation? >> >> ??1. http://wiki.openssl.org/index.php/Hostname_validation >> ??2. X509_check_host that was added in OpenSSL 1.1.0. > ?The X509_check_host() interface is also available in OpenSSL 1.0.2 > ?released a few days ago > > ?????https://www.openssl.org/docs/crypto/X509_check_host.html > > ?(the documentation should be updated to note the earlier availability). > > ?Starting with 1.0.2, you can also ask OpenSSL to automatically > ?perform hostname checks during the SSL handshake on the application's > ?behalf: > > ?????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html > ?????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html > ?????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html > ?????https://www.openssl.org/docs/ssl/SSL_set_verify.html > > ?Sadly, we're still lacking documentation of SSL_get0_param() which > ?is needed for a complete SSL hostname check recipe: > > ?????????const char *servername; > ?????????SSL *ssl; > ?????????X509_VERIFY_PARAM *param; > > ?????????servername = "www.example.com"; > ?????????ssl = SSL_new(...); > ?????????param = SSL_get0_param(ssl); > > ?????????/* Enable automatic hostname checks */ > ?????????X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > ?????????X509_VERIFY_PARAM_set1_host(param, servername, 0); > > ?????????/* Configure a non-zero callback if desired */ > ?????????SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); > > ?????????/* > ??????????* Establish SSL connection, hostname should be checked > ??????????* automatically test with a hostname that should not match, > ??????????* the connection will fail (unless you specify a callback > ??????????* that returns despite the verification failure. ?In that > ??????????* case SSL_get_verify_status() can expose the problem after > ??????????* connection completion. > ??????????*/ > ??????????... >> ??I don't know does the first one support wildcards or no! Seems >> ??to be: how does Curl_cert_hostcheck work - is the answer, but I >> ??don't know how it works. > ?Wildcard support is configured via the flags documented for X509_check_host(), > ?the two most frequently useful are: > > ?????????X509_CHECK_FLAG_NO_WILDCARDS > ?????????X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS > > ?-- > ?????????Viktor. > ?_______________________________________________ > ?openssl-users mailing list > ?To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Best Regards, Serj 25.01.2015, 20:59, "Viktor Dukhovni" : > On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: >> ?What is the best way to make hostname validation? >> >> ?1. http://wiki.openssl.org/index.php/Hostname_validation >> ?2. X509_check_host that was added in OpenSSL 1.1.0. > > The X509_check_host() interface is also available in OpenSSL 1.0.2 > released a few days ago > > ????https://www.openssl.org/docs/crypto/X509_check_host.html > > (the documentation should be updated to note the earlier availability). > > Starting with 1.0.2, you can also ask OpenSSL to automatically > perform hostname checks during the SSL handshake on the application's > behalf: > > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html > ????https://www.openssl.org/docs/ssl/SSL_set_verify.html > > Sadly, we're still lacking documentation of SSL_get0_param() which > is needed for a complete SSL hostname check recipe: > > ????????const char *servername; > ????????SSL *ssl; > ????????X509_VERIFY_PARAM *param; > > ????????servername = "www.example.com"; > ????????ssl = SSL_new(...); > ????????param = SSL_get0_param(ssl); > > ????????/* Enable automatic hostname checks */ > ????????X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > ????????X509_VERIFY_PARAM_set1_host(param, servername, 0); > > ????????/* Configure a non-zero callback if desired */ > ????????SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); > > ????????/* > ?????????* Establish SSL connection, hostname should be checked > ?????????* automatically test with a hostname that should not match, > ?????????* the connection will fail (unless you specify a callback > ?????????* that returns despite the verification failure. ?In that > ?????????* case SSL_get_verify_status() can expose the problem after > ?????????* connection completion. > ?????????*/ > ?????????... >> ?I don't know does the first one support wildcards or no! Seems >> ?to be: how does Curl_cert_hostcheck work - is the answer, but I >> ?don't know how it works. > > Wildcard support is configured via the flags documented for X509_check_host(), > the two most frequently useful are: > > ????????X509_CHECK_FLAG_NO_WILDCARDS > ????????X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS > > -- > ????????Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Best Regards, Serj From rasjv at yandex.com Mon Jan 26 10:07:54 2015 From: rasjv at yandex.com (Serj) Date: Mon, 26 Jan 2015 13:07:54 +0300 Subject: [openssl-users] Hostname validation In-Reply-To: <20150125175706.GN8034@mournblade.imrryr.org> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> Message-ID: <6012611422266874@web20h.yandex.ru> Hi, Thank you for answer. So, your recomendation is to use X509_check_host rather than code from wiki? 25.01.2015, 20:59, "Viktor Dukhovni" : > On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: > Starting with 1.0.2, you can also ask OpenSSL to automatically > perform hostname checks during the SSL handshake on the application's > behalf: > > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html > ????https://www.openssl.org/docs/ssl/SSL_set_verify.html > > Sadly, we're still lacking documentation of SSL_get0_param() which > is needed for a complete SSL hostname check recipe: > > ????????const char *servername; > ????????SSL *ssl; > ????????X509_VERIFY_PARAM *param; > > ????????servername = "www.example.com"; > ????????ssl = SSL_new(...); > ????????param = SSL_get0_param(ssl); > > ????????/* Enable automatic hostname checks */ > ????????X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > ????????X509_VERIFY_PARAM_set1_host(param, servername, 0); > > ????????/* Configure a non-zero callback if desired */ > ????????SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); > > ????????/* > ?????????* Establish SSL connection, hostname should be checked > ?????????* automatically test with a hostname that should not match, > ?????????* the connection will fail (unless you specify a callback > ?????????* that returns despite the verification failure. ?In that > ?????????* case SSL_get_verify_status() can expose the problem after > ?????????* connection completion. > ?????????*/ > ?????????... >> ?I don't know does the first one support wildcards or no! Seems >> ?to be: how does Curl_cert_hostcheck work - is the answer, but I >> ?don't know how it works. > > Wildcard support is configured via the flags documented for X509_check_host(), > the two most frequently useful are: > > ????????X509_CHECK_FLAG_NO_WILDCARDS > ????????X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS > > -- > ????????Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Best Regards, Serj From openssl-users at dukhovni.org Mon Jan 26 15:10:58 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Jan 2015 15:10:58 +0000 Subject: [openssl-users] Hostname validation In-Reply-To: <6012611422266874@web20h.yandex.ru> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> <6012611422266874@web20h.yandex.ru> Message-ID: <20150126151057.GS8034@mournblade.imrryr.org> On Mon, Jan 26, 2015 at 01:07:54PM +0300, Serj wrote: > Thank you for answer. > > So, your recomendation is to use X509_check_host rather than code from wiki? Yes, definitely, provided of course you're linking with OpenSSL 1.0.2 or later. -- Viktor. From openssl-users at dukhovni.org Mon Jan 26 15:16:34 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Jan 2015 15:16:34 +0000 Subject: [openssl-users] Hostname validation In-Reply-To: <20150126151057.GS8034@mournblade.imrryr.org> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> <6012611422266874@web20h.yandex.ru> <20150126151057.GS8034@mournblade.imrryr.org> Message-ID: <20150126151634.GT8034@mournblade.imrryr.org> On Mon, Jan 26, 2015 at 03:10:57PM +0000, Viktor Dukhovni wrote: > On Mon, Jan 26, 2015 at 01:07:54PM +0300, Serj wrote: > > > Thank you for answer. > > > > So, your recomendation is to use X509_check_host rather than code from wiki? > > Yes, definitely, provided of course you're linking with OpenSSL > 1.0.2 or later. To be precise, my recommendation is to populate the X509_VERIFY_PARAMS with the desired hostname, and let the OpenSSL code call X509_check_host automatically. Exactly as shown in my original reply. This makes it easier to some day enable DANE TLSA support, because with DANE, name checks need to be skipped for DANE-EE(3) TLSA records, as the DNSSEC TLSA records provides the requisite name binding instead. Also with the X509_VERIFY_PARAM approach, name checks happen early, and for applications that don't continue handshakes with unauthenticated peers, terminate as early as possible. There is an associated new X509 error code: X509_V_ERR_HOSTNAME_MISMATCH -- Viktor. From pl at artisanlogiciel.net Mon Jan 26 17:58:14 2015 From: pl at artisanlogiciel.net (pl) Date: Mon, 26 Jan 2015 18:58:14 +0100 Subject: [openssl-users] Hostname validation In-Reply-To: <20150126151634.GT8034@mournblade.imrryr.org> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> <6012611422266874@web20h.yandex.ru> <20150126151057.GS8034@mournblade.imrryr.org> <20150126151634.GT8034@mournblade.imrryr.org> Message-ID: <54C68036.8030505@artisanlogiciel.net> On 26/01/2015 16:16, Viktor Dukhovni wrote: > On Mon, Jan 26, 2015 at 03:10:57PM +0000, Viktor Dukhovni wrote: > >> On Mon, Jan 26, 2015 at 01:07:54PM +0300, Serj wrote: >> >>> Thank you for answer. >>> >>> So, your recomendation is to use X509_check_host rather than code from wiki? >> Yes, definitely, provided of course you're linking with OpenSSL >> 1.0.2 or later. I updated wiki accordingly, hoping to be more accurate. From openssl-users at dukhovni.org Mon Jan 26 18:50:38 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Jan 2015 18:50:38 +0000 Subject: [openssl-users] Hostname validation In-Reply-To: <54C68036.8030505@artisanlogiciel.net> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> <6012611422266874@web20h.yandex.ru> <20150126151057.GS8034@mournblade.imrryr.org> <20150126151634.GT8034@mournblade.imrryr.org> <54C68036.8030505@artisanlogiciel.net> Message-ID: <20150126185038.GY8034@mournblade.imrryr.org> On Mon, Jan 26, 2015 at 06:58:14PM +0100, pl wrote: > On 26/01/2015 16:16, Viktor Dukhovni wrote: > >On Mon, Jan 26, 2015 at 03:10:57PM +0000, Viktor Dukhovni wrote: > > > >>On Mon, Jan 26, 2015 at 01:07:54PM +0300, Serj wrote: > >> > >>>Thank you for answer. > >>> > >>>So, your recomendation is to use X509_check_host rather than code from wiki? > >>Yes, definitely, provided of course you're linking with OpenSSL > >>1.0.2 or later. > > I updated wiki accordingly, hoping to be more accurate. Thanks, could you also add the sample code fragment, without it the text is a bit obscure. -- Viktor. From pl at artisanlogiciel.net Mon Jan 26 19:20:40 2015 From: pl at artisanlogiciel.net (pl) Date: Mon, 26 Jan 2015 20:20:40 +0100 Subject: [openssl-users] Hostname validation In-Reply-To: <20150126185038.GY8034@mournblade.imrryr.org> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> <6012611422266874@web20h.yandex.ru> <20150126151057.GS8034@mournblade.imrryr.org> <20150126151634.GT8034@mournblade.imrryr.org> <54C68036.8030505@artisanlogiciel.net> <20150126185038.GY8034@mournblade.imrryr.org> Message-ID: <54C69388.2020309@artisanlogiciel.net> On 26/01/2015 19:50, Viktor Dukhovni wrote: > On Mon, Jan 26, 2015 at 06:58:14PM +0100, pl wrote: > >> On 26/01/2015 16:16, Viktor Dukhovni wrote: >>> On Mon, Jan 26, 2015 at 03:10:57PM +0000, Viktor Dukhovni wrote: >>> >>>> On Mon, Jan 26, 2015 at 01:07:54PM +0300, Serj wrote: >>>> >>>>> Thank you for answer. >>>>> >>>>> So, your recomendation is to use X509_check_host rather than code from wiki? >>>> Yes, definitely, provided of course you're linking with OpenSSL >>>> 1.0.2 or later. >> I updated wiki accordingly, hoping to be more accurate. > Thanks, could you also add the sample code fragment, without it > the text is a bit obscure. > done From jonetsu at teksavvy.com Mon Jan 26 23:21:41 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Mon, 26 Jan 2015 18:21:41 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <54B92B60.1020206@openssl.com> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> Message-ID: <20150126182141.0e668279@mevla> On Fri, 16 Jan 2015 10:16:48 -0500 Steve Marquess wrote: > On 01/15/2015 05:52 AM, Marcus Meissner wrote: >> On Linux usually triggered by /proc/sys/crypto/fips_enabled >> containing "1" or the environment variable >> OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and >> Redhat, which do not use the container blob). > That is (presumably) true for the proprietary RH and SUSE distros, > not so for the open source based OpenSSL FIPS Object Module or other > Linux distros. I'm afraid it does not come across clear to me. So, maybe the following pondering is relevant - or not. Basically, I'm looking at how to integrate a FIPS-enabled OpenSSL that will be used by some common Open Sources applications, as well as a 3rd party application (with source code provided). So, does your comment mean that the paying versions of Red Hat and SuSE (proprietary) have open source applications modified to at least include the FIPS_mode_set() call ? Why would these releases be different in FIPS SSL 'power-up' POST checks when compared to regular free releases ? If I compare with GnuTLS that our product also uses, and with which it will also go to certification, its FIPS mode is completly transparent, with FIPS checks done on library load. Based on the discussion in 'The I.G. 9.5 Issue', I took a look at 'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program', January 15 2015 release. In section 9.10 it states: "The power-on self-tests of the module shall be triggered from within that library function or code block. This execution paradigm satisfies AS09.08 and AS09.09 for a validated module." This would make it OK for OpenSSL to automatically run the FIPS checks when an application loads the library. Are the issues noted in the 'I.G. 9.5 Issue' still relevant ? For instance, the first paragraph of Q4 refers to an application using the library before the library itself has finished doing the FIPS POST checks. Hmmm. without knowing the details I must say, it 'looks like' GnuTLS has solved this problem - or will it simply fail certification lab testing ? Further in the CMVP IG, there is mention that ('DEP' is a default entry point) : "The presence of a library DEP forces the OS loader to call the DEP when it loads the library on behalf of the application linking it. The DEP is executed automatically and independently of the application code before the OS loader hands control back to the application. The OS loader utilizes a standard mechanism for invoking the DEP, which is agnostic of the library programming interface and completely independent of the application code." Wouldn't this mechanism be solving the problems raised in Q4 ? Regards. From thomas.francis.jr at pobox.com Tue Jan 27 03:35:12 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Mon, 26 Jan 2015 22:35:12 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <20150126182141.0e668279@mevla> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> Message-ID: <90213D48-C5A8-407D-BF02-945CA191EE58@pobox.com> > On Jan 26, 2015, at 6:21 PM, jonetsu at teksavvy.com wrote: > > On Fri, 16 Jan 2015 10:16:48 -0500 > Steve Marquess wrote: > >> On 01/15/2015 05:52 AM, Marcus Meissner wrote: > >>> On Linux usually triggered by /proc/sys/crypto/fips_enabled >>> containing "1" or the environment variable >>> OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and >>> Redhat, which do not use the container blob). > >> That is (presumably) true for the proprietary RH and SUSE distros, >> not so for the open source based OpenSSL FIPS Object Module or other >> Linux distros. > > I'm afraid it does not come across clear to me. So, maybe the > following pondering is relevant - or not. Basically, I'm looking at > how to integrate a FIPS-enabled OpenSSL that will be used by some > common Open Sources applications, as well as a 3rd party application > (with source code provided). This is a bad idea. It can generally be done, and it?s probably not even too hard (for some uses, anyway). But it?s a bad idea. Here?s why: 1) Applications that don?t know they?re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode. Because the application wasn?t designed for this situation, if the algorithm is attempted through the proper APIs, use of the algorithm will fail, and the application?s error report will be incorrect (assuming it even handles the error coming from OpenSSL, and doesn?t fail much later!). 2) Applications that don?t know they?re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode, but using an API that will actually succeed. This will cause issues for the USER, since the user believes the application is operating properly in FIPS mode, when it just did something that?s disallowed! 3) Applications that don?t know they?re operating in FIPS mode may attempt to use SHA-1 in operations that are disallowed in FIPS mode. OpenSSL will allow most uses of SHA-1 in FIPS mode, relying on the application to only use it appropriately. Again, this can cause problems for the user who thinks the application is operating in FIPS mode, but the application has done things that are disallowed! 4) If POST fails or some other problem is detected, where FIPS mode fails to be enabled, an application that doesn?t know anything about FIPS mode will fail in a manner unexpected by the application. Even if you?ve found a way to notify the user (ha! how you gonna do that not knowing if the application is graphical or not, has access to stderr, syslog, or something else entirely?), the application?s failure may not release resources appropriately, or may cause other problems, especially for the end user who keeps trying it over and over again. :) Someone who controls all the applications on a system, however, that one could deal with all of those issues and more. It?d be expensive, and one would probably be unwilling to give that work away whenever one doesn?t have to. :) I?ll let Steve answer the stuff I snipped. :) TOM From mirfan at intelligentsiasoftware.com Tue Jan 27 04:09:40 2015 From: mirfan at intelligentsiasoftware.com (Muhammad Irfan) Date: Tue, 27 Jan 2015 09:09:40 +0500 Subject: [openssl-users] unsubscribe Message-ID: <002101d039e7$1455a490$3d00edb0$@intelligentsiasoftware.com> -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of mclellan, dave Sent: Friday, January 23, 2015 6:17 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others Thanks again. I had returned to the conf_def.c file and saw the logic that essentially summarizes your detailed sequence. The workaround you suggested of specifying OPENSSL_CONF is a variation of what I had given our QA team (the original reporter of the issue on AIX), and this indeed circumvented the issue. Thanks to all for all the interest in and traffic on this question. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclellan at emc.com +-+-+-+-+-+-+-+-+- -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Thursday, January 22, 2015 5:34 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Salz, Rich > Sent: Thursday, January 22, 2015 16:37 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] missing default > /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all > others > > > I can't. The behavior of fopen is defined by ISO 9899 and the Single > > UNIX Specfication, which AIX has adhered to for well over a decade. > > I meant no disrespect to big blue :) I worked there for a > half-decade, and also with them on standards for a lot longer... > > > int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); > > perror("fopen"); > > And what happens if some of the directories on the path don't exist? Depends on which of the following happens first: - open(2) encounters a missing directory: ENOENT. - open(2) encounters a non-traversable directory: EACCES. (I wrote "EPERM" in an earlier note, but I don't think that's even a real errno value name. Duh.) - open(2) gets all the way to the file but doesn't have sufficient permission: ENOENT. - Some other I/O error occurs (broken NFS mount, etc): some other errno value, or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets fopen set EACCES, EINTR (if open is "slow" and gets interrupted by a signal), EISDIR, ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should only happen for file creation), ENOTDIR (if you have a non-directory as a non-terminal path component), ENXIO (trying to open a special node in an unsupported way), EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY. A quick look at apps/openssl.c suggests that it'll abort if it gets anything other than CONF_R_NO_SUCH_FILE from ERR_GET_REASON(ERR_peek_last_error()) after NCONF_load fails. That doesn't clarify things much, though I'd suggest that it might be worth suppressing this behavior via an option. If the user knows there's no configuration file, the following should work (under suitable shells): OPENSSL_CONF=/dev/null openssl ... Just let openssl open /dev/null as its config file. It'll get EOF immediately (as if openssl.cnf existed and was empty) and should trundle along happily. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rasjv at yandex.com Tue Jan 27 13:18:49 2015 From: rasjv at yandex.com (Serj) Date: Tue, 27 Jan 2015 16:18:49 +0300 Subject: [openssl-users] Hostname validation In-Reply-To: <20150125175706.GN8034@mournblade.imrryr.org> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> Message-ID: <2157801422364729@web28o.yandex.ru> Hi, Viktor. I have some questions. I didn't find docs on such functions as SSL_get0_param Why there is no corresponding functions as SSL_set0_param in your code? Where can I found documentation on functions operating with params? I found only this code: X509_VERIFY_PARAM *param; param = X509_VERIFY_PARAM_new(); X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK); SSL_CTX_set1_param(ctx, param); X509_VERIFY_PARAM_free(param); here: https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html But there is no any description how SSL_CTX_set1_param works! Does it clear all previous flags on CTX or "ORing" with them? And there are no any docs on "GET" params functions! For example, like docs on SSL_CTX_set_options,SSL_CTX_get_option,SSL_set_options,SSL_get_options. -- Best Regards, Serj 25.01.2015, 20:59, "Viktor Dukhovni" : > On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: >> ?What is the best way to make hostname validation? >> >> ?1. http://wiki.openssl.org/index.php/Hostname_validation >> ?2. X509_check_host that was added in OpenSSL 1.1.0. > > The X509_check_host() interface is also available in OpenSSL 1.0.2 > released a few days ago > > ????https://www.openssl.org/docs/crypto/X509_check_host.html > > (the documentation should be updated to note the earlier availability). > > Starting with 1.0.2, you can also ask OpenSSL to automatically > perform hostname checks during the SSL handshake on the application's > behalf: > > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html > ????https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html > ????https://www.openssl.org/docs/ssl/SSL_set_verify.html > > Sadly, we're still lacking documentation of SSL_get0_param() which > is needed for a complete SSL hostname check recipe: > > ????????const char *servername; > ????????SSL *ssl; > ????????X509_VERIFY_PARAM *param; > > ????????servername = "www.example.com"; > ????????ssl = SSL_new(...); > ????????param = SSL_get0_param(ssl); > > ????????/* Enable automatic hostname checks */ > ????????X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > ????????X509_VERIFY_PARAM_set1_host(param, servername, 0); > > ????????/* Configure a non-zero callback if desired */ > ????????SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); > > ????????/* > ?????????* Establish SSL connection, hostname should be checked > ?????????* automatically test with a hostname that should not match, > ?????????* the connection will fail (unless you specify a callback > ?????????* that returns despite the verification failure. ?In that > ?????????* case SSL_get_verify_status() can expose the problem after > ?????????* connection completion. > ?????????*/ > ?????????... >> ?I don't know does the first one support wildcards or no! Seems >> ?to be: how does Curl_cert_hostcheck work - is the answer, but I >> ?don't know how it works. > > Wildcard support is configured via the flags documented for X509_check_host(), > the two most frequently useful are: > > ????????X509_CHECK_FLAG_NO_WILDCARDS > ????????X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS > > -- > ????????Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From marquess at openssl.com Tue Jan 27 14:15:50 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 27 Jan 2015 09:15:50 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <20150126182141.0e668279@mevla> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> Message-ID: <54C79D96.3020602@openssl.com> On 01/26/2015 06:21 PM, jonetsu at teksavvy.com wrote: > On Fri, 16 Jan 2015 10:16:48 -0500 > Steve Marquess wrote: > >> On 01/15/2015 05:52 AM, Marcus Meissner wrote: > >>> On Linux usually triggered by /proc/sys/crypto/fips_enabled >>> containing "1" or the environment variable >>> OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and >>> Redhat, which do not use the container blob). > >> That is (presumably) true for the proprietary RH and SUSE distros, >> not so for the open source based OpenSSL FIPS Object Module or other >> Linux distros. > > I'm afraid it does not come across clear to me. So, maybe the > following pondering is relevant - or not. Basically, I'm looking at > how to integrate a FIPS-enabled OpenSSL that will be used by some > common Open Sources applications, as well as a 3rd party application > (with source code provided). Tom Francis nailed the answer to this one. We did design the FIPS module + "FIPS capable" OpenSSL combination to make it possible to have a system wide "FIPS mode" capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. > So, does your comment mean that the paying versions of Red > Hat and SuSE (proprietary) have open source applications modified to at > least include the FIPS_mode_set() call ? Why would these releases be > different in FIPS SSL 'power-up' POST checks when compared to regular > free releases ? That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. Note that such modifications are non-trivial for some applications, for instance OpenSSH. > If I compare with GnuTLS that our product also uses, and with which it > will also go to certification, its FIPS mode is completly transparent, > with FIPS checks done on library load. Can't help you there as I know nothing of GnuTLS. But, applications using GnuTLS will face exactly the same problem; if they were not designed or modified to operate in FIPS mode you're probably going to have undesirable outcomes. > Based on the discussion in 'The I.G. 9.5 Issue', I took a look at > 'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic > Module Validation Program', January 15 2015 release. In section 9.10 > it states:... Please read the first two sentences on that web page, right at the top. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jonetsu at teksavvy.com Tue Jan 27 16:09:25 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 27 Jan 2015 11:09:25 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <54C79D96.3020602@openssl.com> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <54C79D96.3020602@openssl.com> Message-ID: "Steve Marquess" wrote on 01/27/15 09:18: Thank you (and Tom) for your comments - much appreciated. > Tom Francis nailed the answer to this one. We did design the FIPS module > + "FIPS capable" OpenSSL combination to make it possible to have a > system wide "FIPS mode" capability, but that presumes that the system > maintainer (i.e. OS distribution maintainer) has done the review and > modification of each application that uses cryptography to make sure it > is compatible with the many restrictions of FIPS mode. Yes, I understand the concern.? Does this mean that the FIPS checks will be done today on OpenSSL library startup w/o the need for an application to use FIPS_mode_set() ?? I'm asking since the OpenSSL FIPS User Guide 2.0 only mentions using FIPS_mode_set() (and FIPS_selftest()).? Might have to do with your comment below. ? > That is indeed the assumption: that commercial versions of RH and SuSE > have modified all impacted OSS applications to operate in FIPS mode. If > they haven't they are deceiving their customers and the U.S. government. I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago, though. ? > Please read the first two sentences on that web page, right at the top. OK!? Regarding the second sentence :) ... what is the current status ?? Is OpenSSL transparently executing FIPS checks when in FIPS mode ?? And, why would there be any validation (as opposed to functional tests) to be done since these checks are the same as they were before I presume, just done automatically this time around. Regards. From openssl-users at dukhovni.org Tue Jan 27 17:21:19 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Jan 2015 17:21:19 +0000 Subject: [openssl-users] Hostname validation In-Reply-To: <2157801422364729@web28o.yandex.ru> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> <2157801422364729@web28o.yandex.ru> Message-ID: <20150127172119.GQ8034@mournblade.imrryr.org> On Tue, Jan 27, 2015 at 04:18:49PM +0300, Serj wrote: > I didn't find docs on such functions as SSL_get0_param As I mentioned, this function should be documented, but is not yet. > Why there is no corresponding functions as SSL_set0_param in your code? > Where can I found documentation on functions operating with params? The documentation for these functions is not yet written. The way I would set SSL verification parameters is to obtain the parameter handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(), and use the various X509_VERIFY_PARAM_mumble() functions to tweak the parameter object in place. Parameters that apply to all connections should be set at the SSL_CTX level, when the context is created. Specifics like hostnames, ... should be set for each connection via the SSL object. > But there is no any description how SSL_CTX_set1_param works! > Does it clear all previous flags on CTX or "ORing" with them? > And there are no any docs on "GET" params functions! Yes, these need (more) documentation. -- Viktor. From marquess at openssl.com Tue Jan 27 19:13:57 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 27 Jan 2015 14:13:57 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <54C79D96.3020602@openssl.com> Message-ID: <54C7E375.3070202@openssl.com> On 01/27/2015 11:09 AM, jonetsu wrote: > "Steve Marquess" wrote on 01/27/15 09:18: Thank > you (and Tom) for your comments - much appreciated. > >> Tom Francis nailed the answer to this one. We did design the FIPS >> module + "FIPS capable" OpenSSL combination to make it possible to >> have a system wide "FIPS mode" capability, but that presumes that >> the system maintainer (i.e. OS distribution maintainer) has done >> the review and modification of each application that uses >> cryptography to make sure it is compatible with the many >> restrictions of FIPS mode. > > Yes, I understand the concern. Does this mean that the FIPS checks > will be done today on OpenSSL library startup w/o the need for an > application to use FIPS_mode_set() ? I'm asking since the OpenSSL > FIPS User Guide 2.0 only mentions using FIPS_mode_set() (and > FIPS_selftest()). Might have to do with your comment below. The user guide documents that correctly. For the OpenSSL FIPS Object Module 2.0 (#1747) the FIPS mode of operation is enabled with FIPS_mode_set(). There is no "library startup"; you keep confusing past validations with new ones. Note that we would update that existing module to comply with the new I.G. 9.10 guidance, but that falls in the class of changes that are not permitted under the "change letter" update process (similarly, we weren't allowed to update the module to address security vulnerabilities such as "Lucky 13"). >> That is indeed the assumption: that commercial versions of RH and >> SuSE have modified all impacted OSS applications to operate in FIPS >> mode. If they haven't they are deceiving their customers and the >> U.S. government. > > I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago, > though. > >> Please read the first two sentences on that web page, right at the >> top. > > OK! Regarding the second sentence :) ... what is the current status > ? We have not done any validations that satisfy the various new requirements introduced in late 2013 and early 2014. New validations are very expensive, in dollars, time, and grief, and we don't have the necessary financial backing. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rasjv at yandex.com Tue Jan 27 19:09:38 2015 From: rasjv at yandex.com (Serj) Date: Tue, 27 Jan 2015 22:09:38 +0300 Subject: [openssl-users] Hostname validation In-Reply-To: <20150127172119.GQ8034@mournblade.imrryr.org> References: <7219711422204194@web29h.yandex.ru> <20150125175706.GN8034@mournblade.imrryr.org> <2157801422364729@web28o.yandex.ru> <20150127172119.GQ8034@mournblade.imrryr.org> Message-ID: <623441422385778@web1g.yandex.ru> Hi, Viktor. 27.01.2015, 20:23, "Viktor Dukhovni" : > I would set SSL verification parameters is to obtain the parameter > handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(), > and use the various X509_VERIFY_PARAM_mumble() functions to tweak > the parameter object in place. Why are not there any X509_VERIFY_PARAM_mumble() functions in your code? So your code is not complete? And if so why it was already added to wiki here: http://wiki.openssl.org/index.php/Hostname_validation > As I mentioned, this function should be documented, but is not yet. > The documentation for these functions is not yet written. ?The way > Yes, these need (more) documentation. That's why maybe it is better to use X509_check_host() in "post conection checks" now? It's strangely, why I read in documentaion: ---------------------------------------------------------------------------------- Applications are strongly advised to use this interface in preference to explicitly calling X509_check_host(3), hostname checks are out of scope with the DANE-EE(3) certificate usage, and the internal check will be suppressed as appropriate when DANE support is added to OpenSSL. and no any documentation on how to set properly params for SSL or CTX! NOTES Applications are encouraged to use X509_VERIFY_PARAM_set1_host() rather than explicitly calling X509_check_host(3). Host name checks are out of scope with the DANE-EE(3) certificate usage, and the internal checks will be suppressed as appropriate when DANE support is added to OpenSSL. ---------------------------------------------------------------------------------- and no any documentation on how to set properly params for SSL or CTX! Maybe this code is right, while there is no full documentation yet: char servername[]="www.openssl.org\x0"; X509_VERIFY_PARAM *param; param = X509_VERIFY_PARAM_new(); //enable automatic hostname checks X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername,0); SSL_CTX_set1_param(ctx, param); //is right if combined by a bitwise 'OR' operation //free param X509_VERIFY_PARAM_free(param); -- Best Regards, Serj From rasjv at yandex.com Tue Jan 27 19:21:01 2015 From: rasjv at yandex.com (Serj) Date: Tue, 27 Jan 2015 22:21:01 +0300 Subject: [openssl-users] Intermediate certificates Message-ID: <648661422386461@web1g.yandex.ru> Hello. Some web-sites don't send all intermediate certs during "SSL Handshake". For example, www.verisign.com sends only server's cert but doesn't send next intermediate cert: s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 So, I need to set a list of intermediate certs for my SSL connections. How to do this? With SSL_CTX_load_verify_locations() I can set only trusted root certs, but not intermediate certs. -- Best Regards, Serj From rsalz at akamai.com Tue Jan 27 19:48:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jan 2015 19:48:06 +0000 Subject: [openssl-users] TSLEXT_TYPE_opaque_prf_input Message-ID: <12fb575d38d74fd5ae5ef191f7b4c1d7@ustx2ex-dag1mb2.msg.corp.akamai.com> This is an implementation of an IETF draft that expired seven years ago. Is anyone using it? -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 27 20:03:45 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Jan 2015 20:03:45 +0000 Subject: [openssl-users] Hostname validation In-Reply-To: <20150125175706.GN8034@mournblade.imrryr.org> <623441422385778@web1g.yandex.ru> Message-ID: <20150127200345.GX8034@mournblade.imrryr.org> On Tue, Jan 27, 2015 at 10:09:38PM +0300, Serj wrote: > 27.01.2015, 20:23, "Viktor Dukhovni" : > > I would set SSL verification parameters is to obtain the parameter > > handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(), > > and use the various X509_VERIFY_PARAM_mumble() functions to tweak > > the parameter object in place. > > Why are not there any X509_VERIFY_PARAM_mumble() functions in your code? > So your code is not complete? It is complete enough. The word "mumble" is not meant to be taken literally. The phrase: "various X509_VERIFY_PARAM_mumble() functions" means any of: X509_VERIFY_PARAM_set_hostflags() X509_VERIFY_PARAM_set1_host() ... > > As I mentioned, this function should be documented, but is not yet. > > The documentation for these functions is not yet written. ?The way > > Yes, these need (more) documentation. > > That's why maybe it is better to use X509_check_host() in "post conection checks" now? No, it is better to use the parameter functions, and also to document the missing SSL_get0_param(). > NOTES > Applications are encouraged to use X509_VERIFY_PARAM_set1_host() > rather than explicitly calling X509_check_host(3). Host name checks > are out of scope with the DANE-EE(3) certificate usage, and the > internal checks will be suppressed as appropriate when DANE support > is added to OpenSSL. > ---------------------------------------------------------------------------------- > and no any documentation on how to set properly params for SSL or CTX! Example code should likely be added to that document. > Maybe this code is right, while there is no full documentation yet: > > char servername[]="www.openssl.org\x0"; > X509_VERIFY_PARAM *param; > param = X509_VERIFY_PARAM_new(); > > //enable automatic hostname checks > X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > X509_VERIFY_PARAM_set1_host(param, servername,0); > SSL_CTX_set1_param(ctx, param); //is right if combined by a bitwise 'OR' operation > > //free param > X509_VERIFY_PARAM_free(param); No, use the code example I provided. The above sets the hostname in the global context, where it does not belong. My original message is below: On Sun, Jan 25, 2015 at 05:57:06PM +0000, Viktor Dukhovni wrote: > On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: > > > What is the best way to make hostname validation? > > > > 1. http://wiki.openssl.org/index.php/Hostname_validation > > 2. X509_check_host that was added in OpenSSL 1.1.0. > > The X509_check_host() interface is also available in OpenSSL 1.0.2 > released a few days ago > > https://www.openssl.org/docs/crypto/X509_check_host.html > > (the documentation should be updated to note the earlier availability). > > Starting with 1.0.2, you can also ask OpenSSL to automatically > perform hostname checks during the SSL handshake on the application's > behalf: > > https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html > https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html > https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html > https://www.openssl.org/docs/ssl/SSL_set_verify.html > > Sadly, we're still lacking documentation of SSL_get0_param() which > is needed for a complete SSL hostname check recipe: > > const char *servername; > SSL *ssl; > X509_VERIFY_PARAM *param; > > servername = "www.example.com"; > ssl = SSL_new(...); > param = SSL_get0_param(ssl); > > /* Enable automatic hostname checks */ > X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > X509_VERIFY_PARAM_set1_host(param, servername, 0); > > /* Configure a non-zero callback if desired */ > SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); > > /* > * Establish SSL connection, hostname should be checked > * automatically test with a hostname that should not match, > * the connection will fail (unless you specify a callback > * that returns despite the verification failure. In that > * case SSL_get_verify_status() can expose the problem after > * connection completion. > */ > ... > > > I don't know does the first one support wildcards or no! Seems > > to be: how does Curl_cert_hostcheck work - is the answer, but I > > don't know how it works. > > Wildcard support is configured via the flags documented for X509_check_host(), > the two most frequently useful are: > > X509_CHECK_FLAG_NO_WILDCARDS > X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS -- Viktor. From openssl-users at dukhovni.org Tue Jan 27 20:12:53 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Jan 2015 20:12:53 +0000 Subject: [openssl-users] Intermediate certificates In-Reply-To: <648661422386461@web1g.yandex.ru> References: <648661422386461@web1g.yandex.ru> Message-ID: <20150127201253.GY8034@mournblade.imrryr.org> On Tue, Jan 27, 2015 at 10:21:01PM +0300, Serj wrote: > Some web-sites don't send all intermediate certs during "SSL Handshake". Indeed some websites are misconfigured. > For example, www.verisign.com sends only server's cert but doesn't send next intermediate cert: But www.verisign.com is not among them: $ sleep 2 | openssl s_client -showcerts -connect www.verisign.com:443 2>&1 | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=350 Ellis Street/O=Symantec Corporation/OU=Infrastructure Operations /CN=www.verisign.com issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 issuer=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority > So, I need to set a list of intermediate certs for my SSL connections. How to do this? > > With SSL_CTX_load_verify_locations() I can set only trusted root certs, but not intermediate certs. This is not needed for properly configured servers, such as www.verisign.com. While providing additional "untrusted" (intermediate) certificates is possible, it is complex and the right solution is for the broken sites to fix their certificate chain configuration. It is unfortunate that browsers "lend a helping hand" to such sites. -- Viktor. From rasjv at yandex.com Tue Jan 27 20:21:03 2015 From: rasjv at yandex.com (Serj) Date: Tue, 27 Jan 2015 23:21:03 +0300 Subject: [openssl-users] Hostname validation In-Reply-To: <20150127200345.GX8034@mournblade.imrryr.org> References: <20150125175706.GN8034@mournblade.imrryr.org> <623441422385778@web1g.yandex.ru> <20150127200345.GX8034@mournblade.imrryr.org> Message-ID: <787091422390063@web21m.yandex.ru> Hi, Viktor. 27.01.2015, 23:07, "Viktor Dukhovni" : > It is complete enough. ?The word "mumble" is not meant to be taken You full code from wiki is: const char *servername; SSL *ssl; X509_VERIFY_PARAM *param; servername = "www.example.com"; ssl = SSL_new(...); param = SSL_get0_param(ssl); /* Enable automatic hostname checks */ X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); /* Configure a non-zero callback if desired */ SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); /* * Establish SSL connection, hostname should be checked * automatically test with a hostname that should not match, * the connection will fail (unless you specify a callback * that returns despite the verification failure. In that * case SSL_get_verify_status() can expose the problem after * connection completion. */ ... You set here only "param": X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); But how this variable is associated with "ssl" object or "ctx" object? I don't understand really! Please explain more in detail. I know this function only SSL_CTX_set1_param() that associates "param" with context "ctx". -- Best Regards, Serj From rasjv at yandex.com Tue Jan 27 20:42:51 2015 From: rasjv at yandex.com (Serj) Date: Tue, 27 Jan 2015 23:42:51 +0300 Subject: [openssl-users] Intermediate certificates In-Reply-To: <20150127201253.GY8034@mournblade.imrryr.org> References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> Message-ID: <825281422391371@web21m.yandex.ru> 27.01.2015, 23:15, "Viktor Dukhovni" : > Indeed some websites are misconfigured. > But www.verisign.com is not among them: > This is not needed for properly configured servers, such as > www.verisign.com. Ok. Seems to be I don't set the last root for www.verisign.com in my trusted root certs and only that's why I got a error: Verify return code: 20 (unable to get local issuer certificate) > While providing additional "untrusted" (intermediate) certificates > is possible, it is complex and the right solution is for the broken > sites to fix their certificate chain configuration. Ok. But is there any documentation how to set intermediate certificates for my SSL connections? Maybe I want to support these broken sites... > It is unfortunate that browsers "lend a helping hand" to such sites. So, you want to say that browsers trust connections that don't provide intermediate certs during SSL handhake? As I know most browsers have also intermediate certs in their stores as builtin objects and also as received during handshakes. That's why any documentation how to set intermediate certificates for my SSL connections will be very needed. Thank you for answers, Viktor, once again. And I looking forward to your reply... -- Best Regards, Serj From steve at openssl.org Tue Jan 27 21:02:41 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 27 Jan 2015 21:02:41 +0000 Subject: [openssl-users] Hostname validation In-Reply-To: <787091422390063@web21m.yandex.ru> References: <20150125175706.GN8034@mournblade.imrryr.org> <623441422385778@web1g.yandex.ru> <20150127200345.GX8034@mournblade.imrryr.org> <787091422390063@web21m.yandex.ru> Message-ID: <20150127210241.GA27774@openssl.org> On Tue, Jan 27, 2015, Serj wrote: > Hi, Viktor. > > 27.01.2015, 23:07, "Viktor Dukhovni" : > > It is complete enough. ?The word "mumble" is not meant to be taken > > You full code from wiki is: > > const char *servername; > SSL *ssl; > X509_VERIFY_PARAM *param; > > servername = "www.example.com"; > ssl = SSL_new(...); > param = SSL_get0_param(ssl); > > /* Enable automatic hostname checks */ > X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > X509_VERIFY_PARAM_set1_host(param, servername, 0); > > /* Configure a non-zero callback if desired */ > SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); > > /* > * Establish SSL connection, hostname should be checked > * automatically test with a hostname that should not match, > * the connection will fail (unless you specify a callback > * that returns despite the verification failure. In that > * case SSL_get_verify_status() can expose the problem after > * connection completion. > */ > ... > > You set here only "param": > X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); > X509_VERIFY_PARAM_set1_host(param, servername, 0); > > But how this variable is associated with "ssl" object or "ctx" object? > I don't understand really! Please explain more in detail. > It's this: param = SSL_get0_param(ssl); Because SSL_get0_param retrieves the internal pointer to parameters used by ssl: so if you modify those parameters the modified versions will be used by ssl. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rasjv at yandex.com Tue Jan 27 21:08:03 2015 From: rasjv at yandex.com (Serj) Date: Wed, 28 Jan 2015 00:08:03 +0300 Subject: [openssl-users] Hostname validation In-Reply-To: <20150127210241.GA27774@openssl.org> References: <20150125175706.GN8034@mournblade.imrryr.org> <623441422385778@web1g.yandex.ru> <20150127200345.GX8034@mournblade.imrryr.org> <787091422390063@web21m.yandex.ru> <20150127210241.GA27774@openssl.org> Message-ID: <754251422392883@web13o.yandex.ru> 28.01.2015, 00:04, "Dr. Stephen Henson" : > It's this: > > ???????param = SSL_get0_param(ssl); > > Because SSL_get0_param retrieves the internal pointer to parameters used by > ssl: so if you modify those parameters the modified versions will be used by > ssl. Thanks, Stephen. Now it's clear. -- Best Regards, Serj From kurt at roeckx.be Tue Jan 27 22:14:20 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 27 Jan 2015 23:14:20 +0100 Subject: [openssl-users] Intermediate certificates In-Reply-To: <825281422391371@web21m.yandex.ru> References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> <825281422391371@web21m.yandex.ru> Message-ID: <20150127221419.GA11102@roeckx.be> On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote: > > > It is unfortunate that browsers "lend a helping hand" to such sites. > So, you want to say that browsers trust connections that don't provide intermediate certs during SSL handhake? > As I know most browsers have also intermediate certs in their stores as builtin objects and also as received during handshakes. > That's why any documentation how to set intermediate certificates for my SSL connections will be very needed. What browsers do is cache the intermediate certificates. If a sites fails to send them, the browser can still find it in it's cache and use those cached intermediate certificates to do the validation. If the missing intermediate certificate is not cached the site will not work in the browser. But if you then visit a site that has the same intermediate certificate that does send it, and then go back to the broken site it will suddenly work. Browsers have too many work arounds for broken sites which results in those sites not actually getting fixed. Kurt From rsalz at akamai.com Tue Jan 27 22:33:43 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jan 2015 22:33:43 +0000 Subject: [openssl-users] Intermediate certificates In-Reply-To: <20150127221419.GA11102@roeckx.be> References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> <825281422391371@web21m.yandex.ru> <20150127221419.GA11102@roeckx.be> Message-ID: <9bd3b3075dd84a00aeef9e70d2a789bf@ustx2ex-dag1mb2.msg.corp.akamai.com> > Browsers have too many work arounds for broken sites which results in > those sites not actually getting fixed. Because if the site doesn't work, the user will blame the browser and switch. :( From dthompson at prinpay.com Wed Jan 28 07:49:34 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Wed, 28 Jan 2015 02:49:34 -0500 Subject: [openssl-users] Intermediate certificates In-Reply-To: <20150127221419.GA11102@roeckx.be> References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> <825281422391371@web21m.yandex.ru> <20150127221419.GA11102@roeckx.be> Message-ID: <005801d03ace$f92db2a0$eb8917e0$@prinpay.com> > From: openssl-users On Behalf Of Kurt Roeckx > Sent: Tuesday, January 27, 2015 17:14 > On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote: > What browsers do is cache the intermediate certificates. That's one possibility. Another is that it uses AuthorityInfoAccess to fetch the cert automatically, which OpenSSL currently does not (unless you figure out a custom X509_LOOKUP to do so). From jonetsu at teksavvy.com Wed Jan 28 13:31:20 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Wed, 28 Jan 2015 08:31:20 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <54C7E375.3070202@openssl.com> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <54C79D96.3020602@openssl.com> <54C7E375.3070202@openssl.com> Message-ID: <20150128083120.197b0dfb@mevla> On Tue, 27 Jan 2015 14:13:57 -0500 Steve Marquess wrote: > The user guide documents that correctly. For the OpenSSL FIPS Object > Module 2.0 (#1747) the FIPS mode of operation is enabled with > FIPS_mode_set(). There is no "library startup"; you keep confusing > past validations with new ones. OK. > Note that we would update that existing module to comply with the new > I.G. 9.10 guidance, but that falls in the class of changes that are > not permitted under the "change letter" update process (similarly, we > weren't allowed to update the module to address security > vulnerabilities such as "Lucky 13"). Yes, FIPS is what it is. I'm short of describing words now, and I prefer not to search too long :-) > We have not done any validations that satisfy the various new > requirements introduced in late 2013 and early 2014. New validations > are very expensive, in dollars, time, and grief, and we don't have the > necessary financial backing. Something I don't understand. Does validation prevent any software development ? Eg. why not develop a newer version that is not validated (until further notice) but will include for instance the automatic library load that would perform transparently all the FIPS checks ? In our case, our system as a whole will be validated. And that includes OpenSSL, as well as anything else that's relevant to FIPS, including stickers on the units. OpenSSL will be validated anyways. We are looking at adding the automatic load hence the running of FIPS tests at library load time. But then, this might change depending on the assessment of other FIPS-aware modifications to popular Open Source packages. Otherwise, if they (most) have already FIPS mode options, then we would add the automatic hooks to OpenSSL. And the unit will be sent to the consultants who will run their SSL tests and others, and then to the NIST labs, as such. Regards. From jonetsu at teksavvy.com Wed Jan 28 13:33:51 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Wed, 28 Jan 2015 08:33:51 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <90213D48-C5A8-407D-BF02-945CA191EE58@pobox.com> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <90213D48-C5A8-407D-BF02-945CA191EE58@pobox.com> Message-ID: <20150128083351.214decec@mevla> On Mon, 26 Jan 2015 22:35:12 -0500 Tom Francis wrote: > This is a bad idea. It can generally be done, and it?s probably not > even too hard (for some uses, anyway). But it?s a bad idea. Here?s > why: Thanks for the detailed comments. I understand the concerns, although there's one thing I do not see clearly, that is: > 2) Applications that don?t know they?re operating in FIPS > mode may attempt to use algorithms that are disallowed in FIPS mode, > but using an API that will actually succeed. How could this happen ? Do you have a practical use case ? Wouldn't OpenSSL in FIPS mode prevent the use of such algorithm in the first place ? Regards. From steve at openssl.org Wed Jan 28 13:47:03 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 28 Jan 2015 13:47:03 +0000 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <20150128083351.214decec@mevla> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <90213D48-C5A8-407D-BF02-945CA191EE58@pobox.com> <20150128083351.214decec@mevla> Message-ID: <20150128134703.GA18160@openssl.org> On Wed, Jan 28, 2015, jonetsu at teksavvy.com wrote: > On Mon, 26 Jan 2015 22:35:12 -0500 > Tom Francis wrote: > > Thanks for the detailed comments. I understand the concerns, although > there's one thing I do not see clearly, that is: > > > 2) Applications that don???t know they???re operating in FIPS > > mode may attempt to use algorithms that are disallowed in FIPS mode, > > but using an API that will actually succeed. > > How could this happen ? Do you have a practical use case ? Wouldn't > OpenSSL in FIPS mode prevent the use of such algorithm in the first > place ? > OpenSSL does prevent the use of non-FIPS algorithms in FIPS mode but applications don't always cleanly handle it. If the application uses TLS then it should be OK as non-FIPS ciphersuites are automatically blocked. A possible gotcha is use of private keys encrypted using the old MD5 PBE algorithm. If the application uses algorithms directly via for example EVP_DigestInit_ex() then things are different. A non-FIPS application might never see an error from EVP_DigestInit_ex() and not handle it properly (e.g. ignoring the return value). This will cause a hard failure later on. Even if an application does check return values it might regard an error return from EVP_DigestInit_ex() as a fatal error (it sometimes is: e.g. memory allocation failure): it is unlikely to retry with a different algorithm. The correct thing to do is never attempt to use the non-FIPS algorithm in the first place. What that measn in practice is that while some applications will "just work" when FIPS mode is enabled, others need to be modified to correctly handle FIPS. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From marquess at openssl.com Wed Jan 28 14:43:21 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 28 Jan 2015 09:43:21 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <20150128083120.197b0dfb@mevla> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <54C79D96.3020602@openssl.com> <54C7E375.3070202@openssl.com> <20150128083120.197b0dfb@mevla> Message-ID: <54C8F589.5010703@openssl.com> On 01/28/2015 08:31 AM, jonetsu at teksavvy.com wrote: > ... > >> We have not done any validations that satisfy the various new >> requirements introduced in late 2013 and early 2014. New validations >> are very expensive, in dollars, time, and grief, and we don't have the >> necessary financial backing. > > Something I don't understand. Does validation prevent any software > development ? Eg. why not develop a newer version that is not > validated (until further notice) but will include for instance the > automatic library load that would perform transparently all the FIPS > checks ? > > ... Why should we? Frankly the FIPS 140-2 stuff is of interest to only a small portion of the overall OpenSSL user base: basically just those commercial vendors who sell to the U.S. government market. The FIPS validated software itself is necessarily inferior to the stock OpenSSL by any "real world" metric (security, performance, maintainability and usability), and so has no value for the rest of the world or the private sector in the U.S. The fully validated module (OpenSSL FIPS Object Module) is at least of use to all those commercial vendors selling to the USG and DoD; speculative code that would make it easier for vendors like you to pursue private proprietary validations would be of interest to a far smaller subset. We have enough demands on our limited resources as it is to expend them on such a limited constituency. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From thomas.francis.jr at pobox.com Wed Jan 28 15:18:47 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Wed, 28 Jan 2015 10:18:47 -0500 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: <20150128134703.GA18160@openssl.org> References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <90213D48-C5A8-407D-BF02-945CA191EE58@pobox.com> <20150128083351.214decec@mevla> <20150128134703.GA18160@openssl.org> Message-ID: > On Jan 28, 2015, at 8:47 AM, Dr. Stephen Henson wrote: > > On Wed, Jan 28, 2015, jonetsu at teksavvy.com wrote: > >> On Mon, 26 Jan 2015 22:35:12 -0500 >> Tom Francis wrote: >> >> Thanks for the detailed comments. I understand the concerns, although >> there's one thing I do not see clearly, that is: >> >>> 2) Applications that don???t know they???re operating in FIPS >>> mode may attempt to use algorithms that are disallowed in FIPS mode, >>> but using an API that will actually succeed. >> >> How could this happen ? Do you have a practical use case ? Wouldn't >> OpenSSL in FIPS mode prevent the use of such algorithm in the first >> place ? >> > > OpenSSL does prevent the use of non-FIPS algorithms in FIPS mode but > applications don't always cleanly handle it. > > If the application uses TLS then it should be OK as non-FIPS ciphersuites > are automatically blocked. A possible gotcha is use of private keys encrypted > using the old MD5 PBE algorithm. > > If the application uses algorithms directly via for example EVP_DigestInit_ex() > then things are different. A non-FIPS application might never see an error > from EVP_DigestInit_ex() and not handle it properly (e.g. ignoring the > return value). This will cause a hard failure later on. > > Even if an application does check return values it might regard an error > return from EVP_DigestInit_ex() as a fatal error (it sometimes is: e.g. memory > allocation failure): it is unlikely to retry with a different algorithm. > > The correct thing to do is never attempt to use the non-FIPS algorithm in > the first place. What that measn in practice is that while some applications > will "just work" when FIPS mode is enabled, others need to be modified to > correctly handle FIPS. Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where OpenSSL would prevent disallowed algorithms from being used, but only if you used the EVP interfaces. You could, for example, invoke MD5 directly. Did that change with 2.x? (it?s not something I paid much attention to, as I always used EVP, anyway). It?s also my understanding that the private APIs could still be used to bypass the FIPS mode algorithm checks, and that some applications may be using those. TOM > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From steve at openssl.org Wed Jan 28 15:31:58 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 28 Jan 2015 15:31:58 +0000 Subject: [openssl-users] Using FIPS mode and modifying apps In-Reply-To: References: <54B7C084.1060404@openssl.com> <54B92B60.1020206@openssl.com> <20150126182141.0e668279@mevla> <90213D48-C5A8-407D-BF02-945CA191EE58@pobox.com> <20150128083351.214decec@mevla> <20150128134703.GA18160@openssl.org> Message-ID: <20150128153158.GA8568@openssl.org> On Wed, Jan 28, 2015, Tom Francis wrote: > > Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where > OpenSSL would prevent disallowed algorithms from being used, but only if you > used the EVP interfaces. You could, for example, invoke MD5 directly. Did > that change with 2.x? (it???s not something I paid much attention to, as I > always used EVP, anyway). It???s also my understanding that the private APIs > could still be used to bypass the FIPS mode algorithm checks, and that some > applications may be using those. > With 2.0 the low level calls are blocked in FIPS mode and you have to use EVP. The blocking in OpenSSL is designed to block *accidental* calls to unapproved algorithms in FIPS mode. An application can decide to bypass those checks if it wants to (for example some usages of unapproved algorithms are considered acceptable in FIPS mode) with appropriate calls. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From oyljerry at gmail.com Thu Jan 29 08:28:31 2015 From: oyljerry at gmail.com (Jerry OELoo) Date: Thu, 29 Jan 2015 16:28:31 +0800 Subject: [openssl-users] Intermediate certificates In-Reply-To: <005801d03ace$f92db2a0$eb8917e0$@prinpay.com> References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> <825281422391371@web21m.yandex.ru> <20150127221419.GA11102@roeckx.be> <005801d03ace$f92db2a0$eb8917e0$@prinpay.com> Message-ID: As I heard, OpenSSL 1.0.2 will do some improvement for AuthorityInfoAccess, Am I right? Thanks! On Wed, Jan 28, 2015 at 3:49 PM, Dave Thompson wrote: >> From: openssl-users On Behalf Of Kurt Roeckx >> Sent: Tuesday, January 27, 2015 17:14 > >> On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote: > >> What browsers do is cache the intermediate certificates. > > That's one possibility. Another is that it uses AuthorityInfoAccess > to fetch the cert automatically, which OpenSSL currently does not > (unless you figure out a custom X509_LOOKUP to do so). > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Rejoice,I Desire! From dave.mclellan at emc.com Thu Jan 29 15:09:30 2015 From: dave.mclellan at emc.com (mclellan, dave) Date: Thu, 29 Jan 2015 10:09:30 -0500 Subject: [openssl-users] IPv6 and OpenSSL at the BIO level -- should it work? Message-ID: <56A41A14DF41784FA3CA37EF5760F2751F07C4C30F@MX30A.corp.emc.com> I have a colleague who is using OpenSSL 1.0.1j and BIOs to connect to servers. Given the requirement that his software must now connect to IPv6 addresses, still using the BIO interface, is it supposed to work? That is, can a BIO caller pass a string hostname:port like this "[2620:0:170:28a1::1003]:443" to BIO and have it work? I see a reference to Patch #1365 which deals with openssl s_client and doing left-side truncation of an IPv6 address specified in the -connect option. The discussion of this patch is http://rt.openssl.org/Ticket/Display.html?id=1365&user=guest&pass=guest but it looks like it's a patch for the application, not the BIO. In fact in the plain build of 1.0.1j I have with OPENSSL_USE_IPV6 specified, still has this left-side truncation issue (I see code in crypto/apps/s_socket.c:extract_host_port() which simply looks for a colon and takes what's on the right side for the port, assuming the left side is a dotted decimal IPv4 address. I have already suggested to this colleague that the issue with IPv6 is name and address resolution, not socket I/O. If he handles the name resolution himself, creates a socket with the right address family and sockaddr format, and then uses the right BIO calls, it should work. We do our own name/address handling and don't use BIO in my application so I have never studied how to do it there. Thanks for your advice Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclellan at emc.com +-+-+-+-+-+-+-+-+- -------------- next part -------------- An HTML attachment was scrubbed... URL: From srirrao at gmail.com Thu Jan 29 15:21:28 2015 From: srirrao at gmail.com (Srinivas Rao) Date: Thu, 29 Jan 2015 20:51:28 +0530 Subject: [openssl-users] PKCS7_add_signature dumps core (windows) Message-ID: OpenSSL experts, Here the intention is to get the signed data (raw signature obtained by PKCS11 APIs like C_Sign) to be packed in PKCS7 format (attached - with certificate, content and signer info) using openssl. I am using USB token (smart card) for signing. Here's the code snippet. PKCS7* p7 = PKCS7_new(); PKCS7_set_type(p7, NID_pkcs7_signed); //PKCS7_SIGNER_INFO* pSI = PKCS7_SIGNER_INFO_new(); //PKCS7_SIGNER_INFO_set(pSI, pX509, pX509->cert_info->key->pkey, EVP_sha256()); //PKCS7_add_signer(p7, pSI); PKCS7_SIGNER_INFO* pSI = PKCS7_add_signature(p7, pX509, pX509->cert_info->key->pkey, EVP_sha256()); // <== core dumps here : : where pX509 is correctly obtained X509* node using d2i_X509() from the value obtained from PKCS11 funcstions like C_GetAttributeValue() etc. I believe the set of the commented lines is the alternate way for this add signature function - that also dumps core at PKCS7_SIGNER_INFO_set() function. I have no clue as to what am I doing wrong here. Appreciate your help. regards Srinivas From antonios.tsakiridis at unify.com Thu Jan 29 16:09:22 2015 From: antonios.tsakiridis at unify.com (Tsakiridis, Antonios) Date: Thu, 29 Jan 2015 16:09:22 +0000 Subject: [openssl-users] Cannot clear error OpenSSL Error Stack Message-ID: <919457A00FC7C141AE43AD46947F85411E0BF372@MCHP04MSX.global-ad.net> Hello, After getting an error in the verify callback of my server saying that the presented client certificate is expired, I cannot clear the openssl error stack. The reason I want to do that is because I want to be able to override (under specific circumstances) the default OpenSSL behavior that rejects a connection from a client who presents an expired certificate. The way I have tried to do that is to return 1 from the verification callback when openssl passes 'ok' argument as 0 (i.e. failed verification). I would expect that returning 1 signifies success and hence the error stack is cleared, however I found out that calling SSL_get_verify_result() after the verification callback still returns an error. Why is that? Please note that I'm using openssl 0.9.8 Thanks a lot in advance, Antonis -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at vpnadmin.com.ua Thu Jan 29 16:17:49 2015 From: lists at vpnadmin.com.ua (Lists@vpnadmin) Date: Thu, 29 Jan 2015 18:17:49 +0200 Subject: [openssl-users] openssl s_server stops on some client connections Message-ID: <54CA5D2D.6030904@vpnadmin.com.ua> Hello all! Please help me to understand, what is the problem with openssl s_server. It stops after some connections: LAN clients connect well, but most of WAN ones kill the s_server (not only SSL/TLS clients, but telnet to same port too). Same versions OS and openssl on different servers (different providers) work well or don't work. The problem is found for openssl "1.0.1e-2+deb7u14" on Debian Wheezy and for openssl "1.0.1f 6 Jan 2014" on Ubuntu 12.04. The task is to create TLS connection to SIP provider with asterisk. Outgoing TLS-connection to provider have been established. Problem is appearing when provider attempts to connect to my host: asterisk is working, but TLS connections are refused: $ openssl s_client -connect 1.2.3.4:5061 connect: Connection refused connect:errno=111 So, port is open on the server, but there is no a service, which listen on this port. Let try to emmulate the SSL/TLS server with the script: # openssl s_server -tls1 -accept 443 -cert /etc/ssl/certs/ssl-cert-snakeoil.pem -key /etc/ssl/private/ssl-cert-snakeoil.key -www Using default temp DH parameters Using default temp ECDH parameters ACCEPT < ... server is waiting for connections ...> Let attempt to connect to this server again: $ openssl s_client -connect 1.2.3.4:443 CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 308 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- $ On the server side: ... gethostbyname failure 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 0 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 0 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows # <... here s_server stops ...> Let restart s_server and try to connect with browser: "https://1.2.3.4/" or with Telnet: "telnet 1.2.3.4 443" - result is same. I think, this is the time to tell about versions: # uname -a Linux server 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux # openssl version OpenSSL 1.0.1e 11 Feb 2013 # dpkg-query -l | grep openssl ii openssl 1.0.1e-2+deb7u14 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools Firewall is open for all outgoing connections and for incoming connections to "s_client" hosts. All servers have direct ethernet connection to providers without NATs, PPPs. Let try to connect from LAN to same server: connection is established. Let try to use "TLS Dump" service from http://paranoidsecurity.nl/ : connection is established. Also I see successful connections from Google and other bots. Let try to create s_server on another server with another provider and the same OS version: connection is established. Let try to create one more s_server on the one more host (the third provider, Ubuntu): there is the same error - "openssl s_server" stops. About this host: # uname -a Linux serv 3.2.0-43-generic-pae #68-Ubuntu SMP Wed May 15 03:55:10 UTC 2013 i686 i686 i686 GNU/Linux # openssl version OpenSSL 1.0.1f 6 Jan 2014 I think, there are external conditions when openssl s_server sometimes stops on connections to it. If it is so, then there is a Denial-of-Service vulnerability into openssl ! Some more information we can get by ssldump-ing working connection with comparison to non-working: *Working connection:** * # ssldump -A -e -H -T port 5069 TCP: srv-2.local(5069) -> srv-1.local(37926) Seq 471176930.(0) ACK 1183615929 FIN TCP: srv-1.local(37926) -> srv-2.local(5069) Seq 1183615929.(29) ACK 471176931 PUSH TCP: srv-2.local(5069) -> srv-1.local(37926) Seq 471176931.(0) RST TCP: srv-1.local(37926) -> srv-2.local(5069) Seq 1183615958.(0) ACK 471176931 FIN TCP: srv-2.local(5069) -> srv-1.local(37926) Seq 471176931.(0) RST TCP: srv-1.local(37927) -> srv-2.local(5069) Seq 2566830925.(0) SYN TCP: srv-2.local(5069) -> srv-1.local(37927) Seq 3381252077.(0) ACK 2566830926 SYN TCP: srv-1.local(37927) -> srv-2.local(5069) Seq 2566830926.(0) ACK 3381252078 New TCP connection #1: srv-1.local(37927) <-> srv-2.local(5069) TCP: srv-1.local(37927) -> srv-2.local(5069) Seq 2566830926.(213) ACK 3381252078 PUSH 1 1 1422527436.6006 (0.0032) C>SV3.1(208) Handshake ClientHello Version 3.1 random[32]= 51 f1 5c 7e 16 d6 05 73 19 21 5d 30 e6 a9 10 8a cd 43 cd f8 45 5b f9 3d 7f 3b d8 b7 80 d0 40 cc cipher suites Unknown value 0xc014 Unknown value 0xc00a TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA Unknown value 0x88 ... Unknown value 0xc002 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA ... Unknown value 0xff compression methods NULL TCP: srv-2.local(5069) -> srv-1.local(37927) Seq 3381252078.(0) ACK 2566831139 *[b]TCP: srv-2.local(5069) -> srv-1.local(37927) Seq 3381252078.(1448) ACK 2566831139 [/b]** **1 2 1422527441.6032 (5.0026) S>CV3.1(58) Handshake* ServerHello Version 3.1 ... *Non-working connection:* # ssldump -i eth1 -A -e -H -T port 5069 TCP: mypc.domain.com(40539) -> 1.2.3.4(5069) Seq 2748453215.(0) SYN TCP: 1.2.3.4(5069) -> mypc.domain.com(40539) Seq 221407102.(0) ACK 2748453216 SYN TCP: mypc.domain.com(40539) -> 1.2.3.4(5069) Seq 2748453216.(0) ACK 221407103 New TCP connection #1: mypc.domain.com(40539) <-> 1.2.3.4(5069) TCP: mypc.domain.com(40539) -> 1.2.3.4(5069) Seq 2748453216.(308) ACK 221407103 PUSH 1 1 1422527941.2773 (0.0203) C>SV3.1(303) Handshake ClientHello Version 3.3 random[32]= 54 ca 0d c5 e6 ea 2f a6 7b 8f 3f e2 07 88 ae 1d 80 71 14 7f 49 98 70 f3 23 2d 0a 54 c0 c1 1d 0d cipher suites Unknown value 0xc030 ... Unknown value 0x6a TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA Unknown value 0x88 ... TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA Unknown value 0xff compression methods unknown value NULL TCP: 1.2.3.4(5069) -> mypc.domain.com(40539) Seq 221407103.(0) ACK 2748453524 *TCP: 1.2.3.4(5069) -> mypc.domain.com(40539) Seq 221407103.(0) ACK 2748453524 RST ** **1 1422527941.2783 (0.0010) S>C TCP RST* So, after first handshake stage s_server sends RST TCP-packet and stops. Here my knowledge and fantasy is over as to decision of this problem. Give me advice please, how to force the openssl s_server to work. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jan 29 16:58:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Jan 2015 16:58:35 +0000 Subject: [openssl-users] Intermediate certificates In-Reply-To: References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> <825281422391371@web21m.yandex.ru> <20150127221419.GA11102@roeckx.be> <005801d03ace$f92db2a0$eb8917e0$@prinpay.com> Message-ID: > As I heard, OpenSSL 1.0.2 will do some improvement for > AuthorityInfoAccess, Am I right? Thanks! As in automatically fetch things? No. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From rsalz at akamai.com Thu Jan 29 17:13:49 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Jan 2015 17:13:49 +0000 Subject: [openssl-users] IPv6 and OpenSSL at the BIO level -- should it work? In-Reply-To: <56A41A14DF41784FA3CA37EF5760F2751F07C4C30F@MX30A.corp.emc.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07C4C30F@MX30A.corp.emc.com> Message-ID: <3ed055446bdb46c48cc4f5e5d7c903a0@ustx2ex-dag1mb2.msg.corp.akamai.com> IPv6 support is sketchy and incomplete and being worked on, albeit slowly. Doing all DNS and accept, etc., on your own and just passing an open socket descriptor to create a "socket BIO" should all just work fine. From steve at openssl.org Thu Jan 29 17:16:40 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 29 Jan 2015 17:16:40 +0000 Subject: [openssl-users] Intermediate certificates In-Reply-To: <825281422391371@web21m.yandex.ru> References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> <825281422391371@web21m.yandex.ru> Message-ID: <20150129171640.GA3399@openssl.org> On Tue, Jan 27, 2015, Serj wrote: > > Ok. But is there any documentation how to set intermediate certificates for my SSL connections? Maybe I want to support these broken sites... > You can add intermediate certificates to the trusted store: they'll then be used when it can no longer find suitable intermediates from the peer. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From dave.mclellan at emc.com Thu Jan 29 17:33:10 2015 From: dave.mclellan at emc.com (mclellan, dave) Date: Thu, 29 Jan 2015 12:33:10 -0500 Subject: [openssl-users] IPv6 and OpenSSL at the BIO level -- should it work? In-Reply-To: <3ed055446bdb46c48cc4f5e5d7c903a0@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <56A41A14DF41784FA3CA37EF5760F2751F07C4C30F@MX30A.corp.emc.com> <3ed055446bdb46c48cc4f5e5d7c903a0@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <56A41A14DF41784FA3CA37EF5760F2751F07C4C36F@MX30A.corp.emc.com> Hi Rich. Excellent. That's exactly what I thought. Thank you very much. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclellan at emc.com +-+-+-+-+-+-+-+-+- -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Thursday, January 29, 2015 12:14 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] IPv6 and OpenSSL at the BIO level -- should it work? IPv6 support is sketchy and incomplete and being worked on, albeit slowly. Doing all DNS and accept, etc., on your own and just passing an open socket descriptor to create a "socket BIO" should all just work fine. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From gayathri.annur at gmail.com Fri Jan 30 13:39:14 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Fri, 30 Jan 2015 19:09:14 +0530 Subject: [openssl-users] i2d_X509_SIG() in FIPS mode Message-ID: Hi All, I am getting segfault while using i2d_X509_SIG() in FIPS mode. (gdb) bt #0 0x01f95045 in __memcpy_ssse3_rep () from /lib/libc.so.6 #1 0x00466837 in asn1_ex_i2c () from /usr/local/cm/lib/libcrypto.so.1.0.1 #2 0x00466a36 in asn1_i2d_ex_primitive () from /usr/local/cm/lib/libcrypto.so.1.0.1 #3 0x00466c4c in ASN1_item_ex_i2d () from /usr/local/cm/lib/libcrypto.so.1.0.1 #4 0x0046727a in asn1_template_ex_i2d () from /usr/local/cm/lib/libcrypto.so.1.0.1 #5 0x00466eb3 in ASN1_item_ex_i2d () from /usr/local/cm/lib/libcrypto.so.1.0.1 #6 0x004675f3 in ASN1_item_i2d () from /usr/local/cm/lib/libcrypto.so.1.0.1 #7 0x0045fb3e in i2d_X509_SIG () from /usr/local/cm/lib/libcrypto.so.1.0.1 unsigned char *ptr, *tmp=NULL; len=i2d_X509_SIG(&sig,NULL); --> No issue sig.algor->algorithm=OBJ_nid2obj(NID_sha1); tmp = (unsigned char*) malloc(512+1); ptr=tmp; i2d_X509_SIG(&sig, &p); -->while calling secod time gettign core file. Its working fine in nonfips mode. But in FIPS getting core files. Please let me know how can i solve this issue. Thanks, Gayathri -------------- next part -------------- An HTML attachment was scrubbed... URL: From srirrao at gmail.com Fri Jan 30 13:46:31 2015 From: srirrao at gmail.com (Srinivas Rao) Date: Fri, 30 Jan 2015 19:16:31 +0530 Subject: [openssl-users] Wrong usage of PKCS7_add_signature()?? Message-ID: All, Please let me know if my below mentioned usage of PKCS7_sign()+adding signer info is wrong and how. Really appreciate your response. cheers and regards Srinivas On 1/29/15, Srinivas Rao wrote: > OpenSSL experts, > > Here the intention is to get the signed data (raw signature obtained > by PKCS11 APIs like C_Sign) to be packed in PKCS7 format (attached - > with certificate, content and signer info) using openssl. > > I am using USB token (smart card) for signing. > > Here's the code snippet. > > PKCS7* p7 = PKCS7_new(); > PKCS7_set_type(p7, NID_pkcs7_signed); > //PKCS7_SIGNER_INFO* pSI = PKCS7_SIGNER_INFO_new(); > //PKCS7_SIGNER_INFO_set(pSI, pX509, pX509->cert_info->key->pkey, > EVP_sha256()); > //PKCS7_add_signer(p7, pSI); > PKCS7_SIGNER_INFO* pSI = PKCS7_add_signature(p7, pX509, > pX509->cert_info->key->pkey, EVP_sha256()); // <== core dumps here > : > : > where pX509 is correctly obtained X509* node using d2i_X509() from the > value obtained from PKCS11 funcstions like C_GetAttributeValue() etc. > > I believe the set of the commented lines is the alternate way for this > add signature function - that also dumps core at > PKCS7_SIGNER_INFO_set() function. > > I have no clue as to what am I doing wrong here. > > Appreciate your help. > > regards > Srinivas From rasjv at yandex.com Fri Jan 30 19:55:19 2015 From: rasjv at yandex.com (Serj) Date: Fri, 30 Jan 2015 22:55:19 +0300 Subject: [openssl-users] Intermediate certificates In-Reply-To: <20150129171640.GA3399@openssl.org> References: <648661422386461@web1g.yandex.ru> <20150127201253.GY8034@mournblade.imrryr.org> <825281422391371@web21m.yandex.ru> <20150129171640.GA3399@openssl.org> Message-ID: <14301681422647719@web27m.yandex.ru> 29.01.2015, 20:18, "Dr. Stephen Henson" : > On Tue, Jan 27, 2015, Serj wrote: >> ?Ok. But is there any documentation how to set intermediate certificates for my SSL connections? Maybe I want to support these broken sites... > > You can add intermediate certificates to the trusted store: they'll then be > used when it can no longer find suitable intermediates from the peer. Ok. This is the decision I think. Really, it makes no sense if we will add only intermediate cert for some site without it's self-signed root cert. And so always if we will have another cert of some web-site which is signed with this intermediate cert, the last in the chain will be trusted self-signed root cert anyway. So, no any problems with security in this case! Thanks, Steve. -- Best Regards, Serj From pl at artisanlogiciel.net Fri Jan 30 21:18:19 2015 From: pl at artisanlogiciel.net (pl) Date: Fri, 30 Jan 2015 22:18:19 +0100 Subject: [openssl-users] Is openssl a vector of exploit for Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname ? Message-ID: <54CBF51B.2000501@artisanlogiciel.net> Hi, I was wondering if openssl a vector of exploitation of Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname ? reference and test code here http://www.openwall.com/lists/oss-security/2015/01/27/9 Here my quick study gethostbyname can be found only in b_sock.c used by struct hostent *BIO_gethostbyname(const char *name). so i guess using BIO_gethostbyname is a possible vector of use of this vulnerability. i searched for usages of BIO_gethostbyname in openssl code too. I reviewed BIO_get_host_ip(const char *str, unsigned char *ip) since even if it can call BIO_gethostbyname t won't do it if it is already detected as an ip, what is one of the requirements of the vulnerability. BIO_get_host_ip itself can be called by BIO_get_accept_socket when using BIO_do_accept(sock) on accept sockets, but since getaddrinfo is defined ( in glibc , could be wrong in some specific cases ? ) and then EAI_FAMILY, this BIO_get_host_ip won't in fact be called. So it look like only direct use of BIO_gethostbyname can cause issues and openssl does not rely on obsolete gethostbyname if it can use alternate getaddrinfo. I would be happy to receive any comment on that. Regards, Philippe Lhardy From rsalz at akamai.com Fri Jan 30 21:46:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 30 Jan 2015 21:46:46 +0000 Subject: [openssl-users] Is openssl a vector of exploit for Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname ? In-Reply-To: <54CBF51B.2000501@artisanlogiciel.net> References: <54CBF51B.2000501@artisanlogiciel.net> Message-ID: > So it look like only direct use of BIO_gethostbyname can cause issues and > openssl does not rely on obsolete gethostbyname if it can use alternate > getaddrinfo. > > I would be happy to receive any comment on that. Okay: I agree with your review... From openssl-users at dukhovni.org Fri Jan 30 21:51:26 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 30 Jan 2015 21:51:26 +0000 Subject: [openssl-users] Is openssl a vector of exploit for Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname ? In-Reply-To: References: <54CBF51B.2000501@artisanlogiciel.net> Message-ID: <20150130215126.GF8034@mournblade.imrryr.org> On Fri, Jan 30, 2015 at 09:46:46PM +0000, Salz, Rich wrote: > > So it look like only direct use of BIO_gethostbyname can cause issues and > > openssl does not rely on obsolete gethostbyname if it can use alternate > > getaddrinfo. > > > > I would be happy to receive any comment on that. > > Okay: I agree with your review... The fix is to deploy an updated glibc. Fixing everything linked to glibc is not particularly practical. -- Viktor. From susumu.sai.2006 at gmail.com Sat Jan 31 01:45:19 2015 From: susumu.sai.2006 at gmail.com (Susumu Sai) Date: Fri, 30 Jan 2015 20:45:19 -0500 Subject: [openssl-users] Is CVE-2014-3570 fixed in FIPS Object Module 1.* (1.1.2, 1.2, 1.2.2 ...) Message-ID: CVE-2014-3570 is fixed in 0.9.8ze. Does the BN_sqr implementation in FIPS Object Module 1.* also need to be fixed? If I run 0.9.8ze on FIPS mode with using FIPS Object Module 1.x, am I vulnerable to the CVE-2014-3570 attacks? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpb795795 at gmail.com Sat Jan 31 02:35:34 2015 From: dpb795795 at gmail.com (Deepak) Date: Sat, 31 Jan 2015 08:05:34 +0530 Subject: [openssl-users] OpenSSL 'verify' command and c_ rehash script on Cygwin Message-ID: <88F86BCF-3A81-45E2-AC06-1CF379FA9A39@gmail.com> Hi, Can following behaviour be confirmed as expected? OpenSSL verify test (test_verify) fails Env- c_rehash run using Cygwin. Run c_rehash on /path/to/certs/demo Cmd - openssl verify -CApath ../certs/demo ../certs/demo/*.pem Cause - Symbolic links (from hash.0 to file.pem) created by c_rehash when run with Cygwin could not be read by OpenSSL.exe verify command. Result - Error 20: could read issuer certificate OpenSSL.exe fails to establish certificate chain. Workaround - Modify c_rehash to use MS API 'mklink' Thank You.