0

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.

4
  • Is it possible that you need to specify a mode (e.g. CBC, GCM) to be used with AES256 and AES128?
    – mti2935
    Jun 8, 2023 at 16:14
  • 4
    You need an ECDSA certificate to use ECDSA cipher suites. Do you have one?
    – Z.T.
    Jun 8, 2023 at 16:58
  • @Z.T. what do you mean ? can you please clarify ? my understanding is that the testssl tool scans the exposed ports on the server and checks all supported cipher suites, no? Jun 9, 2023 at 11:05
  • Congratulations! You've discovered that the purpose of ChatGPT is to sound like a human -- it does not make any attempt to be correct, and usually is NOT correct and in this case is totally wrong. This has only been all over the news for months -- were you on another planet? Jul 11, 2023 at 0:49

2 Answers 2

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.

0

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
7
  • you mean a server certificate no? because the client (testssl) already supports ECDSA, and in Z.T's comment he mentions that " 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" so we need to create an ECDSA server certificate, right? Jun 16, 2023 at 7:14
  • Looks like you are trying to test the server. testssl is your client then. This certificate, if used by testssl, will let you test the server's ECDSA suites. Jun 16, 2023 at 15:14
  • yes indeed I am testing my server , why would I test the client ? I am checking the supported cipher suites that I have on the server through the testssl tool. I use testssl becuase it automatically tells which cipher suites are weak. Jun 16, 2023 at 15:35
  • @ethicalhacker In order communicate they exchange certificates so, you need to update the client cert in order to test the server. The method I posted will allow you to do that. Read up on TLS handshake. Jun 16, 2023 at 15:59
  • I followed your steps, when I ran the last command, I get using CA.conf file, and then it does not generate a certifcate. Prior to running your commands I created the CA key and CA certificate using the below commands: -- openssl genrsa -out private/ca_key.pem 4096 -- openssl req -config CA.conf -key private/ca_key.pem -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca_cert.pem -subj "/C=FR/ST=Paris/L=Paris/O=M/OU=MX/CN=Root CA" Jun 19, 2023 at 10:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .