1
$\begingroup$

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

$\endgroup$
1
$\begingroup$

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?

Your server probably uses a RSA-based certificate and the second part of the name states "ECDSA" which means that this ciphersuite indicates an ECDSA-based certificate. As none has been found, the server didn't actually offer this ciphersuite.

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 would appear that "E" means "practically exploitable if you have enough money / time", as example issues seem to include the use of 3DES which is bad for the small block size or the use of DES which has a easily brute-forced keylength.

"A" here probably means "not practically exploitable if decently implemented", which is the only thing I can come up with as the use of CBC and non-DHE suites have been flagged "A".

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?

This suite has two main issues. The use of SHA1 (which is used in HMAC), is not one of them.

  • It uses CBC mode which has been a major cause of worry in TLS in the past and gave rise to many attacks on TLS implementations.
  • It uses key-transport RSA, that is if your private key leaks from your server (eg because of something like heartbleed), all transcripts of past sessions can be decrypted. This is not the case if a (EC)DHE suite is used.

if so why this is rated as "A" in NMAP?

Apparently the nmap developers chose a different notion of "good" as most cryptographers / Google did, in that they define anything as "good" that is "effectively unbreakable if decently implemented" whereas cryptographers want more fancy properties like "hard to get wrong" and "still somewhat secure if compromised in the future".

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?

This is a naming difference. Your implementation chose the prefix to be SSL_, nmap chose it to be TLS_, the objects identified are still the same.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.