RE: OpenSSL 0.9.8n v. VMS
Hello, I just simply can not believe, that in an open source project, vital, port related changes needs to be submitted so many times... and nothing happens. I suggest taking Steven M. Schweda into the OpenSSL project team with shared OpenVMS responsibility (and commit rights) beside Richard Levitte. Thank you. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 24 mars 2010 17:35 To: openssl-dev@openssl.org Subject: OpenSSL 0.9.8n v. VMS An OpenSSL 0.9.8n kit which appears to work on VMS should be available at: http://antinode.info/ftp/openssl/0_9_8n/openssl-0_9_8n_s1.zip The suggested changes are the same as for 0.9.8m: http://antinode.info/ftp/openssl/0_9_8m/ Not amazingly, old complaints/questions persist: As previously explained, I claim that some of these changes are closer to minimal than to optimal: crypto/o_init.c: Loose extern declarations, instead of a header file. makevms.com: Still overwrites a symlink, apps/md4.c, with crypto/md4/md4.c. (Who uses/needs apps/md4.c?) util/libeay.num: Excludes pqueue_print() on VAX, instead of providing working 32-bit code (crypto/pqueue/pqueue.c). Steven M. Schweda s...@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.
On Mon, 2009-09-14 at 23:13 +0200, David Woodhouse via RT wrote: I'm a little confused about the way Intel AES-NI is supported in OpenSSL HEAD. This is just a feature of new CPUs, like SSE is. Yet SSE support is directly included in the normal assembly routines for x86, while AES-NI is implemented separately as an engine. Why is that? Are we slowly moving _all_ the 'special' implementations to engines, and uncluttering the core implementations? Or are we just being inconsistent? Or is there some distinction between the two (SSE/AESNI) that I'm missing, which makes it sensible to treat them differently? For now, let's at least address the major disadvantage of the engine, which is that it doesn't even get _used_ unless someone registers it. diff --git a/crypto/engine/eng_aesni.c b/crypto/engine/eng_aesni.c index 2a997ca..91fb5b8 100644 --- a/crypto/engine/eng_aesni.c +++ b/crypto/engine/eng_aesni.c @@ -106,6 +106,7 @@ void ENGINE_load_aesni (void) return; ENGINE_add (toadd); ENGINE_free (toadd); + ENGINE_register_complete (toadd); ERR_clear_error (); #endif } Ping? -- dwmw2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
TLS session resumption finished messages
Hi, I've recently finished my own from scratch, mini-scaled TLS 1.1 protocol implementation. Now, I want to add session resumption capability for it (not for the new specification). but couldn't find enough information even from the standard. My question, what are the handshake messages going to be hashed while making the client/server finished messages? are they only the new client_hello/server_hello handshake messages or all the previous handshake messages (may be from cache) but with the new client_hello/server_hello messages? I don't know if this is the right category for this kind of question. But I really need ur reply soon. thnx in advance -- View this message in context: http://old.nabble.com/TLS-session-resumption-finished-messages-tp28027265p28027265.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2202] OpenSSL 0.9.8n v. VMS
My knowledge of VMS is minimal so I've just applied this patch as is. I made one change to stop libeay.num being overwritten on the next make update. Those hacks in mkdef.pl to manually add symbol information look like they should be handled more cleanly at some point. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2192] [PATCH] chil engine displays weird prompts to the end user
I've tested todays snapshot and I can confirm that all issues are resolved. Kind Regards Jaroslav Imrich Disig, a.s. Zahradnicka 151, 821 08 Bratislava 2 jaroslav.imr...@disig.sk www.disig.sk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
libcrypto safe for library use?
The threads(3) manpage states that to use OpenSSL in multi-threaded applications then locking callback functions must be set otherwise random crashes may occur. This poses a challenge when using OpenSSL in a library which should be MT safe. There is no safe way to set the locking callbacks from within the library itself. The calling application may or may not be using OpenSSL or may be linking against multiple libraries some of which may be linked against OpenSSL. The application may not even be aware that it will end up calling into OpenSSL code. The only safe way to ensure that the OpenSSL code will be MT safe would be for the OpenSSL library itself to set locking callbacks, however I don't see any compile-time option to do that. Is there a reason I'm missing as to why this option isn't available? Without this, the library can do its best to set the locking callbacks when loaded if they are not set and then remove them when unloaded, however this will always be inherently racy if there are other parts of the process using OpenSSL. Thanks, -M __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2192] [PATCH] chil engine displays weird prompts to the end user
I've tested todays snapshot and I can confirm that all issues are resolved. Kind Regards Jaroslav Imrich Disig, a.s. Zahradnicka 151, 821 08 Bratislava 2 jaroslav.imr...@disig.sk www.disig.sk :��IϮ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��jם.+-1�ځ��j:+v���h�
[openssl.org #2203] [PATCH] fix fallback to default verify paths
---
apps/s_client.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/apps/s_client.c b/apps/s_client.c
index 484d009..3f57a5d 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -904,12 +904,19 @@ bad:
if (!set_cert_key_stuff(ctx,cert,key))
goto end;
- if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
- (!SSL_CTX_set_default_verify_paths(ctx)))
+ if (CAfile || CApath)
{
- /* BIO_printf(bio_err,error setting default verify
locations\n); */
- ERR_print_errors(bio_err);
- /* goto end; */
+ if (!SSL_CTX_load_verify_locations(ctx,CAfile,CApath))
+ {
+ BIO_printf(bio_err,error setting verify locations\n);
+ ERR_print_errors(bio_err);
+ goto end;
+ }
+ }
+ else
+ {
+ BIO_printf(bio_c_out,using default CA certificates\n);
+ SSL_CTX_set_default_verify_paths(ctx);
}
#ifndef OPENSSL_NO_TLSEXT
--
1.6.4.2
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2204] Contribution [OS: all] [Version openssl-0.9.8m]
Dear Sir,
I would like to make this contribution to openssl
Feature implemented: aes key wrapper for all key sizes(RFC 5649)
Thanks
/* crypto/aes/aes_wrap.c */
/* Written by Dr Stephen N Henson (st...@openssl.org) for the OpenSSL
* project.
* Modified by Attaullah Baig (ab...@paypal.com) to wrap/unwrap any
* size keys (Implemented RFC5649)
*/
/*
* Copyright (c) 2008 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. All advertising materials mentioning features or use of this
*software must display the following acknowledgment:
*This product includes software developed by the OpenSSL Project
*for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)
*
* 4. The names OpenSSL Toolkit and OpenSSL Project must not be used to
*endorse or promote products derived from this software without
*prior written permission. For written permission, please contact
*licens...@openssl.org.
*
* 5. Products derived from this software may not be called OpenSSL
*nor may OpenSSL appear in their names without prior written
*permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
*acknowledgment:
*This product includes software developed by the OpenSSL Project
*for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/
#include openssl/aes.h
#include openssl/bio.h
#include netinet/in.h
static const unsigned char default_iv[] = {
0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6,
};
static const unsigned char alternate_iv[] = {
0xA6, 0x59, 0x59, 0xA6,
};
int AES_wrap_key_withpad(AES_KEY *key, unsigned char *out,
const unsigned char *in, unsigned int inlen)
{
int len, nlen, ret = -1;
unsigned char *input, iv[8];
if (!inlen)
return -1;
len = inlen+(inlen%8 == 0 ? 0 : (8-inlen%8));
nlen = htonl(inlen);
input = OPENSSL_malloc(len+8);
if(!input)
return -1;
memset(input, 0, len+8);
memcpy(iv, alternate_iv, 4);
memcpy(iv+4, ((unsigned char *) nlen), 4);
if(len == 8)
{
memcpy(input, iv, 8);
memcpy(input+8, in, inlen);
AES_encrypt(input, out, key);
ret = 8+8;
}
else
{
memcpy(input, in, inlen);
ret = AES_wrap_key(key, iv, out, input, len);
}
OPENSSL_free(input);
return ret;
}
int AES_unwrap_key_withpad(AES_KEY *key, unsigned char *out,
const unsigned char *in, unsigned int inlen)
{
int len, padlen;
unsigned char a_iv[8], zero_iv[8];
memset(zero_iv, 0, 8);
if (inlen 0x7)
return -1;
if (inlen 16)
return -1;
if(inlen == 16)
{
AES_decrypt(in, out, key);
memcpy(a_iv, out, 8);
memmove(out, out+8, 8);
}
else
{
if(AES_unwrap_key(key, NULL, out, in, inlen, a_iv) = 0)
return -1;
}
if(memcmp(a_iv, alternate_iv, 4))
return -1;
memcpy((unsigned char *) len, a_iv+4, 4);
len = ntohl(len);
inlen -= 8;
if(len inlen || len = (inlen-8))
return -1;
RE: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.
Though I am not a member of the OpenSSL team, I totally agree with you. As for the AES, the Westmere CPUs have also a new instruction for the GHASH (pclmulqdq / _mm_clmulepi64_si128). This as well is only available as intrinsic or in native assembler. So, when I offered some weeks ago a contribution regarding the GHASH for the GCM, (now with a fallback from pclmulqdq to SSE2 to native C), I was instructed that (at least inline) assembler or intrinsics are not an option for OpenSSL. Inline assembler (or exotic intrinsics) is not considered as viable option for MMX/SSE (or any code bigger than couple of instructions), perlasm code is. As all major compilers for Intel CPUs support intrinsics and, if used correctly, optimize to the same instructions as direct assembler, IMHO these policies should be reconsidered to keep OpenSSL competitive. For good reasons perlasm is not an option for a company like Intel. To get a solution, I now use a self-patched version of OpenSSL with intrinsics which fulfills my and my customer's requirements. Peter-Michael -- Peter-Michael Hager - acm senior - HAGER-ELECTRONICS GmbH - Germany On Mon, 2009-09-14 and Thu, 2010-30-25 David Woodhouse via RT wrote: I'm a little confused about the way Intel AES-NI is supported in OpenSSL HEAD. This is just a feature of new CPUs, like SSE is. Yet SSE support is directly included in the normal assembly routines for x86, while AES-NI is implemented separately as an engine. Why is that? Are we slowly moving _all_ the 'special' implementations to engines, and uncluttering the core implementations? Or are we just being inconsistent? Or is there some distinction between the two (SSE/AESNI) that I'm missing, which makes it sensible to treat them differently? For now, let's at least address the major disadvantage of the engine, which is that it doesn't even get _used_ unless someone registers it. diff --git a/crypto/engine/eng_aesni.c b/crypto/engine/eng_aesni.c index 2a997ca..91fb5b8 100644 --- a/crypto/engine/eng_aesni.c +++ b/crypto/engine/eng_aesni.c @@ -106,6 +106,7 @@ void ENGINE_load_aesni (void) return; ENGINE_add (toadd); ENGINE_free (toadd); + ENGINE_register_complete (toadd); ERR_clear_error (); #endif } __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2205] bug report: ECDSA in TLS handshake
Hi, I'd like to submit bug report for OpenSSL version 1.x and up, all platforms supporting ECDSA in TLS handshake in version 1.0.0 there were new digest algorithms introduced NID_ecdsa_with_SHA224 NID_ecdsa_with_SHA256 NID_ecdsa_with_SHA384 NID_ecdsa_with_SHA512 in addition to NID_ecdsa_with_SHA1 When certificate with one of new signature algorithms used in handshake, it failed with error 0x1408a0c1 'no shared cipher'. The reason is that ssl_set_cert_masks() function only checks for NID_ecdsa_with_SHA1 algorithm ssl_lib.c (1.0.0-beta5) line #1993 if (signature_nid == NID_ecdsa_with_SHA1) I'd suggest replace it with if ((signature_nid == NID_ecdsa_with_SHA1) || (signature_nid == NID_ecdsa_with_SHA224) || (signature_nid == NID_ecdsa_with_SHA256) || (signature_nid == NID_ecdsa_with_SHA384) || (signature_nid == NID_ecdsa_with_SHA512)) Another place is in function ssl_check_srvr_ecc_cert_and_alg() ssl_lib.c (1.0.0-beta5) line #2077 if (signature_nid != NID_ecdsa_with_SHA1) replace with if ((signature_nid != NID_ecdsa_with_SHA1) (signature_nid != NID_ecdsa_with_SHA224) (signature_nid != NID_ecdsa_with_SHA256) (signature_nid != NID_ecdsa_with_SHA384) (signature_nid != NID_ecdsa_with_SHA512)) Of course it's might be even better to check for ECDSA generally, but I don't know how to make it simple (convert it to string and search ECDSA?) Thanks, Alex Tyshlek __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
OpenSSL wrote: Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m How comes the vulnerability doesn't touch 0.9.8e though the patched file wasn't modified between 0.9.8e and 0.9.8f ? But that code was modified between 0.9.8d and 0.9.8e, see this patch : http://cvs.openssl.org/filediff?f=openssl/ssl/s3_pkt.cv1=1.60v2=1.61 Could it be a reference mistake and that this vulnerability is from 0.9.8e through 0.9.8m ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Mar 25, 2010, at 6:33 PM, Jean-Marc Desperrier wrote: OpenSSL wrote: Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m How comes the vulnerability doesn't touch 0.9.8e though the patched file wasn't modified between 0.9.8e and 0.9.8f ? But that code was modified between 0.9.8d and 0.9.8e, see this patch : http://cvs.openssl.org/filediff?f=openssl/ssl/s3_pkt.cv1=1.60v2=1.61 Could it be a reference mistake and that this vulnerability is from 0.9.8e through 0.9.8m ? No, it's not a mistake -- it's code elsewhere that no longer tolerates the coarse logic we are changing in the patch, which has been around forever. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Am I reading the changes file correctly: if you don't use Kerberos, then this vulnerability doesn't apply? Thanks, Paul ___ Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 | paul.suh...@quantum.com ___ Disregard the Quantum Corporation confidentiality notice below. The information contained in this transmission is not confidential. Permission is hereby explicitly granted to disclose, copy, and further distribute to any individuals or organizations, without restriction. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Bodo Moeller Sent: Thursday, March 25, 2010 11:40 AM To: openssl-dev@openssl.org Subject: Re: OpenSSL Security Advisory On Mar 25, 2010, at 6:33 PM, Jean-Marc Desperrier wrote: OpenSSL wrote: Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m How comes the vulnerability doesn't touch 0.9.8e though the patched file wasn't modified between 0.9.8e and 0.9.8f ? But that code was modified between 0.9.8d and 0.9.8e, see this patch : http://cvs.openssl.org/filediff?f=openssl/ssl/s3_pkt.cv1=1.60v2=1.61 Could it be a reference mistake and that this vulnerability is from 0.9.8e through 0.9.8m ? No, it's not a mistake -- it's code elsewhere that no longer tolerates the coarse logic we are changing in the patch, which has been around forever. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory: Record of death
On Thu, Mar 25, 2010, Bodo Moeller wrote: Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m No, it's not a mistake -- it's code elsewhere that no longer tolerates the coarse logic we are changing in the patch, which has been around forever. Could you please elaborate? I'm asking this because: - we ship OpenSSL 0.9.8k + some security patches, e.g., turn off renegotiation. - I need to find out whether our version is affected (if it is, we need to update our products to include this patch) So far I haven't been able to determine which change caused the problem, so I'm still looking at various diff's, but I'm not familiar with the source code to (easily) spot the problem. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Thu, Mar 25, 2010, Paul Suhler wrote: Am I reading the changes file correctly: if you don't use Kerberos, then this vulnerability doesn't apply? There are two separate issues. CVE-2010-0740 applies to 0.9.8m SSL/TLS and has nothing to do with Kerberos. That is why we made the special release. CVE-2010-0433 applies only if OpenSSL is compiled with kerberos support (it isn't by default). This was fixed before and since it only affected kerberos builds it was felt it didn't warrant a release. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: libcrypto safe for library use?
Mark Phalan wrote: The threads(3) manpage states that to use OpenSSL in multi-threaded applications then locking callback functions must be set otherwise random crashes may occur. That is correct. This poses a challenge when using OpenSSL in a library which should be MT safe. There is no safe way to set the locking callbacks from within the library itself. The calling application may or may not be using OpenSSL or may be linking against multiple libraries some of which may be linked against OpenSSL. The application may not even be aware that it will end up calling into OpenSSL code. It's trivial -- adopt the same solution OpenSSL adopts. Have the application set your library's locking callbacks and you pass them onto OpenSSL. It won't matter then if you change the callbacks because you'd be changing them to what they already were or would be anyway. The only safe way to ensure that the OpenSSL code will be MT safe would be for the OpenSSL library itself to set locking callbacks, however I don't see any compile-time option to do that. It can't do that, it has no idea what threading model the application is using. It would have no way to know whether the locks it provided were suitable or sensible. Is there a reason I'm missing as to why this option isn't available? The library has no way to know what threading model the application that calls it is using. Only the application has this knowledge, so it's the application's responsibility to pass this to the library. Without this, the library can do its best to set the locking callbacks when loaded if they are not set and then remove them when unloaded, however this will always be inherently racy if there are other parts of the process using OpenSSL. I agree. Your library should impose a requirement on any application that uses it that it inform you of the threading model it's using so that you can use appropriate locking as well. Then you can set the OpenSSL locking callbacks (just pass them through) and there's no chance of a race or problem. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
