I have a question related to the cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039).

It is first mentioned in RFC3268 in 2002. The highest available TLS version in 2002 was TLS 1.0 (RFC 2246). Thus RFC3268 was an extention which provided new cipher suites to TLS 1.0. The mentioned cipher suite is also listed in RFC4346 (TLS 1.1) and RFC5246 (TLS 1.2).

I was running different tools to check the cipher suite. First openssl s_client:

$ openssl s_client -cipher DHE-RSA-AES256-SHA -connect www.uni-luebeck.de:443
Protocol  : TLSv1.2
Cipher    : DHE-RSA-AES256-SHA

And with nmap:

nmap --script ssl-enum-ciphers -p 443 www.uni-luebeck.de | grep "ciphers\|TLSv\|TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
| ssl-enum-ciphers: 
|   SSLv3: No supported ciphers found
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLSv1.1: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong

Checking the same cipher suite with openssl ciphers returns SSLv3, which seems wrong to me:

$ openssl ciphers -V | grep 0x39
0x00,0x39 - DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
  • I'm not sure I understand your question?
    – RoraΖ
    Jul 19, 2016 at 12:32
  • Why is it SSLv3 with openssl ciphers, and not TLSv1?
    – Dennis
    Jul 19, 2016 at 12:34
  • 3
    If I had to guess, OpenSSL would offer 0x00,0x39 over SSLv3 connections, even though it wasn't defined until TLS 1.0 (RFC3268). TLS/SSL is pretty messy and OpenSSL makes it even messier. Jul 19, 2016 at 14:16
  • 1
    I second John. I have learned through experience that this specific field (where openssl highlights the TLS protocol ver), is not reliable.
    – sandyp
    Jul 19, 2016 at 23:58

2 Answers 2


OpenSSL has only three categories of 'cipher' for SSL/TLS (really ciphersuite, and not to be confused with EVP named ciphers used among other things in openssl enc which are quite different):

  • SSLv2 uses the SSL2 encoding (3 bytes) and is usable only in SSLv2 (which of course you shouldn't use at all, and by default is #if'ed out at compile time in recent versions)

  • SSLv3 which uses the SSL3 encoding (2 bytes, which is the same for TLS1.0 through 1.2) and the record formats defined in SSL3 (GenericStream and GenericBlock which is actually CBC) which are essentially unchanged in TLS1.0 through 1.2 (except 1.1 and up fixes the exposed-IV problem reported by Vaudenay and exploited by BEAST)

  • TLSv1.2 which uses the same encoding as SSL3 but the record format for AEAD (update) or HMAC-SHA2 which both exist only in TLS1.2

As a result of this categorization, OpenSSL supports using the export cipher suites in TLS1.1 and 1.2 even though 4346 officially deleted them (along with the special export KDF), and the single-DES and IDEA suites in TLS1.2 even though 5246 officially 'deprecated' them -- but only if they are supported at all (which in recent versions most aren't by default) and only if the peer agrees (which most won't).


When I try the openssl command you mentioned against another site:

openssl s_client -cipher DHE-RSA-AES256-SHA -connect www.verificationlabs.com:443

I see in the results the following which I assume means it applies to both SSLv3 and TLSv1.*:

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

So this may simply be an issue with the way OpenSSL formats its answer.

relevant link:


  • 1
    Actually it means SSLv3 and TLSv1.0 through 1.2 (in OpenSSL versions 1.0.1 and up where TLSv1.1 and 1.2 are implemented, but lower versions are no longer supported upstream). If you look about 7 lines down in the s_client output you will see Protocol: TLSv1.2 which means even though the cipher is categorized as SSLv3 it was used (and is usable) in TLSv1.2. Jul 20, 2016 at 0:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .