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
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
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
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
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
