testssl not detecting all cipher suites

Question

I was testing the supported cipher suites for an exposed httpd service. On the server, the cipher suites are defined in the httpd properties file ( httpd.sslCipherSuite=....)

When I run testssl from my Kali machine, I get a list of cipher suites, but one of the default lists does not show. Am I missing something?

The command I run: testssl -E myserver.com:19000

Output:

Testing ciphers per protocol via OpenSSL plus sockets against the server, ordered by encryption strength 


Hexcode | Cipher Suite Name (OpenSSL)  |  KeyExch.  |  Encryption |  Bits | Cipher Suite Name (IANA/RFC)
____________________________________________________________________________
SSLv2  
SSLv3  
TLS 1  
TLS 1.1  
TLS 1.2  
 xc030  | ECDHE-RSA-AES256-GCM-SHA384  |  ECDH 256  |  AESGCM  |  256  |  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 xc028  | ECDHE-RSA-AES256-SHA384      |  ECDH 256  |  AES     |  256  |  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 xc02f  | ECDHE-RSA-AES128-GCM-SHA256  |  ECDH 256  |  AESGCM  |  128  |  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 xc027  | ECDHE-RSA-AES128-SHA256      |  ECDH 256  |  AES     |  128  |  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
             
TLS 1.3  

 Done 2023-06-08 07:51:15 [17s] -->> x.x.x.x:19000 (myserver.com) <<--

In the default list of cipher we have ECDHE-ECDSA-AES256-SHA384, ECDHE-ECDSA-AES128-SHA256, however both are not detected in the testssl scan.

According to chatgpt:

Question: if I have a server exposing a TLS port with an RSA certificate, and I run the testssl.sh tool on a linux machine acting as a client to detect the supported cipher suites by the server, will testssl detect the cipher suites that use ECDSA ?

Yes, the testssl.sh tool should be able to detect cipher suites that use ECDSA on the server, even if the server is using an RSA certificate.

When performing a scan with testssl.sh, it checks the supported cipher suites by initiating a connection to the server and examining the ServerHello message sent by the server during the SSL/TLS handshake. The ServerHello message includes information about the cipher suites supported by the server.

Cipher suites are negotiated during the handshake process, and the server's certificate type (RSA or ECDSA) does not restrict the available cipher suites. The cipher suites supported by the server depend on the server's configuration, and they can include both RSA and ECDSA-based cipher suites.

Therefore, testssl.sh should be able to detect and display the cipher suites supported by the server, including those that utilize ECDSA.

Answer 1

The cipher suite specifies 5 parts: key agreement, end entity authentication, encryption, symmetric message authentication and PRF.

The second part is special: It is the way the server will prove to the client that it holds the private key for the end entity / leaf certificate.

For RSA certificates, the server will use an RSA signature over the ECDHE key share (or DHE key share in older TLS_DHE_RSA_ cipher suites that Chrome doesn't support anymore).

For ECDSA certificates, an ECDSA signature.

DH and DSA certificates don't exist since the 90s.

TLS_RSA_ (no ECDHE, no DHE) cipher suites that use RSA encryption for both key agreement and authentication should not be used because they lack PFS. They are not allowed for HTTP2 and don't exist in TLS 1.3.

If a client indicates it supports everything needed for ECDSA (the cipher suites, the point format and the signature algorithm), and the server has an ECDSA certificate to use, the server can use TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or similar. Especially if the client doesn't offer an alternative, like a client used for testing which cipher suites a server supports. But a server that can use TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 will not do that if it doesn't have an ECDSA certificate. It can't.

Servers support having both an RSA and an ECDSA certificate configured and choosing based on what the client supports. Many years ago Cloudflare made this popular to reduce CPU load on the server, because producing ECDSA signatures is much cheaper that producing RSA signatures, but clients would prefer verifying RSA, because that is faster. See benchmarks here: https://security.stackexchange.com/a/232091/70830

It is common to have an ECDSA end-entity / leaf certificate signed by an RSA root - the client will handle that fine.

Answer 2

To follow up on Z.T.'s comment and answer, all you need to do is create a client cert using an elliptic curve. Below is an example set of OpenSSL commands to achieve that - elliptic curve secp160k1 is specified in the key generation part. Point to it as a cert for the TLS handshake. That way you should be able to verify ECDSA suites.

#Prerequisites: a CA cert named CA.pem and CA.conf config file

#generate private key for end entity cert

openssl ecparam -genkey -name secp160k1 -out my_private.key

#generate CSR (certificate signing request)

openssl req -new -sha256 -key my_private.key -out my.csr -subj '/C=US/ST=any/L=any/O=My End Entity Cert/CN=mycert' -config CA.conf

#sign the CSR thereby creating my.pem, a cert to be used in the TLS handshake

openssl ca -md sha256 -batch -cert CA.pem -config CA.conf -notext -days 1 -in my.csr -out my.pem -extensions v3_req

#v3_req section in CA.conf

[v3_req]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = critical, serverAuth, clientAuth
basicConstraints = critical,CA:FALSE