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. I
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
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 t
>>> 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:
>
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
> >>> mes
>>> 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
>>
> [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_
> 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 @@
> 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 PA
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
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 @@
# defi
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 -D_REENTRANT
> 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
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
>> 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
> 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)
> => 0xb7e369f
18 matches
Mail list logo
