Re: [openssl.org #1527] bug report - interop between TLS 1.1 and TLS 1.0 is not working
We have some interop issue between TLS 1.0 and TLS 1.1. Our application is based on OpenSSL 0.9.7 version (Linux - Operation system). This is Radvision SIP stack and oSIP stack. I don't quite understand. Does OpenSSL act as server or client? You must be referring to server... It doesn't work with one of two possible scenarios: 1) Client sends hello request to server where indicates that the latest supported version it is TLS 1.1. Server accepts this request but doesn't send back to client server hello request where should indicate the latest supported version for him TLS 1.0. After that the connection is dropped. (In correct behavior, server should send back to client server hello request with TLS 1.0 and after that client should re-send hello request but already using TLS 1.0). If we assume that OpenSSL acts as server, then I can't confirm this. I tried to send TSL 1.1 headers to 'openssl s_server' and it does not prevent it from responding with TLS 1.0 server hello. If we assume OpenSSL acts as client then it has to be modified version and then it's your responsibility... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1524] Bug with RSA cerficates/keys longer than 1024 bits
we are using openssl in an environment with a Windows 2003 PKI/CA. OpenSSL together with OpenLDAP shall be used to provide Single Sign On. This is working as long as the servers public key on the Windows AD server is not getting larger than 1024 bit. I have tested the following commands with openssl 0.9.8d and 0.9.8e on SuSE Linux and Windows XP. This is the typical result if i try to connect to a server with a key larger than 1024 bit: # openssl s_client -connect 10.17.1.1:636 CONNECTED(0003) depth=1 /DC=local/DC=customer/CN=customer Issuing CA 01 verify error:num=20:unable to get local issuer certificate verify return:0 21981:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: I can't reproduce it with neither 2048- or 4096-bit self-signed certificates. Could submit complete 'openssl s_client -connect 10.17.1.1:636 -debug' output from failing attempt? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1511] A possible bug when compiling openSSL with minGW
[EMAIL PROTECTED] via RT wrote: Hi, I am having a bit of a trouble compiling the openSSL release 0.9.8e under WinXP SP2. The version of minGW's the gcc compiler I am using is 3.4.5-20060117-1 and the minGW32-make is 3.80.0-1. For some reason the build tools use malformed file names such as .\crypto\/cryptlib.h (pay attention to the \/ -- it's not V, but \ and / concatenated) and the compilation fails with the final message being mingw32-make: *** [tmp\cryptlib.o] Error 1. I included the compile log with my letter. Any ideas what might be the issue here? The fact that you see \/ is not relevant, or at least it's not the one causing problems. Trouble apparently is that gcc fails to locate standard headers, such as stdio.h, stdlib.h, windows.h, etc. You're likely to fail to compile *any* program. In other words it's no OpenSSL problem and I'm dismissing this case. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1426] openssl on a Mac
0.9.7 is no longer [actively] supported. Mac OS support is improved in 0.9.8 stable and development versions and we advice to use them instead. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1394] 0.9.8c darwin-i386-cc broken without config shared
This was fixed at some point. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1580] Resolved: [PATCH] add read through fp support for certificate loading
On Tue, 18 Sep 2007 15:44:46 +0200 (CEST) Ben Laurie via RT [EMAIL PROTECTED] wrote: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I don't agree with this, as steve stated in a previous email: Instead of relying on file based SSL functions you can instead rely on structure based ones using X509, EVP_PKEY et al. You'd load the structures outside the jail and keep them hanging around inside. Then when you need to reload you just pass the necessary structures. Here is the reply I sent: There's no reliable way to pass these structures on a AF_UNIX socket since I don't know their internals (without pulling in header files I'm not supposed to) and there are other pointers in the X509 and related structs. If you guys think its still achievable without changing openssl, then fine. I really don't see a clean way without breaking the API though. At least there is no documented way of doing this without API violation unless I missed something. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1580] Resolved: [PATCH] add read through fp support for certificate loading
On Tue, 18 Sep 2007 15:44:46 +0200 (CEST) Ben Laurie via RT [EMAIL PROTECTED] wrote: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I don't agree with this, as steve stated in a previous email: Instead of relying on file based SSL functions you can instead rely on structure based ones using X509, EVP_PKEY et al. You'd load the structures outside the jail and keep them hanging around inside. Then when you need to reload you just pass the necessary structures. Here is the reply I sent: There's no reliable way to pass these structures on a AF_UNIX socket since I don't know their internals (without pulling in header files I'm not supposed to) and there are other pointers in the X509 and related structs. If you guys think its still achievable without changing openssl, then fine. I really don't see a clean way without breaking the API though. At least there is no documented way of doing this without API violation unless I missed something. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1485] [PATCH] Type Punning fix for 0.9.7f+ and all 0.9.8 on Big Endien 64 bit machines
We have been building OpenSSL on PPC64 and S390X platforms with Linux and have found some type punning errors in both the 0.9.7 tree and the 0.9.8 tree. The self-test test_x509 fails due to this error. This error only seems to appear on big endien 64 bit machines, whether compiling for 32 or 64 bit targets. This is circumstantial. I mean it's not specific to big endian 64-bit platforms. It takes aggressive optimizer and large register bank, large enough to apply those aggressive optimizations. Proper fix is http://cvs.openssl.org/chngview?cn=16407 [and http://cvs.openssl.org/chngview?cn=16408 for 0.9.8]. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1580] Resolved: [PATCH] add read through fp support for certificate loading
On Tue, Sep 18, 2007, Pierre-Yves Ritschard via RT wrote: On Tue, 18 Sep 2007 15:44:46 +0200 (CEST) Ben Laurie via RT [EMAIL PROTECTED] wrote: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I don't agree with this, as steve stated in a previous email: Instead of relying on file based SSL functions you can instead rely on structure based ones using X509, EVP_PKEY et al. You'd load the structures outside the jail and keep them hanging around inside. Then when you need to reload you just pass the necessary structures. Here is the reply I sent: There's no reliable way to pass these structures on a AF_UNIX socket since I don't know their internals (without pulling in header files I'm not supposed to) and there are other pointers in the X509 and related structs. Well if you really wanted to you could pass their encoding using i2d_X509() and d2i_X509() at the other end but that's not the cleanest way. If you guys think its still achievable without changing openssl, then fine. I really don't see a clean way without breaking the API though. At least there is no documented way of doing this without API violation unless I missed something. Well other than the new error codes you are largely making use of documented functions in OpenSSL so that the whole functionality could be implemented (with few changes) outside the ssl library at an application level. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1583] assertion
This transaction appears to have no content __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1580] Resolved: [PATCH] add read through fp support for certificate loading
Hi Steve, thanks for replying ! Well other than the new error codes you are largely making use of documented functions in OpenSSL so that the whole functionality could be implemented (with few changes) outside the ssl library at an application level. Alright. I could indeed. But this is not documented and in my opinion is thus not exported through SSL's API. I guess my question is: isn't cleaner and less error prone - thus improving security - to enable openssl applications to be able to do that ? What is the cost of allowing this behavior in next versions of openssl ? The library footprint shows very little increase. Sure it would require a major library bump since the API changes, but you're already about to do that with 0.98.x (+ this is only adding functionnality, not changing an existing one). In the meantime I will take these changes inside my application, I still really feel it could promote the writing of privsep'd programs which would be nice. Last, if you have issues with how the proposed changes are written and would rather see it done in a different way before supposedly going in, I'd be glad to rewrite it (or to see it rewritten by someone else). Thanks ! Pierre-Yves. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Patch for default CApath
Hi, I've created very small patch that uses default CApath ($OPENSSLDIR/certs/), it allows apps using OpenSSL and not allowing to specify CApath to function correctly. Most Linux distributions install certificates (for example root certificate for CACert) there. Before patch: $ wget 'https://rudolf/' --21:09:01-- https://rudolf/ = `index.html' Resolving rudolf... 10.0.0.6 Connecting to rudolf|10.0.0.6|:443... connected. ERROR: Certificate verification error for rudolf: unable to get local issuer certificate To connect to rudolf insecurely, use `--no-check-certificate'. Unable to establish SSL connection. With patch applied: $ wget 'https://rudolf/' --21:08:24-- https://rudolf/ = `index.html' Resolving rudolf... 10.0.0.6 Connecting to rudolf|10.0.0.6|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 906 [text/html] 100%[=] 906 --.--K/s 21:08:24 (11.12 MB/s) - `index.html' saved [906/906] That server (Apache) has a certificate signed by CACert. Can it get included in next version of OpenSSL? -- Krzysztof Pawlik DBA - KP1365-RIPE tel./fax: (+48 12) 628-73-50 e-mail: [EMAIL PROTECTED] diff -Nru --exclude='*.o' openssl-0.9.8e.vanilla/ssl/ssl_lib.c openssl-0.9.8e/ssl/ssl_lib.c --- openssl-0.9.8e.vanilla/ssl/ssl_lib.c2007-09-18 10:56:56.0 +0200 +++ openssl-0.9.8e/ssl/ssl_lib.c2007-09-18 11:43:37.0 +0200 @@ -128,6 +128,9 @@ #ifndef OPENSSL_NO_DH #include openssl/dh.h #endif +#define HEADER_CRYPTLIB_H +#include openssl/opensslconf.h +#undef HEADER_CRYPTLIB_H const char *SSL_version_str=OPENSSL_VERSION_TEXT; @@ -1453,6 +1456,8 @@ ret-extra_certs=NULL; ret-comp_methods=SSL_COMP_get_compression_methods(); + SSL_CTX_load_verify_locations(ret, NULL, OPENSSLDIR /certs); + return(ret); err: SSLerr(SSL_F_SSL_CTX_NEW,ERR_R_MALLOC_FAILURE); signature.asc Description: OpenPGP digital signature
Re: Re: [openssl.org #1485] [PATCH] Type Punning fix for 0.9.7f+ and all 0.9.8 o
Andy - These fixes look great and solve the underlying problem we encountered with x_name.c and assumed byte-ordering. We will re-test with these fixes and get back to you, but for now please consider this case closed (and fixed). Thanks, Mike Michael Kobar [EMAIL PROTECTED] Chief Technology Officer860.434.4018 phone Lymeware Corporation240.218.7363 fax 860.967.3888 cell www.lymeware.com From: Andy Polyakov via RT [EMAIL PROTECTED] Date: 2007/09/18 Tue PM 12:26:14 EDT To: [EMAIL PROTECTED] CC: openssl-dev@openssl.org Subject: Re: [openssl.org #1485] [PATCH] Type Punning fix for 0.9.7f+ and all 0.9.8 on Big Endien 64 bit machines We have been building OpenSSL on PPC64 and S390X platforms with Linux and have found some type punning errors in both the 0.9.7 tree and the 0.9.8 tree. The self-test test_x509 fails due to this error. This error only seems to appear on big endien 64 bit machines, whether compiling for 32 or 64 bit targets. This is circumstantial. I mean it's not specific to big endian 64-bit platforms. It takes aggressive optimizer and large register bank, large enough to apply those aggressive optimizations. Proper fix is http://cvs.openssl.org/chngview?cn=16407 [and http://cvs.openssl.org/chngview?cn=16408 for 0.9.8]. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
