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
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:
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.
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
[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 version of
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 are 1.0.
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
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
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
(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.s:647
#1
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
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
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) DTLS test
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=(unsigned
14 matches
Mail list logo
