Re: Question on DTLS server calling dtls_handle_timeout during protocol handshake.
On Jun 27, 2011, at 11:02 PM, Robin Seggelmann wrote: Hi Yogesh, Yes, I noticed that after I wrote the mail. The server starts a timer after sending the HelloVerifyRequest, although it's not supposed to. A patch is submitted already, but has not yet appeared on the OpenSSL request tracker. In the meantime the patch is available from http://sctp.fh-muenster.de/dtls-patches.html Best regards Michael Best regards Robin On 27.06.2011, at 22:58, Yogesh Chopra wrote: Hi, Please look at the debug messages attached to the original message, These were printf's added in the DTLS code and these were messages captured on the server. We are seeing the server start a timer when it sends back a HelloVerifyRequest. Based on your comments below it appears that should not be the case but we do see the timer getting invoked on the server in contrast to expected behavior. Thanks, -Yogi On Mon, Jun 27, 2011 at 1:15 AM, Robin Seggelmann seggelm...@fh-muenster.de wrote: Hi Yogesh, I'm not sure what your problem is. If you drop all messages sent by the server, then the client keeps repeating its ClientHello until max retransmissions is reached, that is 12 times. The client starts a timer for every ClientHello it sends, and if it expires because there is no HelloVerifyRequest, it will retransmit and double the timer value. The server, however, never starts any timer or performs any retransmission in this scenario. The HelloVerifyRequest is sent as an immediate response to a ClientHello, with no changes in the server's state. This is done to prevent several attacks, which would be possible otherwise. The client has to sent its ClientHello again with the cookie data from the HelloVerifyRequest attached, before the server sends its ServerHello, for which a timer is started. Best regards Robin On Jun 23, 2011, at 3:50 AM, Yogesh Chopra wrote: Hi, We are using DTLS API to implement a DTLS Client/Server. We notice when the client application uses dtls_handle_timeout to re-transmit handshake messages. The DTLS server library seems to be invoking dtls_handle_timeout for every CLIENT HELLO message. In order to conduct some network connectivity tests, we have disbaled all network traffic to reach from Server to Client. i.e The Client sends CLIENT HELLO, Server responds with HELLO VERIFY REQUEST but this never reaches the client by using a firewall rule between client/server disabling all server responses to reach the client. A handshake in progress looks as follows: CLIENT - CLIENT HELLO DTLS Server library calls dtls_handle_timeout (1 sec timeout) SERVER - HELLO VERIFY REQUEST There is a packet drop on the network layer so NO server traffic reaches the client. This leads to client sending a CLIENT HELLO protocol message again (As the DTLS client application is invoking dtls_handle_timeout when timeout expires) So client repeats: CLIENT - CLIENT HELLO DTLS Server library calls dtls_handle_timeout (~2 sec) SERVER - HELLO VERIFY REQUEST CLIENT - CLIENT HELLO DTLS Server library calls dtls_handle_timeout (~4 sec) SERVER - HELLO VERIFY REQUEST CLIENT - CLIENT HELLO DTLS Server library calls dtls_handle_timeout (8~ sec) SERVER - HELLO VERIFY REQUEST CLIENT - CLIENT HELLO DTLS Server library calls dtls_handle_timeout (16~ sec) SERVER - HELLO VERIFY REQUEST CLIENT - CLIENT HELLO DTLS Server library calls dtls_handle_timeout (32~ sec) SERVER - HELLO VERIFY REQUEST CLIENT - CLIENT HELLO DTLS Server library calls dtls_handle_timeout (60~ sec) SERVER - HELLO VERIFY REQUEST Say the CLIENT HELLO comes before 60 seconds, The DTLS server does not reply with a HELLO VERIFY REQUEST before 60 seconds and connection does not get established (Even though we allow the traffic from Server to reach the client). Should the DTLS Server library even start any timers before the CLIENT HELLO verification is successful. As per post below: http://www.mail-archive.com/openssl-dev@openssl.org/msg28844.html We see in d1_pkt.c/dtls1_read_bytes /* Check for timeout */ if (dtls1_handle_timeout(s) 0) goto start; and have seen handle_timeouts being called during the connection handshake. It appears the Server does not respond until timer has expired. (test excerpt) (10.4.0.80 is Client 10.4.0.87 is Server) 6:34:43.051411 IP 10.4.0.80.34071 10.4.0.87.: UDP, length 154 (CLIENT HELLO) (0x93f4008) dtls_get_timeout timeleft expired = 0 0
Re: [PATCH] cfi/fpo directives in md5 assembly code
On Mon, Jun 27, 2011 at 22:20, Wim Lewis w...@omnigroup.com wrote: On 27 Jun 2011, at 9:27 AM, yoni londner wrote: As you know, on 32bit systems, when using EBP for anything other than holding the stack base, it is very difficult to get reasonable backtrace. this can be fixed if directing the compiler to add a debug record which tells (at runtime) where we keep EBP value. So, I added this record (FPO in ml.exe and cfi in gcc), and now we can debug/get backtrace at runtime. I also fixed source file name, so gdb find's it. Patch is attached (against openssl-1.0.0d.tar.gz), and I hope you will merge it to trunk. This seems like a good thing to fix. I have some questions/comments: 1. Would it be better to use .cfi_startproc simple? The GAS documentation doesn't actually say what opcodes are emitted by cfi_startproc vs. simple (and I haven't taken the time to check), but I'd expect a frameless leaf procedure like this one not to want the default opcodes emitted for a normal procedure. I could be wrong. 2. We could add .cfi_offset directives for the other callee-saved registers as well (EBX, ESI, EDI). 1. I looked at a generated assembler from gcc. So I am not 100% sure what is the 'most correct', but this is what gcc emits. 2. This is possible, but the frame is the most important. I didn't see those additional registers being a problem when debugging (the debugger may be incorrect about values of local variables in parent function). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Build Error on 1.0.1 with FIPS
All, I'm having a problem when building OpenSSL 1.0.1 along with fips-2.0. My layout is like this: /home/tyrel/openssl-test/openssl -- contains the 1.0.1 branch from CVS /home/tyrel/openssl-test/fips -- contains the extract fips-2.0 snapshot tarball My build steps are (from the openssl-test dir): cd fips ./config no-asm no-hw --prefix=/home/tyrel/openssl-test/dep make make install cd .. cd openssl export FIPSDIR=/home/tyrel/openssl-test/dep export FIPSLIBDIR=/home/tyrel/openssl-test/dep/lib ./config fips no-asm no-hw --prefix=/home/tyrel/openssl-test/dep make depend make make install The config script indicated that I should run make depend because you've disabled or enabled at least one algorithm. But make depend is the step that is failing. Log is below. It's worth noting that even though make depend fails, I can run make just fine. Is make depend even necessary, then, in this case? Also this failure only seems to be happening the last week or so, I think. So it may be related to a recent change in CVS. My coworkers are seeing the same thing on their boxes. Any thoughts? Here's the log: make[2]: Entering directory `/home/tyrel/openssl-test/openssl/crypto/hmac' ../../util/domd ../.. -MD gcc -- -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -I/home/tyrel/openssl-test/dep/include -I.. -I../.. -I../asn1 -I../evp -I../../include -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP224_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_STORE -- hmac.c hm_ameth.c hm_pmeth.c In file included from hm_pmeth.c:64: ../evp/evp_locl.h:355:1: error: SHA1_Init redefined In file included from /home/tyrel/openssl-test/dep/include/openssl/crypto.h:151, from ../cryptlib.h:72, from hm_pmeth.c:59: /home/tyrel/openssl-test/dep/include/openssl/fipssyms.h:456:1: error: this is the location of the previous definition In file included from hm_pmeth.c:64: ../evp/evp_locl.h:356:1: error: SHA224_Init redefined In file included from /home/tyrel/openssl-test/dep/include/openssl/crypto.h:151, from ../cryptlib.h:72, from hm_pmeth.c:59: /home/tyrel/openssl-test/dep/include/openssl/fipssyms.h:462:1: error: this is the location of the previous definition In file included from hm_pmeth.c:64: ../evp/evp_locl.h:357:1: error: SHA256_Init redefined In file included from /home/tyrel/openssl-test/dep/include/openssl/crypto.h:151, from ../cryptlib.h:72, from hm_pmeth.c:59: /home/tyrel/openssl-test/dep/include/openssl/fipssyms.h:465:1: error: this is the location of the previous definition In file included from hm_pmeth.c:64: ../evp/evp_locl.h:358:1: error: SHA384_Init redefined In file included from /home/tyrel/openssl-test/dep/include/openssl/crypto.h:151, from ../cryptlib.h:72, from hm_pmeth.c:59: /home/tyrel/openssl-test/dep/include/openssl/fipssyms.h:471:1: error: this is the location of the previous definition In file included from hm_pmeth.c:64: ../evp/evp_locl.h:359:1: error: SHA512_Init redefined In file included from /home/tyrel/openssl-test/dep/include/openssl/crypto.h:151, from ../cryptlib.h:72, from hm_pmeth.c:59: /home/tyrel/openssl-test/dep/include/openssl/fipssyms.h:474:1: error: this is the location of the previous definition In file included from hm_pmeth.c:64: ../evp/evp_locl.h:367:1: error: DES_set_key_unchecked redefined In file included from /home/tyrel/openssl-test/dep/include/openssl/crypto.h:151, from ../cryptlib.h:72, from hm_pmeth.c:59: /home/tyrel/openssl-test/dep/include/openssl/fipssyms.h:254:1: error: this is the location of the previous definition make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/tyrel/openssl-test/openssl/crypto/hmac' make[1]: *** [depend] Error 1 make[1]: Leaving directory `/home/tyrel/openssl-test/openssl/crypto' make: *** [depend] Error 1 Thanks, Tyrel __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Build Error on 1.0.1 with FIPS
On Tue, Jun 28, 2011, Tyrel Haveman wrote: All, I'm having a problem when building OpenSSL 1.0.1 along with fips-2.0. My layout is like this: /home/tyrel/openssl-test/openssl -- contains the 1.0.1 branch from CVS /home/tyrel/openssl-test/fips -- contains the extract fips-2.0 snapshot tarball My build steps are (from the openssl-test dir): cd fips ./config no-asm no-hw --prefix=/home/tyrel/openssl-test/dep make make install cd .. cd openssl export FIPSDIR=/home/tyrel/openssl-test/dep export FIPSLIBDIR=/home/tyrel/openssl-test/dep/lib ./config fips no-asm no-hw --prefix=/home/tyrel/openssl-test/dep make depend make make install The config script indicated that I should run make depend because you've disabled or enabled at least one algorithm. But make depend is the step that is failing. Log is below. It's worth noting that even though make depend fails, I can run make just fine. Is make depend even necessary, then, in this case? You don't need to run make depend. Also the steps you use above should be changed. Set FIPSDIR only and no other environment variables before you even build the test 2.0 module. You can only do: ./config make make install for the FIPS test 2.0 module build. No other options are permitted. In the past no-asm was permitted but this time no one has (so far) sponsored the C only build. For the FIPS capable build you can include additional options but don't set --prefix in the FIPS capable build to the same directory as FIPSDIR. The test 2.0 module and the FIPS capable OpenSSL should go in different places. You can skip make depend. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] cfi/fpo directives in md5 assembly code
On 28 Jun 2011, at 12:21 AM, yoni londner wrote:
1. I looked at a generated assembler from gcc. So I am not 100% sure what is
the 'most correct', but this is what gcc emits.
I was concerned that since this routine isn't compiler-generated it might be
doing something different from what .cfi_startproc was designed for. However, I
checked gas's behavior and the non-simple seems to be the right one after
all: it sets up the CFA in the normal place, located through the stack pointer,
and defines the return address's location relative to that. (Simple emits no
opcodes at all.)
2. This is possible, but the frame is the most important.
I agree entirely, but why not fix the other registers while we're at it? I've
attached a version of your diff with the extra registers' unwind info added---
untested, unfortunately--- it'll also need a
sub ::cfi_restore { ::emit(.cfi_restore,@_); }
in x86gas.pl and the corresponding stub for MASM.
Several of the other assembly files could use the same treatment as well:
md5-x86_64.pl uses %rbp to point to one of its arguments, sha1-586.pl uses %ebp
as a scratch register, etc.
cfi_fpo_2.diff
Description: Binary data
