Hi All,
I am using ssldump to tool to
check the ciphersuite used in communication between client and server with
different
ssl configurations.
SSL configuration values are
DEFAULT, LOW and HIGH. When I set to DEFAULT and LOW configuration ciphersuites
are TLS_RSA_WITH_RC4_128_MD5 and
Folks:
The buildbot for the Tahoe-LAFS project runs CPython under valgrind on
Fedora, and valgrind emits warnings like this:
==30127== Conditional jump or move depends on uninitialised value(s)
==30127==at 0x4C2AD01: bcmp (mc_replace_strmem.c:889)
==30127==by 0xC1D1646: fips_get_entropy
It seems that it misleads Qualys scanner and may cause some problems
with BEAST vulnerability. With the following ciphers enabled (in order
of preference)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
[zo...@zooko.com - Fri Mar 02 12:36:14 2012]:
If there's any interest, I could write a patch for openssl to zero out
memory before using it in the PRNG. I assume that you have discussed
that before now and decided against it, but if you want a patch that
does that, let me know.
This is
On Fri, Mar 02, 2012, Rama K. Chandra Reddi wrote:
Hi All,
I am using ssldump to tool to
check the ciphersuite used in communication between client and server with
different
ssl configurations.
SSL configuration values are
DEFAULT, LOW and HIGH. When I set to DEFAULT and LOW
DTLS maintains timers for every handshake flight in case retransmissions are
necessary. In the current implementation the timer is stopped as soon as any
message of the following flight arrived. This can lead to a deadlock, if the
flight was incomplete for some reason and the missing message is
On Fri, Mar 02, 2012, Adrian Kotelba wrote:
It seems that it misleads Qualys scanner and may cause some problems
with BEAST vulnerability. With the following ciphers enabled (in order
of preference)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
While having SSL_want_read() and SSL_want_write() return nonzero after a
permanent error is a poor interface, the documentation does state that
it is necessary to check the return of SSL_get_error().
So this ticket can be closed out as invalid.
Well, it seems that I am not able to reproduce this behavior using
s_client. Apparently, the server picks up the correct cipher RC4. Part
of connection log below:
---
No client certificate CA names sent
---
SSL handshake has read 4538 bytes and written 363 bytes
---
New, TLSv1/SSLv3, Cipher is
