>> http://cvs.openssl.org/chngview?cn=22334 is interim solution,
>> proper solution will be provided at later point (if found appropriate).
>
> Thanks, this circumvents the DTLS issue.
>
> The TLS empty fragments issue remains,
http://cvs.openssl.org/chngview?cn=22390
_
> http://cvs.openssl.org/chngview?cn=22334 is interim solution,
> proper solution will be provided at later point (if found appropriate).
Thanks, this circumvents the DTLS issue.
The TLS empty fragments issue remains, but this patch hints at
the cause. I think the problem is here, (s3_pkt.c, circ
> http://cvs.openssl.org/chngview?cn=22334 is interim solution,
> proper solution will be provided at later point (if found appropriate).
Thanks, this circumvents the DTLS issue.
The TLS empty fragments issue remains, but this patch hints at
the cause. I think the problem is here, (s3_pkt.c, circ
>> Please try setting the OPENSSL_ia32cap environment variable to 0 and see
>> if you still get the problem.
>
> That worked.
http://cvs.openssl.org/chngview?cn=22334 is interim solution, proper
solution will be provided at later point (if found appropriate).
___
> Please try setting the OPENSSL_ia32cap environment variable to 0 and see
> if you still get the problem.
That worked.
I added code to the test harness to show the capability flags:
OPENSSL_ia32cap=[ffeb:1fbae3ff]
I then added a command-line switch to change the flags on-the-fly.
Turning
> Please try setting the OPENSSL_ia32cap environment variable to 0 and see
> if you still get the problem.
That worked.
I added code to the test harness to show the capability flags:
OPENSSL_ia32cap=[ffeb:1fbae3ff]
I then added a command-line switch to change the flags on-the-fly.
Turning
> [john_fitzgib...@yahoo.com - Tue Apr 03 23:24:21 2012]:
>
> > Andy has made some recent fixes to the AES code too which may be
>
> > relevant. Please check the next snapshot to see if you still have
> problems.
>
> I get the same results with openssl-1.0.1-stable-SNAP-20120403.tar.gz
>
> To n
> Andy has made some recent fixes to the AES code too which may be
> relevant. Please check the next snapshot to see if you still have problems.
I get the same results with openssl-1.0.1-stable-SNAP-20120403.tar.gz
To narrow down the problem, I built the "no-asm" version, (which works),
saved of
> Andy has made some recent fixes to the AES code too which may be
> relevant. Please check the next snapshot to see if you still have problems.
I get the same results with openssl-1.0.1-stable-SNAP-20120403.tar.gz
To narrow down the problem, I built the "no-asm" version, (which works),
saved of
> [john_fitzgib...@yahoo.com - Sat Mar 31 07:50:09 2012]:
>
> This is happening because of the following, (which looks like a bug),
> in ssl/d1_srvr.c, line 923:
>
> Time=(unsigned long)time(NULL); /*
> Time */
> l2n(Time,p);
> RAND_
> 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
>> 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
> 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
>> 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
.
From: John Fitzgibbon
To: OpenSSL Response Team
Sent: Wednesday, March 28, 2012 2:29 PM
Subject: Re: [openssl.org #2778] [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 t
From: John Fitzgibbon
To: OpenSSL Response Team
Sent: Wednesday, March 28, 2012 12:42 PM
Subject: [openssl.org #2778] [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,
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
21 matches
Mail list logo
