False Positive 'TLS1.3 Server accepts all signature algorithms'

[emanuelfc]

Summary

sslscan may return a False Positive 'Server accepts all signature algorithms' for TLS1.3.

Example

Signature Algorithm = RSA+SHA256 (rsa_pkcs1_sha256)

Not supported by aws.amazon.com.

openssl s_client -connect aws.amazon.com:443 -sigalgs "RSA+SHA256" -tls1_3

However, sslscan reports as 'Server accepts all signature algorithms'.

sslscan --show-sigs --no-cipher-details --no-ciphersuites --no-compression --no-fallback --no-groupseartbleed --no-renegotiation --no-check-certificate --tls13 aws.amazon.com

Explanation

Currently, sslscan only verifies if the ServerHello message was successfully received, and if so, then the given signature algorithm is considered to have been accepted by the server.

sslscan/sslscan.c

Lines 6011 to 6044 in b31459e

	server_hello = getServerHello(s);
	CLOSE(s);
	/* This signature algorithm is not supported. */
	if (server_hello == NULL)
	continue;
	bs_free(&server_hello);
	if (!printed_header) {
	printf("\n %sServer Signature Algorithm(s):%s\n", COL_BLUE, RESET);
	printed_header = 1;
	}
	/* If the server accepted our bogus signature ID, then we can conclude that it will accept all of them (and not test any further). Some servers in the wild do this for some reason... */
	if (sig_id == BOGUS_SIG_ALG_ID) {
	printf("%s%s Server accepts all signature algorithms.%s\n", getPrintableTLSName(tls_version), COL_RED, RESET);
	printf_xml(" <connection-signature-algorithm sslversion=\"%s\" name=\"ANY\" id=\"0xfdff\" />\n", getPrintableTLSName(tls_version));
	break;
	} else {
	printf("%s %s%s%s\n", getPrintableTLSName(tls_version), color, sig_name, RESET);
	printf_xml(" <connection-signature-algorithm sslversion=\"%s\" name=\"%s\" id=\"0x%04x\" />\n", getPrintableTLSName(tls_version), sig_name, sig_id);
	}
	}
	}
	done:
	CLOSE(s);
	bs_free(&ciphersuite_list);
	bs_free(&tls_extensions);
	bs_free(&client_hello);
	bs_free(&server_hello);
	return ret;
	}

However, TLS1.3 now makes use of the CertificateVerify message:

TL;DR: If the server does not support any of the signature algorithms offered by the client, it continues the handshake and may use a different signature algorithm.

...
Servers MUST send this message when authenticating via a certificate.
...
If the CertificateVerify message is sent by a server, the signature algorithm MUST be one offered in the client's "signature_algorithms" extension unless no valid certificate chain can be produced without unsupported algorithms (see Section 4.2.3).

https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.3

"If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general, but MAY do so if the client's advertisement permits it, and MUST NOT do so otherwise."

https://datatracker.ietf.org/doc/html/rfc8446#page-67

As such, it fails to obtain the CertificateVerify message sent by the server and verify if the signature algorithm specified by the client was accepted, or if the server using a different one.

openssl s_client -connect aws.amazon.com:443 -sigalgs "RSA+SHA256" -msg -trace

Remediation

When receiving a CertificateVerify message from the server, verify if the signature algorithm matches the one sent by the client.