Re: 0.9.8b + zlib + -bugs?
Hello, Interesting that the initial session is uncompressed, but the resumed session is... With default configuration (enabled ssl2/3,tls1) OpenSSL client sends SSL2 ClientHello packet (with TLS1 protocol version) which has no support for compression information. I'll gladly test any snapshot that addresses this issue. Simply way to disable TLS1_FLAGS_TLS_PADDING_BUG when compression is compiled in AND when peer want to use compression is to change line ssl/t1_enc.c:831 : if ((memcmp(s-s3-read_sequence, \0\0\0\0\0\0\0\0,8) == 0) !(ii 1)) to someting like: if ((memcmp(s-s3-read_sequence, \0\0\0\0\0\0\0\0,8) == 0) !(ii 1) !s-expand) Is there any way to determine at run-time whether the OpenSSL library is a 0.9.8[ab] release with zlib enabled? SSL_COMP_get_compression_methods() returns always NULL when compression is not compiled in. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8b + zlib + -bugs?
On Sat, May 06, 2006, Victor Duchovni wrote: I'll gladly test any snapshot that addresses this issue. OK, please try the next snapshot and/or this patch: http://cvs.openssl.org/chngview?cn=15251 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8b windows binaries
- Original Message - From: Wai Wu [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Saturday, May 06, 2006 2:36 PM Subject: RE: 0.9.8b windows binaries Hummm. I downloaded the binary from http://hunter.campbus.com/, and I am using Visual Studio 2005 C++, and everything works fine. Ofcourse, I have the issue of getting a good random number generator. From: [EMAIL PROTECTED] on behalf of Kyle Hamilton Sent: Sat 5/6/2006 12:31 AM To: openssl-users@openssl.org Subject: Re: 0.9.8b windows binaries First off, those aren't official. They seem to be compiled by VC++ 6, which seems to be binary-incompatible with VC++ .Net 2002+. (I use VC++2005 Express Edition, at the moment, and I can't get anything to run when linked against those.) Any inquiries about the Shining Light Productions binaries need to be directed there. He might be modifying his build process to include a FIPS-compliant version of 0.9.7j -- I just don't know. -Kyle H On 5/5/06, Mike Ehlert [EMAIL PROTECTED] wrote: Can anyone tell me how long it usually takes after a release before the official Windows binaries are updated (at Shining Light Productions)? Regards, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8b windows binaries
Oops. looks like I sent a blank reply to the list earlier this morning. My apologies to all. Hummm. I downloaded the binary from http://hunter.campbus.com/, I was going to comment that this site does not offer the 0.9.8b binaries, but what I'm after now is some information on any tricks to compiling the DLL's with only the features needed for my application to reduce their size. I'd rather not try to blindly rip appart the source without some guidance as I am not a C++ coder, my former coding skills were limited to masm. Regards, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Improving ssl conection time
Dear all,
I'm working with an xml messaging protocol where
messages are exchaged by means of ssl connections.
The client needs to open/close a new connection for
every message to sent (the server adopts this policy
and it is not possible to change it), so I was trying
to understand a little more on BIO_do_connect.
In the past, I used to sleep(2) on BIO_do_connect to
to waif for ssl handshake to be performed, here a
snip of code
// CTX settngs (keys, cert,...)
BIO_get_ssl(out, ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
BIO_set_nbio(out,1);
if (BIO_do_connect(out) = 0){
sleep(2);
}
However I noticed sleep(2) slows down my client
application, I got better times if I don't use sleep
and I go directly to use BIO_read and BIO_write, and
wait for the BIO to be ready using int values returned
by these functions and related macro BIO_should_read
...
bytesRead = BIO_read(out, buf, sizeof(buf));
while ( (!(bytesRead == 0)) (count NTRIES)){
if (bytesRead 0) {
if(BIO_should_read(out) || BIO_should_retry(out))
This works almost fine with SSLv3 but if I try to use
TLS 1 (server supports both) I receive too much
connection error.
Checking what is happening with ssldump I see the
handshake hangs up on ClientKeyExchange when the
master key should be already be aggred
ssldump -q
6 1 0.1293 (0.1293) CS SSLv2 compatible client
hello
6 2 0.2623 (0.1329) SC Handshake ServerHello
6 3 0.6656 (0.4032) SC Handshake Certificate
ServerKeyExchange
CertificateRequest
certificate_authority
certificate_authority
ServerHelloDone
6 4 0.6945 (0.0289) CS Handshake Certificate
6 5 0.8243 (0.1298) CS Handshake
ClientKeyExchange
How could I improve and possibly speed up ssl
connetion time in a correct manner ?
Thanks,
Marco Rossi
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
openssl speed -engine chil error
Hi, I installed openssl 0.9.8a from www.sunfreeware.com for my solaris 10 server. I have a nfast's www.nChiper.com Crypto device. This version can make use of nfast module using the CHIL(Cryptographic Hardware Interface Library), because following command says: #openssl engine chil CHIL hardware engine supoort Am I right? After, I run speed test with following command: # openssl engine chil-pre SO_PATH:/opt/nfast/toolkits/hwcrhk (chil) CHIL hardware engine support[Success]: SO_PATH:/opt/nfast/toolkits/hwcrhk#openssl speed -engine chil and i get following errors:can't use that engine1523:error:80067072:CHIL engine:HWCRHK_INIT:locking missing:e_chil.c:594:You HAVE to add dynamic locking callbacks via
CRYPTO_set_dynlock_{create,lock,destroy}_callback()1523:error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed:eng_table.c:161:Doing md2 for 3s on 16 size blocks: 79767 md2's in 3.03sDoing md2 for 3s on 64 size blocks: ^C Please Help me!Thanks
24 FIFA World Cup tickets to be won with Yahoo! Mail. Learn more
Re: 0.9.8b windows binaries
On 5/7/06, Mike Ehlert [EMAIL PROTECTED] wrote: Oops. looks like I sent a blank reply to the list earlier this morning. My apologies to all. Hummm. I downloaded the binary from http://hunter.campbus.com/, I was going to comment that this site does not offer the 0.9.8b binaries, but what I'm after now is some information on any tricks to compiling the DLL's with only the features needed for my application to reduce their size. I'd rather not try to blindly rip appart the source without some guidance as I am not a C++ coder, my former coding skills were limited to masm. Regards, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] Mike, I provide the binaries for hunter.campbus.com. The files are actually stored at brandleadershipmarketing.com/apache. You can take the Archive and MD5 link from hunter.campbus.com. I have been busy and have not had time to build Openssl-0.9.8b. I will be getting to the Apache builds in the next few days but I thought I would try to address your issue - smaller binaries. I assume you also need headers and libs for building your application. I will be waiting for an update to mod_ssl for Apache 1.3.x. I noticed an option for the build to not statically link the engines. This results in binaries that are a little smaller. I built the code with 'no-static-engine' and used the 'install' option. Then I zipped up the directory structure created by the makefile in c:\openssl. The engine dll's can be found in the c:\openssl\lib\engines directory. Openssl-0.9.8b-no-static-engine-Win32.zip Try this build and let me know if it suits your needs. If it does I will continue the build the updates in this form in addition to the regular package, which is created to support Apache 1.3.x. Apache 2.x.x are packaged with OpenSSL included. If you prefer you can build your own using these options, but let me know so that I know if should continue to provide this form of package. Chris Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Random errors in openssl apps
Title: Random errors in openssl apps Folks, Using RedHat ES3.0 stock openssl RPM, for which openssl version yields 'OpensSSL 0.9.7a Fed 19 2003, I get random SEGVs while doing pk7out or verify operations using openssl smime -pk7out or openssl smime -verify. The discouraging thing about this is that repeating the failed operation has not reproduced the failure -- the message is processed successfully. I have enabled the capture of core files, and get at least a hint of the problem, as below. However, the RH binaries are not symbol laden, so a hint is all I get. I'm hoping someone has seen something like this and has an answer in hand. I suspect that my only option is to get the RH source, build with symbols and wait for something bad to happen for me to look at. Anybody have other suggestions? Thanks, rnd = cut here = [ verify operation ] $ gdb openssl corefile ... Core was generated by `/usr/bin/openssl smime -verify -in entity.verify -inform SMIME'. Program terminated with signal 11, Segmentation fault. ... (gdb) where #0 0x00f3c4ec in memcpy () from /lib/tls/libc.so.6 #1 0x009901a1 in BIO_new_mem_buf () from /lib/libcrypto.so.4 #2 0x0098f136 in BIO_write () from /lib/libcrypto.so.4 #3 0x009dc4cd in SMIME_text () from /lib/libcrypto.so.4 #4 0x009dbe5d in SMIME_read_PKCS7 () from /lib/libcrypto.so.4 #5 0x08082302 in msg_cb () #6 0x08054bbc in ?? () #7 0x000a in ?? () #8 0xbfffd148 in ?? () #9 0xbfffcbb8 in ?? () #10 0x08055062 in ?? () #11 0xbfffd070 in ?? () #12 0x08097684 in ?? () #13 0xbfffcbe8 in ?? () #14 0x00997994 in lh_doall_arg () from /lib/libcrypto.so.4 #15 0x08054930 in ?? () #16 0x0a04fb48 in ?? () #17 0x000a in ?? () #18 0xbfffd148 in ?? () #19 0x00ff6240 in _IO_wide_data_2 () from /lib/tls/libc.so.6 #20 0x00cf11ec in _rtld_local () from /lib/ld-linux.so.2 #21 0x00cf1d90 in ?? () #22 0x00cf11ec in _rtld_local () from /lib/ld-linux.so.2 #23 0x00cf11ec in _rtld_local () from /lib/ld-linux.so.2 #24 0x00ed3084 in ?? () from /lib/tls/libc.so.6 #25 0x00ed44f8 in ?? () from /lib/tls/libc.so.6 #26 0x in ?? () [ pk7out operation ] $ gdb openssl corefile ... Core was generated by `/usr/bin/openssl smime -pk7out -in entity.decrypt -inform SMIME'. Program terminated with signal 11, Segmentation fault. ... (gdb) where #0 0x0037e4ec in memcpy () from /lib/tls/libc.so.6 #1 0x0027f1a1 in BIO_new_mem_buf () from /lib/libcrypto.so.4 #2 0x0027e136 in BIO_write () from /lib/libcrypto.so.4 #3 0x002cb4cd in SMIME_text () from /lib/libcrypto.so.4 #4 0x002cae5d in SMIME_read_PKCS7 () from /lib/libcrypto.so.4 #5 0x08082302 in msg_cb () #6 0x08054bbc in ?? () #7 0x000a in ?? () #8 0xbfff92a8 in ?? () #9 0xbfff8d18 in ?? () #10 0x08055062 in ?? () #11 0xbfff91d0 in ?? () #12 0x08097684 in ?? () #13 0xbfff8d48 in ?? () #14 0x00286994 in lh_doall_arg () from /lib/libcrypto.so.4 #15 0x08054930 in ?? () #16 0x0a01eb48 in ?? () #17 0x000a in ?? () #18 0xbfff92a8 in ?? () #19 0x00438240 in _IO_wide_data_2 () from /lib/tls/libc.so.6 #20 0x005d71ec in _rtld_local () from /lib/ld-linux.so.2 #21 0x005d7d90 in ?? () #22 0x005d71ec in _rtld_local () from /lib/ld-linux.so.2 #23 0x005d71ec in _rtld_local () from /lib/ld-linux.so.2 #24 0x00315084 in ?? () from /lib/tls/libc.so.6 #25 0x003164f8 in ?? () from /lib/tls/libc.so.6 #26 0x in ?? ()
Re: 0.9.8b + zlib + -bugs?
On Sun, May 07, 2006 at 02:36:10PM +0200, Dr. Stephen Henson wrote: On Sat, May 06, 2006, Victor Duchovni wrote: I'll gladly test any snapshot that addresses this issue. OK, please try the next snapshot and/or this patch: http://cvs.openssl.org/chngview?cn=15251 Preliminary testing with s_client and s_server looks good, initial SSLv3/TLSv1 sessions, resumed sessions and renegotiation all work. I'll build Postfix against the modified library and report the results here, but that will likely take a few days. Thanks for looking into this, I am looking forward to seeing this issue gone with 0.9.8c. [ If it were up to me, I would push 0.9.8c out the door sooner rather than later. The more distributions ship 0.9.8[ab] with zlib support enabled, the more interoperability issues are likely to be encountered in the field with applications using SSL_OP_ALL. ] -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Improving ssl conection time
You might want to check out SSL_set_session() and friends. This will
allow your programs to reuse a session and avoid the negotiation.
On May 7, 2006, at 8:03 AM, Marco Rossi wrote:
Dear all,
I'm working with an xml messaging protocol where
messages are exchaged by means of ssl connections.
The client needs to open/close a new connection for
every message to sent (the server adopts this policy
and it is not possible to change it), so I was trying
to understand a little more on BIO_do_connect.
In the past, I used to sleep(2) on BIO_do_connect to
to waif for ssl handshake to be performed, here a
snip of code
// CTX settngs (keys, cert,...)
BIO_get_ssl(out, ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
BIO_set_nbio(out,1);
if (BIO_do_connect(out) = 0){
sleep(2);
}
However I noticed sleep(2) slows down my client
application, I got better times if I don't use sleep
and I go directly to use BIO_read and BIO_write, and
wait for the BIO to be ready using int values returned
by these functions and related macro BIO_should_read
...
bytesRead = BIO_read(out, buf, sizeof(buf));
while ( (!(bytesRead == 0)) (count NTRIES)){
if (bytesRead 0) {
if(BIO_should_read(out) || BIO_should_retry(out))
This works almost fine with SSLv3 but if I try to use
TLS 1 (server supports both) I receive too much
connection error.
Checking what is happening with ssldump I see the
handshake hangs up on ClientKeyExchange when the
master key should be already be aggred
ssldump -q
6 1 0.1293 (0.1293) CS SSLv2 compatible client
hello
6 2 0.2623 (0.1329) SC Handshake ServerHello
6 3 0.6656 (0.4032) SC Handshake Certificate
ServerKeyExchange
CertificateRequest
certificate_authority
certificate_authority
ServerHelloDone
6 4 0.6945 (0.0289) CS Handshake Certificate
6 5 0.8243 (0.1298) CS Handshake
ClientKeyExchange
How could I improve and possibly speed up ssl
connetion time in a correct manner ?
Thanks,
Marco Rossi
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
Re: 0.9.8b + zlib + -bugs?
On Sat, May 06, 2006 at 10:45:53PM -0400, Victor Duchovni wrote:
Is there any
way to determine at run-time whether the OpenSSL library is a 0.9.8[ab]
release with zlib enabled?
For Postfix 2.3 (and perhaps even a 2.2 patch at some point) I would like
to use (SSL_OP_ALL ~SSL_OP_TLS_BLOCK_PADDING_BUG) provided
OPENSSL_VERSION_NUMBER = 0x0090800fL
OPENSSL_VERSION_NUMBER = 0x0090802fL
but it would be nice to avoid this when zlib support is not compiled in.
Is there a run-time test for that?
It looks like I can call SSL_COMP_get_compression_methods(), and if I
get a non-null stack, check whether the stack depth is 0.
static void my_set_options(SSL_CTX *ctx)
{
long options = SSL_OP_ALL;
#if (OPENSSL_VERSION_NUMBER 0x0090800fL) ||
(OPENSSL_VERSION_NUMBER 0x0090802fL)
STACK_OF(SSL_COMP) *comp_methods;
comp_methods = SSL_COMP_get_compression_methods();
if (comp_methods != 0 sk_SSL_COMP_num(comp_methods) 0)
options = SSL_OP_ALL ~SSL_OP_TLS_BLOCK_PADDING_BUG;
#endif
SSL_CTX_set_options(ctx, options);
}
Does this seem sensible?
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8b + zlib + -bugs?
On Sun, May 07, 2006 at 04:28:22PM -0400, Victor Duchovni wrote:
It looks like I can call SSL_COMP_get_compression_methods(), and if I
get a non-null stack, check whether the stack depth is 0.
static void my_set_options(SSL_CTX *ctx)
{
long options = SSL_OP_ALL;
#if (OPENSSL_VERSION_NUMBER 0x0090800fL) ||
(OPENSSL_VERSION_NUMBER 0x0090802fL)
STACK_OF(SSL_COMP) *comp_methods;
comp_methods = SSL_COMP_get_compression_methods();
if (comp_methods != 0 sk_SSL_COMP_num(comp_methods) 0)
options = SSL_OP_ALL ~SSL_OP_TLS_BLOCK_PADDING_BUG;
#endif
SSL_CTX_set_options(ctx, options);
}
Does this seem sensible?
The #if ( ) || ( ) test is inverted, sorry too much on the fly
editing, but you get the idea... Is the general approach sensible?
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8b + zlib + -bugs?
On Sun, May 07, 2006, Victor Duchovni wrote:
On Sun, May 07, 2006 at 04:28:22PM -0400, Victor Duchovni wrote:
It looks like I can call SSL_COMP_get_compression_methods(), and if I
get a non-null stack, check whether the stack depth is 0.
static void my_set_options(SSL_CTX *ctx)
{
long options = SSL_OP_ALL;
#if (OPENSSL_VERSION_NUMBER 0x0090800fL) ||
(OPENSSL_VERSION_NUMBER 0x0090802fL)
STACK_OF(SSL_COMP) *comp_methods;
comp_methods = SSL_COMP_get_compression_methods();
if (comp_methods != 0 sk_SSL_COMP_num(comp_methods) 0)
options = SSL_OP_ALL ~SSL_OP_TLS_BLOCK_PADDING_BUG;
#endif
SSL_CTX_set_options(ctx, options);
}
Does this seem sensible?
The #if ( ) || ( ) test is inverted, sorry too much on the fly
editing, but you get the idea... Is the general approach sensible?
That will of course only perform the version comparison at compile time. If
OpenSSL shared libraries are updated without recomplining the source then
that might not do what you want. A runtime comparison would avoid that.
This looks like its one area which was overlooked since the SSLeay days.
Currently you have to use the function SSLeay() to get the version number at
runtime.
Some new functions with OPENSSL in them should be added.
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8b windows binaries
Mike Ehlert wrote: but what I'm after now is some information on any tricks to compiling the DLL's with only the features needed for my application to reduce their size. Typically one links to the static library then, which of course will only link in .obj files that are consumed. One bit of OpenSSL magic are the seperate objects which create a (relatively) quite small binary. That is, if you use explicit methods, e.g. use TLSV1_server_init if you will only respond with TLS, instead of SSLV23_server_init where you draw in much more conditional code. Bill __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8b + zlib + -bugs?
On Mon, May 08, 2006 at 12:04:24AM +0200, Dr. Stephen Henson wrote:
It looks like I can call SSL_COMP_get_compression_methods(), and if I
get a non-null stack, check whether the stack depth is 0.
static void my_set_options(SSL_CTX *ctx)
{
long options = SSL_OP_ALL;
#if (OPENSSL_VERSION_NUMBER 0x0090800fL) ||
(OPENSSL_VERSION_NUMBER 0x0090802fL)
STACK_OF(SSL_COMP) *comp_methods;
comp_methods = SSL_COMP_get_compression_methods();
if (comp_methods != 0 sk_SSL_COMP_num(comp_methods) 0)
options = SSL_OP_ALL ~SSL_OP_TLS_BLOCK_PADDING_BUG;
#endif
SSL_CTX_set_options(ctx, options);
}
Does this seem sensible?
The #if ( ) || ( ) test is inverted, sorry too much on the fly
editing, but you get the idea... Is the general approach sensible?
That will of course only perform the version comparison at compile time. If
OpenSSL shared libraries are updated without recomplining the source then
that might not do what you want. A runtime comparison would avoid that.
True, if I build with 0.9.8[ab], then the code will suppress the padding
bug work-around even with 0.9.8[c-z], or fail to suppress it on a regression
from 0.9.8[c-z] to 0.9.8[ab].
This looks like its one area which was overlooked since the SSLeay days.
Currently you have to use the function SSLeay() to get the version number at
runtime.
Some new functions with OPENSSL in them should be added.
Yes, indeed. Would it be appropriate for applications to check for the
same major/minor at runtime and compile time?
if ((0xF000L OPENSSL_VERSION_NUMBER) != (0xF000L SSLeay())) {
... warning or perhaps even fatal error ...
}
This would detect mismatches between headers and libraries. Usually the
library SONAME (on my system libssl.so.0.9.7) prevents run-time linking
of an incompatible library, but that too is not 100% foolproof. To date
there has been no expectation that different major.minor OpenSSL releases
will offer the same ABI.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
