AnsweredAssumed Answered

TLSv1.3 and ECDSA not tested?

Question asked by Bernard Spil on Mar 18, 2019

Hi all,

 

In the SSLLabs scan output I'm missing ECDSA and p-521 for TLSv1.3 capable servers. Am I missing something, or am I just too early to expect this?

 

Given the following configuration in Apache httpd (FreeBSD, Apache httpd from ports):

$ httpd -V
Server version: Apache/2.4.38 (FreeBSD)
Server's Module Magic Number: 20120211:83
Server loaded: APR 1.6.5, APR-UTIL 1.6.1
$ ldd /usr/local/libexec/apache24/mod_ssl.so
/usr/local/libexec/apache24/mod_ssl.so:
libssl.so.11 => /usr/local/lib/libssl.so.11 (0x800698000)
libcrypto.so.11 => /usr/local/lib/libcrypto.so.11 (0x800e00000)
$ /usr/local/bin/openssl version
OpenSSL 1.1.1b 26 Feb 2019
$ grep SSL /usr/local/etc/apache24/httpd.conf
SSLEngine on
SSLCertificateFile ${sslRoot}/certs/${vhost}_ecc.pem
SSLCertificateKeyFile ${sslRoot}/priv/${vhost}_ecc.pem
SSLCertificateFile ${sslRoot}/certs/${vhost}.pem
SSLCertificateKeyFile ${sslRoot}/priv/${vhost}.pem
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384"
SSLOpenSSLConfCmd Curves "P-521:P-384"
SSLOpenSSLConfCmd DHParameters "/etc/ssl/dh4096.pem"
SSLCipherSuite TLSv1.3 "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"

${vhost}.pem is the RSA-4096 key/cert

${vhost}_ecc.pem is the ECDSA-384 key/cert

 

I get the following output of the SSLLabs scan:

Cipher Suites

# TLS 1.3 (suites in server-preferred order)

TLS_AES_256_GCM_SHA384 (0x1302) ECDH secp384r1 (eq. 7680 bits RSA) FS 256 TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH secp384r1 (eq. 7680 bits RSA) FS 256

# TLS 1.2 (suites in server-preferred order)

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH secp521r1 (eq. 15360 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp521r1 (eq. 15360 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH secp521r1 (eq. 15360 bits RSA) FS 256

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH secp521r1 (eq. 15360 bits RSA) FS 256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS 256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq. 15360 bits RSA) FS 256

 

The same endpoint, connected with OpenSSL 1.1.1b using s_client:

-----END CERTIFICATE----- 
subject=CN = brnrd.eu
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: ECDH, P-521, 521 bits
---
SSL handshake has read 2972 bytes and written 811 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

So the SSLLabs scan seems to be missing

  1. ECDSA certs
  2. P-521 curve

 

Firefox 65.0.2 negotiates a TLSv1.3 connection TLS_AES_256_GCM_SHA384 using the ECDSA cert.

Chrome 73.0.3683.75 negotiates a TLS 1.3, P-384 AES_256_GCM with ECDSA_P384 cert.

 

Thanks for an excellent service! SSLLabs scans are still more convincing to people than sslscan / testssl.sh scan outputs.

Outcomes