Don't know if this is related or not, but I'm also running a very similar test that uses TLS instead of DTLS, (same scenario, OpenSSL 1.0.1 with 1.0.0 Cipher Suites selected). That works fine, except that the 64 bit version of the test looks like it doesn't include the "Empty Fragments" security countermeasure, (at least the telltale 32 byte record at the start of each packet isn't there).
My config command is the same for 32/64 bits: ./config --prefix=../../ssl --openssldir=../../ssl/openssl no-threads no-shared no-sse2 no-idea no-mdc2 no-rc5 $NO_HEARTBEATS ... where NO_HEARTBEATS="no-heartbeats" for OpenSSL 1.0.1 only, (option didn't exist for 1.0.0). My understanding was that the "Empty Fragments" countermeasure should be "on" by default for both builds?? ________________________________ From: John Fitzgibbon <john_fitzgib...@yahoo.com> To: OpenSSL Response Team <r...@openssl.org> Sent: Wednesday, March 28, 2012 2:37 PM Subject: Re: [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0 Geez, not my best day... this *is* still a problem. I forgot to reset my test cases to use the 1.0.0 list of Cipher Suites. The alignment bug had nothing whatsoever to do with this particular OpenSSL failure, and it still fails even with my now-squeaky-clean test harness. ________________________________ From: John Fitzgibbon <john_fitzgib...@yahoo.com> To: OpenSSL Response Team <r...@openssl.org> Sent: Wednesday, March 28, 2012 2:29 PM Subject: Re: [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0 Never mind... found a 64 bit memory alignment error in the test harness. I'm not entirely clear how/why the alignment problem was impacting OpenSSL, but with that bug fixed, the DTLS problem goes away. Apologies for the false alarm, John Fitzgibbon ________________________________ From: John Fitzgibbon <john_fitzgib...@yahoo.com> To: OpenSSL Response Team <r...@openssl.org> Sent: Wednesday, March 28, 2012 12:42 PM Subject: [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0 Hi, I'm trying to run a simple DTLS client/server test using OpenSSL 1.0.1, but with the same Cipher Suites that OpenSSL 1.0.0 uses, (to compare the two handshakes). This works fine with a 32 bit, (i686), build, but fails on 64 bit, (x86_64) with the following error: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0 If I do *not* override the default Cipher Suites, the 64 bit test works. I've attached packet captures from the various tests: dtls-assert-fail-x86_64.pcap -- failing handshake, (64 bit OpenSSL 1.0.1, using 1.0.0 Ciphers) dtls-assert-ok-i686.pcap -- working handshake, (32 bit OpenSSL 1.0.1, using 1.0.0 Ciphers) dtls-assert-ok-x86_64.pcap -- working handshake, (64 bit OpenSSL 1.0.1, using 1.0.1 Ciphers) Looking at the working/failing x86_64 pcaps, the MD differs for the chosen suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (works) vs. TLS_RSA_WITH_AES_256_CBC_SHA (fails) My OpenSSL 1.0.1 code is built from the original sources, and linked directly into a test harness, with patches/overrides for the following: 1) The random number generator is controlled by the test harness 2) Time-of-day is controlled by the test harness 3) Memory allocation/freeing is handled by the test harness The 64 bit code is built on Fedora 16 using: gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) I'd be interested to hear if other people experience the same problem with OpenSSL 1.0.1 x86_64 DTLS using TLS_RSA_WITH_AES_256_CBC_SHA, (or am I on my own here). Thanks, John Fitzgibbon
Don't know if this is related or not, but I'm also running a very similar test that uses TLS instead of DTLS, (same scenario, OpenSSL 1.0.1 with 1.0.0 Cipher Suites selected). That works fine, except that the 64 bit version of the test looks like it doesn't include the "Empty Fragments" security countermeasure, (at least the telltale 32 byte record at the start of each packet isn't there).
My config command is the same for 32/64 bits:
./config --prefix=../../ssl --openssldir=../../ssl/openssl no-threads no-shared no-sse2 no-idea no-mdc2 no-rc5 $NO_HEARTBEATS
... where NO_HEARTBEATS="no-heartbeats" for OpenSSL 1.0.1 only, (option didn't exist for
1.0.0).
My understanding was that the "Empty Fragments" countermeasure should be "on" by default for both builds??
From: John Fitzgibbon <john_fitzgib...@yahoo.com>
To: OpenSSL Response Team <r...@openssl.org>
Sent: Wednesday, March 28, 2012 2:37 PM
Subject: Re: [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0
Geez, not my best day... this *is* still a problem. I forgot to reset my test cases to use the 1.0.0 list of Cipher Suites. The alignment bug had nothing whatsoever to do with this particular OpenSSL failure, and it still fails even with my now-squeaky-clean test harness.
From: John Fitzgibbon <john_fitzgib...@yahoo.com>
To: OpenSSL Response Team <r...@openssl.org>
Sent: Wednesday, March 28, 2012 2:29 PM
Subject: Re: [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0
Never mind... found a 64 bit memory alignment error in the test harness. I'm not entirely clear how/why the alignment problem was impacting OpenSSL, but with that bug fixed, the DTLS problem goes away.
Apologies for the false alarm,
John Fitzgibbon
From: John Fitzgibbon <john_fitzgib...@yahoo.com>
To: OpenSSL Response Team <r...@openssl.org>
Sent: Wednesday, March 28, 2012 12:42 PM
Subject: [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0
Hi,
I'm trying to run a simple DTLS client/server test using OpenSSL 1.0.1, but with the same Cipher Suites that OpenSSL 1.0.0 uses, (to compare the two handshakes). This works fine with a 32 bit, (i686), build, but fails on 64 bit, (x86_64) with the following error:
If I do *not* override the default Cipher Suites, the 64 bit test works.
I've attached packet captures from the various tests:
dtls-assert-fail-x86_64.pcap -- failing handshake, (64 bit OpenSSL 1.0.1, using 1.0.0 Ciphers)
dtls-assert-ok-i686.pcap -- working handshake, (32 bit OpenSSL 1.0.1, using 1.0.0 Ciphers)
dtls-assert-ok-x86_64.pcap -- working handshake, (64 bit OpenSSL 1.0.1, using 1.0.1 Ciphers)
Looking at the working/failing x86_64 pcaps, the MD differs for the chosen suite:
TLS_RSA_WITH_AES_256_CBC_SHA256 (works)
vs.
TLS_RSA_WITH_AES_256_CBC_SHA (fails)
My OpenSSL 1.0.1 code is built from the original sources, and linked directly into a test harness, with patches/overrides for the following:
1) The random number generator is controlled by the test harness
2) Time-of-day is controlled by the test harness
3) Memory allocation/freeing is handled by the test harness
The 64 bit code is built on Fedora 16 using:
gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC)
I'd be interested to hear if other people experience the same problem with OpenSSL 1.0.1 x86_64 DTLS using TLS_RSA_WITH_AES_256_CBC_SHA, (or am I on my own here).
Thanks,
John Fitzgibbon
