> 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
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
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
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
> (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.
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
> 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
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
>> 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
> [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
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
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.
_
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
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
14 matches
Mail list logo