query regarding printing ciphersuite value
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 TLS_RSA_WITH_DES_CBC_SHA respectively as shown by ssldump tool. But when SSL configuration set to HIGH, ssldump tool showing ciphersuite value as “Unknown value 0x2f”. I would like to know cipher suite name of “Unknown value 0x2f”__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2747] valgrind suppressions file to suppress warnings from Python/openssl
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 (fips_drbg_lib.c:166)
==30127==by 0xC1D1D6E: FIPS_drbg_instantiate (fips_drbg_lib.c:234)
==30127==by 0xC15F590: RAND_init_fips (rand_lib.c:286)
==30127==by 0xC0F54D3: OPENSSL_init_library (o_init.c:106)
==30127==by 0xBE76AF8: SSL_library_init (ssl_algs.c:68)
==30127==by 0xBC2B39D: init_hashlib (in
/usr/lib64/python2.7/lib-dynload/_hashlib.so)
==30127==by 0x4F1DB00: _PyImport_LoadDynamicModule (in
/usr/lib64/libpython2.7.so.1.0)
You can see the full output from such a buildbot run here:
https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora%20syslib/builds/58/steps/test%20valgrind/logs/valgrind
Here is information about the versions of software involved:
https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora%20syslib/builds/58/steps/show-tool-versions/logs/stdio
The owner of the buildslave machine says that the openssl package was
openssl-1.0.1-0.1.beta2.fc17.x86_64.
Not having looked closer, I assume this is just a case of using
uninitialized memory as part of the initialization of the PRNG.
Accordingly, I wrote suppressions stanzas for our valgrind
suppressions file
(https://tahoe-lafs.org/trac/pycryptopp/browser/git/misc/coding_helpers/python.supp
), which made the warnings go away.
Appended are the suppression expressions.
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.
I opened this ticket on launchpad.net to track the handling of this
issue in various projects such as openssl, pycryptopp, CPython,
valgrind, and Fedora:
https://bugs.launchpad.net/pycryptopp/+bug/944585
Regards,
Zooko
# generated on buildbot.rubenkerkhof.com, which had, according to Ruben
# Fedora's package openssl-1.0.1-0.1.beta2.fc17.x86_64
{
buildbot.rubenkerkhof.com cond fips openssl 1
Memcheck:Cond
fun:bcmp
fun:fips_get_entropy
fun:FIPS_drbg_instantiate
fun:RAND_init_fips
fun:OPENSSL_init_library
fun:SSL_library_init
fun:init_hashlib
}
{
buildbot.rubenkerkhof.com cond fips openssl 2
Memcheck:Cond
fun:fips_get_entropy
fun:FIPS_drbg_instantiate
fun:RAND_init_fips
fun:OPENSSL_init_library
fun:SSL_library_init
fun:init_hashlib
}
{
buildbot.rubenkerkhof.com val _x86_64_AES_encrypt_compact
Memcheck:Value8
fun:_x86_64_AES_encrypt_compact
fun:AES_encrypt
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0
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) TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) the server responds with TLS_RSA_WITH_AES_256_CBC_SHA when using TLS 1.0. I think that the server should respond with TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) when using TLS 1.0. I guess, the configuration of ciphers in s3_lib.c is the main reason for this behavior. Check full discussion on https://community.qualys.com/thread/9340. Adrian 2012/3/2 Dr. Stephen Henson st...@openssl.org: On Thu, Mar 01, 2012, Adrian Kotelba wrote: In s3_lib.c ciphers 0x3B to 0x40 and 0x67 to 0x6D with SHA256 are set as SSL_TLSV1. Should it be SSL_TLSV1_2? Well I've seen implementations uses them in TLS 1.0 and 1.1 and it seemed harmless to keep that. Anything not supporting them wont use them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2747] valgrind suppressions file to suppress warnings from Python/openssl
[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 an option already: try compiling OpenSSL with -DPURIFY Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: query regarding printing ciphersuite value
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 configuration ciphersuites are TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_DES_CBC_SHA respectively as shown by ssldump tool. But when SSL configuration set to HIGH, ssldump tool showing ciphersuite value as ?Unknown value 0x2f?. I would like to know cipher suite name of ?Unknown value 0x2f? If you use the -V option to the ciphers command you can see the cipher ids. In this case 0x2f is AES128-SHA Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2748] [PATCH] Possible timer deadlock with DTLS bug
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 awaited forever with no timer running anymore. This patch changes the timer behavior so that a timer is not stopped until the entire following flight has been received to avoid this issue. This is also required by the DTLS specification. Thanks to Lindani Phiri for reporting this bug! Best regards Robin dtls-timer-deadlock-bug-1.0.0.patch Description: Binary data dtls-timer-deadlock-bug-1.0.1.patch Description: Binary data
Re: Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0
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) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) the server responds with TLS_RSA_WITH_AES_256_CBC_SHA when using TLS 1.0. I think that the server should respond with TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) when using TLS 1.0. I guess, the configuration of ciphers in s3_lib.c is the main reason for this behavior. Check full discussion on https://community.qualys.com/thread/9340. I can't see why the server responds with the AES cipher instead of the RC4 one with that configuration. Can you reproduce this behaviour using s_server and s_client? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2740] AutoReply: infinite loop in nonblocking SSL_shutdown() upon permanent error
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. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0
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 ECDHE-RSA-RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: ECDHE-RSA-RC4-SHA It could be the problem of Qualys scanner or yet something else. Adrian 2012/3/2 Dr. Stephen Henson st...@openssl.org: 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) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) the server responds with TLS_RSA_WITH_AES_256_CBC_SHA when using TLS 1.0. I think that the server should respond with TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) when using TLS 1.0. I guess, the configuration of ciphers in s3_lib.c is the main reason for this behavior. Check full discussion on https://community.qualys.com/thread/9340. I can't see why the server responds with the AES cipher instead of the RC4 one with that configuration. Can you reproduce this behaviour using s_server and s_client? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
