如何解释“服务器签名算法”(sslscan)的安全影响

Question

我正在查看内部web应用程序的单字扫描的结果，它报告如下：

我不知道如何解释这些内容，也无法在他们的github页面上找到这到底代表什么的详细说明。这些是TLS连接可用密码套件中使用的签名算法吗？TLS证书的签名算法使用SHA256和RSA，所以不可能是那样的。

编辑: the扫描的完整输出：

Version: 2.0.0-static
OpenSSL 1.1.1h-dev  xx XXX xxxx

Connected to <redacted>

Testing SSL server <redacted>

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   disabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
Accepted  TLSv1.2  256 bits  AES256-SHA256                
Accepted  TLSv1.2  128 bits  AES128-SHA256                                                                        
Accepted  TLSv1.2  256 bits  AES256-SHA                                                                           
Accepted  TLSv1.2  128 bits  AES128-SHA                                                                           
Accepted  TLSv1.2  112 bits  DES-CBC3-SHA                                                                         
Preferred TLSv1.1  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256                                    
Accepted  TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256                                    
Accepted  TLSv1.1  256 bits  AES256-SHA                                                                                                                                                                                                    
Accepted  TLSv1.1  128 bits  AES128-SHA                                                                                                                                                                                                    
Accepted  TLSv1.1  112 bits  DES-CBC3-SHA                                                                                                                                                                                                  
Preferred TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256                                                                                                                                                             
Accepted  TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256                                                                                                                                                             
Accepted  TLSv1.0  256 bits  AES256-SHA                                                                                                                                                                                                    
Accepted  TLSv1.0  128 bits  AES128-SHA                                                                                                                                                                                                    
Accepted  TLSv1.0  112 bits  DES-CBC3-SHA                                                                                                                                                                                                  
                                                                                                                                                                                                                                           
  Server Key Exchange Group(s):
TLSv1.2  141 bits  sect283k1
TLSv1.2  141 bits  sect283r1
TLSv1.2  204 bits  sect409k1
TLSv1.2  204 bits  sect409r1
TLSv1.2  285 bits  sect571k1
TLSv1.2  285 bits  sect571r1
TLSv1.2  128 bits  secp256k1
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  260 bits  secp521r1 (NIST P-521)
TLSv1.2  128 bits  brainpoolP256r1
TLSv1.2  192 bits  brainpoolP384r1
TLSv1.2  256 bits  brainpoolP512r1

  Server Signature Algorithm(s):
TLSv1.2  rsa_pkcs1_sha1
TLSv1.2  dsa_sha1
TLSv1.2  ecdsa_sha1
TLSv1.2  rsa_pkcs1_sha224
TLSv1.2  dsa_sha224
TLSv1.2  ecdsa_sha224
TLSv1.2  rsa_pkcs1_sha256
TLSv1.2  dsa_sha256
TLSv1.2  ecdsa_secp256r1_sha256
TLSv1.2  rsa_pkcs1_sha384
TLSv1.2  dsa_sha384
TLSv1.2  ecdsa_secp384r1_sha384
TLSv1.2  rsa_pkcs1_sha512
TLSv1.2  dsa_sha512
TLSv1.2  ecdsa_secp521r1_sha512

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    4096

Subject:  <redacted>
Altnames: <redacted>
Issuer:  <redacted>

Not valid before: Jan 01 00:00:00 2020 GMT
Not valid after:  Jan 01 00:00:00 2021 GMT

Answer 1

下面是代码：https://github.com/rbsec/sslscan/blob/master/sslscan.c#L5584

该软件有一个TLS "SignatureAndHashAlgorithm“值数组，在TLS1.3之前的2字节值是散列值和数字签名单字节值的组合，您可以混合和匹配，但现在只有2字节值，一份清单由IANA管理。

对于每个值，它创建一个新的TCP连接，并发送一个应该成功的有效的TLS ClientHello，但是它在ClientHello中发送一个特殊的signature_algorithms扩展，其中只包含测试的值。如果服务器发送了一个好的ServerHello，这意味着服务器接受了测试的signature_algorithms值并打印了该值。软件硬编码一些值有颜色，表明软件作者认为接受这些值是一个问题。没有打印那些导致服务器不接受连接的值。

服务器应该使用这些值来确定它应该使用哪个证书(如果它在SNI中有多个未过期的证书，例如RSA和ECDSA证书，比如Cloudflare所做的事情)，还应该在DHE/ECDHE数据上执行哪些在线签名(ServerKeyExchange，证明拥有叶证书的私钥的签名)。

扩展的含义如下：

https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.4.1

如果客户端只支持默认的散列和签名算法(在本节中列出)，则可能省略signature_algorithms扩展。如果客户端不支持默认算法，或者支持其他哈希和签名算法(并且愿意使用它们来验证服务器发送的消息，即服务器证书和服务器密钥交换)，则必须发送signature_algorithms扩展，列出它愿意接受的算法。

https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2

如果客户端提供了"signature_algorithms“扩展，那么服务器提供的所有证书都必须由该扩展中出现的散列/签名算法对签名。

https://www.rfc-editor.org/rfc/rfc5246#section-7.4.3

如果客户端提供了"signature_algorithms“扩展，则签名算法和哈希算法必须是该扩展中列出的一对。请注意，这里可能存在不一致的情况。例如，客户端可能提供DHE_DSS密钥交换，但在其"signature_algorithms“扩展中忽略任何DSA对。为了正确协商，服务器必须在选择"signature_algorithms“扩展之前检查任何候选密码套件。这有点不雅，但这是一种折衷方案，旨在将对原始密码套件设计的更改降到最低。

因此，如果客户端发送扩展并只列出一个值，服务器应该认为客户端只支持此值(不支持其他值，甚至不支持默认值)，如果服务器无法提供证书链并执行只能使用此签名方案验证的在线签名，则服务器应中止连接。

在您的情况下，情况并非如此(当软件说客户端只支持dsa或ecdsa时，服务器使用RSA证书创建连接)。也许sslscan实际上发送的ClientHello不是它所想的那样，也许服务器响应的测试不是它想要的那样，也许服务器只是忽略了这个扩展，而只是使用密码套件列表来尽最大努力。后者将是服务器不符合RFC，但不一定是一个安全问题，如果服务器总是使用安全签名方案，而不管客户端要求什么。

我认为这个sslscan工具的代码不是很有用。它发送包含所有内容的密码套件列表，以及仅限于一个值的signature_algorithms扩展。它实际上不测试服务器选择了哪个密码套件，在ServerKeyExchange和发送的证书链中使用了哪个在线签名。因此，在使用过时的签名方案(如md5或sha1 (或dsa-1024或rsa-1024或ecc-224等))时，它并不能很好地捕获服务器。

我建议你忽略这个输出--它是没有用的。

一个更好的测试，如果您真的想测试这一点，应该是一次为一个签名方案制作密码套件列表和signature_algorithms扩展，并测试得到的密码套件和服务器所提供的签名，以试图捕捉服务器正在做一些错误的事情(比如RSA-sha1 1在线签名，即使叶子证书是RSA-sha2，这是一些服务器面临的真正的安全问题，但是您不会用这个代码捕获它)。

如果服务器应该支持多个在线签名方案(例如rsa-sha-256和rsa-sha-512)，那么它就会在该测试中失败。如果服务器应该支持在RSA和ECDSA证书之间进行选择，则基于客户端首选项测试。

Answer 2

您看到的是服务器支持的签名验证算法列表。在密钥交换阶段，服务器向客户端通告它所支持的签名和散列协议对(与TLS1.0和1.1中的签名和散列协议不同，根据RFC5246，这两个协议比较少)。根据选择的密码套件，有推断的默认值。

这是我发现的解释此特性的最佳资源。就我所能确定的情况而言，这是用来验证客户端发送到服务器的premaster机密的完整性。当然，两个对等点都需要使用相同的方案来确保结果匹配。