Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread John Fitzgibbon via RT
> DTLS test "works", but the "random bytes" field differs in the server hello. > There should be > no difference because the test harness is supplying a non-random PRNG. This is happening because of the following, (which looks like a bug), in ssl/d1_srvr.c, line 923:     Time=(unsig

Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread John Fitzgibbon via RT
Some interesting observations: 1) Changed the cipher lists to much simpler values: ciphers = "AES256-SHA256"   => works ciphers = "AES256-SHA"   => fails 2) On a hunch, I tried adding "no-asm" to the config line:  2.1) TLS test now works and yields a perfect match with the 32 bit test   2.2) DTL

Re: [openssl.org #2775] [openssh 5.9p1-8] Segmentation fault libcrypto.so.1.0.0

2012-03-30 Thread Kurt Roeckx
On Wed, Mar 28, 2012 at 10:34:49AM +0200, Joe Bew via RT wrote: > Please, consider this bugreport: > > https://bugs.archlinux.org/task/29111 There is also: http://bugs.debian.org/665836 Kurt __ OpenSSL Project

[openssl.org #2775]

2012-03-30 Thread Mike Russo via RT
Well I executed this right after the 'where' from last time (still had it up in a window though the connection has long since timed out): (gdb) info reg eax0x0 0 ecx0xb7e35f90 -1209835632 edx0x80084ae8 -2146940184 ebx0x3018 12312 esp

Re: [openssl.org #2775] Segmentation fault libcrypto.so.1.0.0

2012-03-30 Thread Andy Polyakov via RT
> (gdb) continue 100 > Will ignore next 99 crossings of breakpoint 1. Continuing. > Hardware watchpoint 2: *((int *)(-2146940184+240)) > > Old value = 9 > New value = 915002721 > vpaes_cbc_encrypt () at vpaes-x86.s:647 > 647in vpaes-x86.s > (gdb) where > #0 vpaes_cbc_encrypt () at vpaes-x86.

[openssl.org #2775] Segmentation fault libcrypto.so.1.0.0

2012-03-30 Thread Mike Russo via RT
Damn, I knew I should have taken that assembly language course all those years ago. And yes, it does appear that it's only "old" versions of SSH that I'm having a problem connecting to (eg OpenSSH_3.6.1p2 w/ OpenSSL 0.9.7f, another host running 4.3p2 and 0.9.8e is fine). Well I set the breakpo

Re: [openssl.org #2775] Additional information for openssh segfault

2012-03-30 Thread Andy Polyakov via RT
> I too am experiencing a segfault in openssh when connecting to a > particular Linux host. So you mean you can login to say 2-3-4-5 other hosts, but not one specific. Tough break... > This did work fine with the previous version > of libssl (I'm running Ubuntu 12.04 so this was 1.0.0 before > up

[openssl.org #2775] Additional information for openssh segfault

2012-03-30 Thread Mike Russo via RT
I too am experiencing a segfault in openssh when connecting to a particular Linux host. This did work fine with the previous version of libssl (I'm running Ubuntu 12.04 so this was 1.0.0 before upgrading to 1.0.1). No core file is created but I can do the gdb backtrace and disassemble. You've c

Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread John Fitzgibbon via RT
>> the 64 bit version of the test looks like it doesn't include >> the "Empty Fragments" security countermeasure > > If you're using TLS v1.1 or 1.2 then you shouldn't encounter empty > fragments on any version as they are not required any more as CBC mode > includes an explicit IV. The TLS tests

[openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread Stephen Henson via RT
> [john_fitzgib...@yahoo.com - Fri Mar 30 09:21:50 2012]: > > 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 versi

Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread John Fitzgibbon via RT
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

Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread John Fitzgibbon via RT
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. _

Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread John Fitzgibbon via RT
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

[openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0

2012-03-30 Thread John Fitzgibbon via RT
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 inte