关于密码和Nmap扫描的澄清
我正在运行下面的Nmap命令来测试我在主机中使用的密码套件的强度
nmap -sV --script ssl-enum-ciphers -p 443 <host>Nmap 文档表示，每个密件都有一个字母等级(A到F)，表示连接的强度，以最小强度开头的输出线表示提供的最弱密码的强度。
当我对主机运行命令时，得到了如下所示的输出
| 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我的问题
- 根据医生的说法，标记为"E“的密码是弱密码，我可以用另一种方式将标记为"A”的密码视为强密码吗？
- TLS_RSA_WITH_AES_128_CBC_SHA在这里被标记为"A“，但在一些讨论中，我注意到它被认为是弱的。是因为SHA1的使用吗？如果是这样，为什么这在NMAP中被评为"A“？
- 我已经在服务器上配置了下面的密码列表。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“
但是像SSL_RSA_WITH_RC4_128这样的密码在Nmap输出中是不可用的，相反，有像TLS_RSA_WITH_RC4_128这样的密码，原因是什么？我们能在密码中交替使用SSL和TLS吗？
- 尽管我已经将TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256作为密码添加到我的服务器中，但它在Nmap结果中是不可用的，原因可能是什么呢？
PS:我使用JDK1.7作为服务器的底层JDK版本
回答 1
Cryptography用户
发布于 2018-05-01 12:01:20
尽管我已经将TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256作为密码添加到我的服务器中，但它在Nmap结果中是不可用的，原因可能是什么呢？
您的服务器可能使用基于RSA的证书，名称的第二部分声明为"ECDSA“，这意味着此加密套件表示基于ECDSA的证书。由于没有发现，服务器实际上并没有提供这个密匙套件。
根据医生的说法，标记为"E“的密码是弱密码，我可以用另一种方式将标记为"A”的密码视为强密码吗？
"E“的意思似乎是”如果你有足够的钱/时间，实际上是可以利用的“，例如问题似乎包括使用对小块大小不利的3 DES，或者使用DES，因为DES有一个很容易被人强迫的keylength。
这里的"A“可能意味着”如果执行得当，就不会被实际利用“，这是我唯一能想到的东西，因为CBC和非DHE套房的使用已经标记为"A”。
TLS_RSA_WITH_AES_128_CBC_SHA在这里被标记为"A“，但在一些讨论中，我注意到它被认为是弱的。是因为SHA1的使用吗？
这套套间有两个主要问题。SHA1的使用(在HMAC中使用)并不是其中之一。
- 它使用的是CBC模式，这在过去一直是TLS中的一个主要原因，并引发了对TLS实现的许多攻击。
- 它使用密钥传输RSA，也就是说，如果您的私钥从您的服务器泄漏(例如，因为类似于心脏出血)，过去会话的所有记录都可以解密。如果使用(EC)DHE套件，则不是这种情况。
如果是这样，为什么这在NMAP中被评为"A“？
显然，nmap开发人员选择了另一种“好”的概念，就像大多数密码学家/谷歌( Google )所做的那样，他们将任何“好”定义为“好的”，即“有效地、不可打破的(如果有体面的实现)”，而密码开发者想要更多花哨的属性，比如“很难出错”，以及“如果将来受到损害仍会有些安全”。
但是像SSL_RSA_WITH_RC4_128这样的密码在Nmap输出中是不可用的，相反，有像TLS_RSA_WITH_RC4_128这样的密码，原因是什么？
这是命名上的区别。您的实现选择前缀为SSL_，nmap选择为TLS_，所标识的对象仍然相同。
https://crypto.stackexchange.com/questions/58821
复制相似问题
腾讯云开发者
