[openssl.org #3109] [openssl.org #3041[PATCH] DTLS message_sequence number wrong in rehandshake ServerHello
This patch ensures that * A HelloRequest is retransmitted if not responded by a ClientHello * The HelloRequest consumes the sequence number 0. The subsequent ServerHello uses the sequence number 1. * The client also expects the sequence number of the ServerHello to be 1 if a HelloRequest was received earlier. This patch fixes the RFC violation. This patch should be applied to 1.0.1, 1.0.0 and 0.9.8. renegotiate.patch Description: Binary data
[openssl.org #3041][PATCH] DTLS message_sequence number wrong in rehandshake ServerHello
This patch ensures that * A HelloRequest is retransmitted if not responded by a ClientHello * The HelloRequest consumes the sequence number 0. The subsequent ServerHello uses the sequence number 1. * The client also expects the sequence number of the ServerHello to be 1 if a HelloRequest was received earlier. This patch fixes the RFC violation. This patch should be applied to 1.0.1, 1.0.0 and 0.9.8. renegotiate.patch Description: Binary data
Re: [openssl.org #3109] AutoReply: [openssl.org #3041[PATCH] DTLS message_sequence number wrong in rehandshake ServerHello
On Aug 11, 2013, at 3:33 PM, The default queue via RT r...@openssl.org wrote: Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: [openssl.org #3041[PATCH] DTLS message_sequence number wrong in rehandshake ServerHello , a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #3109]. Please include the string: [openssl.org #3109] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. It is a response to [openssl.org #304], so I'll resend the message correctly. You can close this ticket. Sorry for the inconvenience. Best regards Michael Thank you, r...@openssl.org - This patch ensures that * A HelloRequest is retransmitted if not responded by a ClientHello * The HelloRequest consumes the sequence number 0. The subsequent ServerHello uses the sequence number 1. * The client also expects the sequence number of the ServerHello to be 1 if a HelloRequest was received earlier. This patch fixes the RFC violation. This patch should be applied to 1.0.1, 1.0.0 and 0.9.8. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
bsdmake mystery
I'm trying to figure out why bsdmake on MacOS does this using the standard Makefiles: cc -c -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED -Wno-language-extension-token -Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int -Wall -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 -c -o x86_64cpuid.o x86_64cpuid.s but does this when using the single makefile: as -o tmp.master/x86_64cpuid.o tmp.master/x86_64cpuid.s anyone got any ideas? Its driving me crazy (and stops the single makefile from working on macos). AFAICS, both routes should use a .s.o rule which invokes as, so ... wtf? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
On the concurrent use of SSL_write and SSL_read
Hello there, It has been understood that the concurrent use of SSL_write and SSL_read is dangerous. However, is it correct to assume that the only crossing between these two APIs happen at the handshake stage only ? In other terms, once the SSL handshake stage has been completed, is it safe to use these two APIs concurrently ? In our server application, we integrated OpenSSL and so far could not see any issue related to the concurrent use of these two APIs. We even setup a test in which we send/receive many messages that we sort of sign by means of hashing, then we ensured that the data we get in other end is correct. We are afraid that this is just luck. And we appreciate a lot if some expert can validate or not our above claim, since the examination of the source code of OpenSSL has been very difficult. Below is the details of how we are doing things: 1. First of all we are doing our own socket IO, so we are using two BIOs. 2. Once we have new incoming data, we write that into the input BIO then call SSL_read to get the decryption result 3. Once we are ready to send some outgoing data, we call SSL_write, then read the encryption result from the output BIO before sending it to the network. 4. 2. and 3. can happen simultaneously leading to the concurrent call to SSL_write/SSL_read 5. 4. is only true once the connection has finished the handshake stage. 6. If the connection is still at handshake stage, what we only do is react to incoming data: if some data comes, we do like in 2. but then expect the output BIO to have been filled with some outgoing data which we send to client. This continues till the handshake has finished. Thank you for any possible advise and help.
