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) disassemble
Dump of assembler code for function vpaes_cbc_encrypt:
...
0xb7e369f8 +184: movdqu %xmm0,(%ebx,%esi,1)
= 0xb7e369fd +189:
Please, consider this bugreport:
https://bugs.archlinux.org/task/29111
There is also:
http://bugs.debian.org/665836
Yes, looks like exact duplicate. For reference. It should be possible to
avoid vpaes by setting OPENSSL_ia32cap environment variable to
~0x200. Why x86_64 is not
Hi,
please apply the following patch to the util/cygwin.sh script to
the 0.9.8 branch, the 1.0.1 branch, and trunk.
Strange choice of branches...
The patch fixes the generated name for the runtime openssl package
on Cygwin. So far it used the version number of OpenSSL for the
package
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.
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
Hello,
I've tried to compile openssl-1.0.1 with the no-stdio option and ran
into errors..
I reproduce the problem on my linux debian (amd64), see below.
I'm attaching a patch.
$ ./config no-ssl2 no-stdio
$ make depend
$ make build_libs
...
gcc -I. -I.. -I../include -DOPENSSL_THREADS
Since `bswap' is a i486 invention, I suggest the following patch to
make the code work on i386 ( at least the tests run ok ):
--- crypto/modes/modes_lcl.h.orig 2012-01-15 14:40:21.0
+0100 +++ crypto/modes/modes_lcl.h 2012-03-29 16:27:59.0
+0200 @@ -45,7 +45,7 @@
#
Woo-hoo! Success! I was able to connect to both machines that I could not
before the patch. Thank you so much Andy!
root@hawty:/usr/src/openssl-1.0.1# ssh mi...@smtp.readq.com
ssh: /usr/src/openssl-1.0.1/libcrypto.so.1.0.0: no version information
available (required by ssh)
Enter PASSCODE:
Last
Woo-hoo! Success! I was able to connect to both machines that I could
not before the patch. Thank you so much Andy!
root@hawty:/usr/src/openssl-1.0.1# ssh mi...@smtp.readq.com
ssh: /usr/src/openssl-1.0.1/libcrypto.so.1.0.0: no version information
available (required by ssh)
Enter
Since `bswap' is a i486 invention, I suggest the following patch to
make the code work on i386 ( at least the tests run ok ):
--- crypto/modes/modes_lcl.h.orig 2012-01-15 14:40:21.0
+0100 +++ crypto/modes/modes_lcl.h2012-03-29 16:27:59.0
+0200 @@ -45,7 +45,7 @@
#
[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);
I've done some more tests and it seems that the size of the client hello
message is significant: all the options that work reduce the size of
client hello. If you use the -debug option and check out the first
message bytes 4 and 5 it seems those servers hang if the length exceeds
0xFF (using
On Sat, Mar 31, 2012 at 08:12:54PM +0200, Andy Polyakov wrote:
I've done some more tests and it seems that the size of the client hello
message is significant: all the options that work reduce the size of
client hello. If you use the -debug option and check out the first
message bytes 4
So I'm getting more and more reports of sites that have a problem
since 1.0.1. They basicly fall in 2 categories:
- They don't tolerate versions higher than TLS 1.0
- They don't like big packets.
Of the 2nd case I have at least found people complain about those
sites:
- www.facebook.com
On Sat, Mar 31, 2012, Kurt Roeckx wrote:
On Sat, Mar 31, 2012 at 08:12:54PM +0200, Andy Polyakov wrote:
I've done some more tests and it seems that the size of the client hello
message is significant: all the options that work reduce the size of
client hello. If you use the -debug
On Sat, Mar 31, 2012 at 11:09:15PM +0200, Andy Polyakov wrote:
Bugs never make sense. But what do you mean by doesn't seem to happen
here? Can you connect with 'openssl s_client -connect
www.paypal.com:443 -cipher DEFAULT:\!AES' and 'openssl s_client -connect
www.paypal.com:443 -cipher ALL'?
On Sun, Apr 01, 2012 at 12:13:44AM +0200, Dr. Stephen Henson wrote:
OpenSSL 1.0 and later will use an *SSLv3* compatible client hello provided no
SSLv2 ciphersuites are requested. The default cipherstring now excludes all
SSLv2 ciphersuites so by default you wont get SSLv2 client hellos. If
18 matches
Mail list logo
