Now we’re talking. Thank you Jay Foster. SSL_get_version() call does show what I expect given a variety of combinations of capabilities of the peers communicating. Examples:
Ø It shows “TLSv1” where the server has disabled SSLv3, and the client is too old to support TLSv1.2, using, for example, DHE-RSA-AES128-SHA Ø It show “TLSV1.2” when both the server and client have disabled SSLv3, and the cipher suite is, for example, DHE-RSA-AES128-GCM-SHA256 Having now understood this part (using the correct function to print the protocol version): once I turn off SSLv3, TLSv1 and TLSv1.1, and THEN try to connect with an old client (using 0.9.8r), I now get the ‘unknown protocol’ message I expect. Thanks to all who contributed to this thread. I hope Pradeep got the answer he needed (since he started this in the first place). Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jay Foster Sent: Friday, October 24, 2014 1:43 PM To: openssl-users@openssl.org Subject: Re: openssl SSL3 vulnerability There seems to be a difference between the SSL (protocol) version and the Cipher version/description. You might try the following debug code to clarify. printf("SSL Version : %s\n", SSL_get_version(ssl)); const SSL_CIPHER *ciph = SSL_get_current_cipher(ssl); if (ciph) { printf("Cipher Version : %s\n", SSL_CIPHER_get_version(ciph)); printf("Cipher Name : %s\n", SSL_CIPHER_get_name(ciph)); } For example: SSL Version : TLSv1 Cipher Version : TLSv1/SSLv3 Cipher Name : AES256-SHA From the SSL_CIPHER_get_name(3) man page: SSL_CIPHER_get_version() returns string which indicates the SSL/TLS protocol version that first defined the cipher. This is currently SSLv2 or TLSv1/SSLv3. In some cases it should possibly return ``TLSv1.2'' but does not; use SSL_CIPHER_description() instead. Jay On 10/24/2014 10:16 AM, mclellan, dave wrote: The plot thickens, but our mails must be crossing. I do indeed see TLSV1.2 in that message, but if and only if a much more restrictive set of ciphers is specified. That's why I was questioning the appearance of SSLv3 in other cases, despite the case that I had set the options to disable SSLv3. +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com<mailto:dave.mclel...@emc.com> +-+-+-+-+-+-+-+-+- -----Original Message----- From: owner-openssl-us...@openssl.org<mailto:owner-openssl-us...@openssl.org> [mailto:owner-openssl-us...@openssl.org] On Behalf Of Erik Forsberg Sent: Friday, October 24, 2014 12:46 PM To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> Subject: Re: openssl SSL3 vulnerability That triggers my memory. I saw this too a long time ago, if I recall correctly, if you get a TLSv1.2 connection, its still logged as SSLv3 (there is lack of printable enums in the OpenSSL code. I looked at my negotiation with wireshark and saw that I got TLSv1.2 despite what the debug trace said. I hope this could be fixed one day ? -- Original Message -- On 24/10/2014 15:53, Pradeep Gudepu wrote: To my earlier code, I have added these extra flags for client: SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3); And server also has these same flags set, so that no way client and server can communicate on sslv2, sslv3. But again in logs I see SSL3 is negotiated: [2014-10-24 18:00:17.063, Info < proxysrv:10684>] SSLConfig::Init: SSL initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Mon Oct 20 15:08:32 2014). [2014-10-24 18:02:11.640, Info < proxysrv:10684>] SSLSocket::Callback: Handshake done: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 Does this really mean "SSLv3.0 protocol negotiated"? Or does it just mean "SSLv3.x" (which includes TLSv1.x)? Or perhaps "SSLv3 compatible cipher suite" (which also includes TLSv1.x)? On server, I have these ciphers set: ::SSL_CTX_set_cipher_list(ctx, "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"); Is there something wrong with these ciphers? What are best cipher argument for only TLSv1 communication. I think, I need not set ciphers on client side. Thanks – Pradeep reddy. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org<mailto:openssl-users@openssl.org> Automated List Manager majord...@openssl.org<mailto:majord...@openssl.org> :��I"Ϯ��r�m���� (���Z+�K‑�+����1���x ��h���[�z�(���Z+� ��f�y�����‑�f���h��)z{,��
