Re: DSO_load using DSO_method_dlfcn
On Mon, 2008-10-13 at 22:11 -0400, Geoff Thorpe wrote: What's the relation between this patch and the original poster's question? I suspect that I haven't fully understood what your patch is trying to resolve. The question was 'how to load a DSO from within an engine'. That patch just highlights some existing, functional code which loads a DSO from within an external engine (the openssl_tpm_engine, from the Trousers project). It highlights that code by disabling it, but in doing so it does show where to look. The problem I was trying to resolve, in that particular case, was that the engine _was_ using DSO_load() and I didn't want it to. The opposite of the original poster's problem :) -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1703] Bug report for DTLS
David Woodhouse wrote: On Mon, 2008-10-13 at 09:01 +0200, Lutz Jaenicke via RT wrote: Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling is not present in HEAD (0.9.9). That makes sense. I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the pre-RFC version of DTLS was considered to be an OpenSSL-specific thing that would quickly die out as people upgraded to 0.9.8f and beyond? Now we've observed that there are servers in the wild which implement that old OpenSSL-specific version of the protocol, but which we'd like to be compatible with. If I can actually get that working in HEAD, would a patch to support it be acceptable? I had a deeper look into the mailing list archive and I did not find any explicit statement on why this was handed differently in 0.9.8 and in HEAD. Finally we would of course prefer to move people to update to an RFC compliant version, so I guess the pre-RFC support should be configurable somehow. Andy, what do you think? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[PATCH] DTLS renegotiation bug #1647
As described in bug report #1647 both server and client are hanging when calling SSL_renegotiate() with DTLS. The client sends the ClientHello to the server, but the message sequence number has not been reset to 0 after the first handshake. So the server drops it (out of sync) and continues waiting for the ClientHello while the client is waiting for the server's response. The following patch resets the message sequence number to 0 after finishing a handshake and thus fixes this bug for OpenSSL 0.9.8i. Regards, Robin --- ssl/d1_clnt.c~ 2008-06-04 20:35:25.0 +0200 +++ ssl/d1_clnt.c 2008-10-14 13:24:09.0 +0200 @@ -492,6 +492,7 @@ /* done with handshaking */ s-d1-handshake_read_seq = 0; + s-d1-next_handshake_write_seq = 0; goto end; /* break; */ --- ssl/d1_srvr.c~ 2008-09-14 16:02:01.0 +0200 +++ ssl/d1_srvr.c 2008-10-14 13:24:01.0 +0200 @@ -554,6 +554,7 @@ s-d1-handshake_read_seq = 0; /* next message is server hello */ s-d1-handshake_write_seq = 0; + s-d1-next_handshake_write_seq = 0; goto end; /* break; */ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1647] [PATCH] DTLS renegotiation bug #1647
As described in bug report #1647 both server and client are hanging when calling SSL_renegotiate() with DTLS. The client sends the ClientHello to the server, but the message sequence number has not been reset to 0 after the first handshake. So the server drops it (out of sync) and continues waiting for the ClientHello while the client is waiting for the server's response. The following patch resets the message sequence number to 0 after finishing a handshake and thus fixes this bug for OpenSSL 0.9.8i. Regards, Robin --- ssl/d1_clnt.c~ 2008-06-04 20:35:25.0 +0200 +++ ssl/d1_clnt.c 2008-10-14 13:24:09.0 +0200 @@ -492,6 +492,7 @@ /* done with handshaking */ s-d1-handshake_read_seq = 0; + s-d1-next_handshake_write_seq = 0; goto end; /* break; */ --- ssl/d1_srvr.c~ 2008-09-14 16:02:01.0 +0200 +++ ssl/d1_srvr.c 2008-10-14 13:24:01.0 +0200 @@ -554,6 +554,7 @@ s-d1-handshake_read_seq = 0; /* next message is server hello */ s-d1-handshake_write_seq = 0; + s-d1-next_handshake_write_seq = 0; goto end; /* break; */ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
question regarding ./config no-idea no-mdc2 no-rc5
Hi There, I am building a web service client application that uses openSSL for web service https/SSL communication. In order to avoid the patent issue for the portion of openSSL, I build the openSSL libraries myself using ./config no-idea no-mdc2 no-rc5. All is working fine as far as I am concerned, my client application can talk to web service server through https. Now my question is: What cypto algorithm is actually used in the https/SSL communication? What is really turned off by using no-idea no-mdc2 no-rc5? If these things are not needed, then why they are there? Thanks much! Ray __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
