3

I'm running the below Nmap command to test the strength of the cipher suites I have used in my host

nmap -sV --script ssl-enum-ciphers -p 443 <host>

The Nmap doc says that Each ciphersuite is shown with a letter grade (A through F) indicating the strength of the connection and the output line beginning with Least strength shows the strength of the weakest cipher offered

When I ran the command against the host I got the output as shown below

| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 768) - E
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       64-bit block cipher DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 768) of lower strength than certificate key
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 768) - E
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       64-bit block cipher DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 768) of lower strength than certificate key
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 768) of lower strength than certificate key
|_  least strength: E

My questions

  1. As per the doc, the Ciphers marked as "E" is the weak cipher and in another way can I consider the cipher marked as "A" as the strong cipher?
  2. TLS_RSA_WITH_AES_128_CBC_SHA is marked as "A" here, but in some discussions, I have observed it is mentioned as WEAK. Is it because of the SHA1 usage? if so why this is rated as "A" in NMAP?
  3. I have configured the below cipher list on my server.

    ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"

but the ciphers such as SSL_RSA_WITH_RC4_128 is not available in the Nmap output, instead, there are ciphers like TLS_RSA_WITH_RC4_128, what is the reason for this? Can we use SSL and TLS interchangeably in the Ciphers?

  1. Even though I have added the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as a cipher in my server, it wasn't available in the Nmap results, what might be the reason for this?

PS: I'm using JDK 1.7 as the underlying JDK version for the server

Prakhash
  • 193
  • 2
  • 8
  • *"...but in some discussions, I have observed it is mentioned as WEAK..."* - maybe the discussions are wrong, maybe you've understood it wrong, maybe ... - please cite the relevant discussions. – Steffen Ullrich May 01 '18 at 10:55
  • I think it's because of it doesn't provide PFS. So can I consider this as a Strong cipher? Is it a must to use a cipher which provides PFS when choosing a cipher? [1] https://community.qualys.com/thread/17971-tlsrsawithaes256cbcsha-comes-to-be-weak-cipher – Prakhash May 01 '18 at 12:48
  • I use another fantastic tool when I'm assessing ciphers. I'd like to recommend it for checking SSL/TLS strength that's being constantly updated and works on most linux distros! Have a look at testssl.sh here: https://github.com/drwetter/testssl.sh Really nice script and very handy during Vulnerability Assessments or Penetration Tests. It packs information about different strengths and has a very nice colorful output that is easy on the eyes. Let me know if it worked out better for you :) – Robert May 01 '18 at 14:07

1 Answers1

5

You are asking multiple unrelated questions which is not the recommended way to ask and chances are that the question might be closed as too broad or as duplicate since some part was already answered somewhere else. Still, to give some short answers:

As per the doc, the Ciphers marked as "E" is the weak cipher and in another way can I consider the cipher marked as "A" as the strong cipher?

It clearly says in the documentation

The scoring is based on the Qualys SSL Labs SSL Server Rating Guide, but does not take protocol support (TLS version) into account, which makes up 30% of the SSL Labs rating.

The relevant guide can be easily found and it includes an explanation of the scoring at the very beginning. But yes, 'A' means essentially stronger then 'B' etc.

TLS_RSA_WITH_AES_128_CBC_SHA is marked as "A" here, but in some discussions, I have observed it is mentioned as WEAK. Is it because of the SHA1 usage? if so why this is rated as "A" in NMAP?

Because the nmap script is based on a guide from 2009. While TLS_RSA_WITH_AES_128_CBC_SHA isn't weak it would today probably be graded down to B since it uses RSA key exchange (no forward secrecy). But it is far from weak and I don't know who claimed this (please always add links if you cite opinions from somewhere else).

...SSL_RSA_WITH_RC4_128 is not available in the Nmap output, instead, there are ciphers like TLS_RSA_WITH_RC4_128...

These are the same. There are several naming conventions originating from different times or software products.

Even though I have added the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as a cipher in my server, it wasn't available in the Nmap results, what might be the reason for this?

As you can see there are only RSA ciphers in the nmap output. This is because you are using a certificate with an RSA key. For ECDSA ciphers you would need to use a certificate with an ECC key.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424