How to interpret security impact of "Server Signature Algorithms" (sslscan)

Question

I'm looking at the results of an sslscan of an internal web application, which reports the following:

I'm not sure how to interpret these and couldn't find an elaboration of what exactly this represents on their github page. Are these the signature algorithms used in the available cipher suites for the TLS connection? The signature algorithm of the TLS certificate uses SHA256 with RSA, so it can't be that.

EDIT: Complete output of the sslscan:

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

Here is the code: https://github.com/rbsec/sslscan/blob/master/sslscan.c#L5584

The software has an array of values of TLS "SignatureAndHashAlgorithm", 2 byte values which before TLS 1.3 used to be a combination of hash and digital signature single byte values you could mix and match but now are just 2 byte values, with a list managed by IANA.

For every value, it creates a new TCP connection and sends a valid TLS ClientHello that should succeed, but it sends a special signature_algorithms extension in the ClientHello that includes only the tested value. If the server sends a good ServerHello, it means the server accepted the tested signature_algorithms value and the value is printed. The software hardcodes some values to have a color, indicating the software author thinks accepting those values is a problem. Those values that caused the server to not accept the connection are not printed.

The server should use those values to determine which certificate it should use (if it has multiple unexpired certificates for the domain in SNI, for example an RSA and an ECDSA certificate, like what Cloudflare does) and also which online signature it should perform on the DHE/ECDHE data (ServerKeyExchange, the signature that proves possession of the private key of the leaf certificate).

The meaning of the extension is as follows:

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

If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the signature_algorithms extension, listing the algorithms it is willing to accept.

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

If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension.

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

If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension. Note that there is a possibility for inconsistencies here. For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension. In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them. This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design.

Thus, if the client sends the extension and only lists one value, the server should think the client indicates it only supports this value (and no other values, not even the defaults) and if the server can't serve a certificate chain and perform an online signature that can be validated using only this signature scheme, the server should abort the connection.

This is not what is happening in your case (the server created connections using RSA certificate when the software says the client indicated it only supports dsa or ecdsa). Maybe the ClientHello actually sent by sslscan is not what it thinks, maybe the test of the server's response is not what it thinks, maybe the server just ignores this extension and just tries its best using the cipher suite list. The latter would be non-compliance of the server with the RFC, but not necessarily a security problem if the server just always uses a secure signature scheme regardless of what the client asks.

I think this code of the sslscan tool is not very useful. It sends a cipher suite list that includes everything, and a signature_algorithms extension limited to one value. It does not actually test which cipher suite was chosen by the server, which online signature was used in ServerKeyExchange and the sent certificate chain. So it's not doing a good job of catching the server at using obsolete signature schemes like anything with md5 or sha1 (or dsa-1024 or rsa-1024 or ecc-224, etc.).

I would recommend you disregard this output - it is not useful.

A better test, if you actually want to test this, would be to craft cipher suite list and signature_algorithms extension for one signature scheme at a time and test the resulting cipher suite and signatures served by the server to try to catch the server doing something bad (like RSA-sha1 online signature, even when the leaf certificate is RSA-sha2, which is a real security problem some servers have, but you won't catch it with this code).

If the server is supposed to support multiple online signature schemes (e.g. rsa-sha-256 and rsa-sha-512) and it fails at that - test specifically that. If the server is supposed to support choosing between an RSA and an ECDSA certificate based on client preference test for that.

Answer 2

What you are seeing is a list of algorithms of signature validation supported by the server. At the key exchange phase, the server advertises to the client which pairs of signature and hashing protocols it supports (which unlike in TLS 1.0 and 1.1 there's a fair few as per RFC5246). There are inferred defaults depending on the cipher suites chosen.

This was the best resource I found that explains this feature. As far as I was able to ascertain, this is used to verify the integrity of the premaster secret sent by the client to the server. Naturally both peers need to use the same scheme to make sure the results match.