2

As per this answer RSA and ECC certificates should use different cipher suites. I tried to test it. It holds true for TLSv1.2. But for TLSv1.3 I see same cipher suite being used for both types of certificates(Tested via Google Chrome=>Dev Tools=>Security). Why is that?

Here is how I generated an ECC cert:

openssl ecparam -out nginx.key -name prime256v1 -genkey
openssl req -new -key nginx.key -out csr.pem
openssl req -x509 -nodes -days 365 -key nginx.key -in csr.pem -out nginx.pem

Generating RSA cert:

 openssl genrsa -out rsa.key 2048
 openssl req -x509 -new -nodes -key rsa.key -days 7300 -out rsa.pem

With TLS1.3 both the certs result in usage of same cipher suite:

The connection to this site is encrypted and authenticated using TLS 1.3,
 X25519, and AES_256_GCM.

With TLS1.2, RSA cert:

    The connection to this site is encrypted and authenticated using TLS 1.2,
 ECDHE_RSA with X25519, and AES_256_GCM.

With TLS1.2, ECC cert:

The connection to this site is encrypted and authenticated using TLS 1.2, 
ECDHE_ECDSA with X25519, and AES_256_GCM.
3
  • 3
    That answer, and many others, was written before Aug 2018 when TLS 1.3 was approved (and it was several months to a year or more before many systems implemented it). All TLS versions before 1.3 (and also SSLv3) did include the keyexchange method and thus the server key-and-cert type in the ciphersuite, but TLS 1.3 changes this and does not do so. See the paragraph beginning 'Although' in rfc8446 B.4 – dave_thompson_085 May 18 '20 at 2:58
  • @dave_thompson_085 So in case of TLS1.3 the certificate type(RSA or ECC or OTHER) has no impact on cipher suite chosen for the connection? – simplfuzz May 18 '20 at 7:41
  • Yes in 1.3 cert is independent of ciphersuite. More exactly there are now two kinds of RSA certs supported (the old 'rsae' type and the newer rsapss-specific type), and ECC (ECDSA or EdDSA), but no other algorithms, in particular not 'classic' DSA which was used (not very widely) in some ciphersuites in older TLS. – dave_thompson_085 May 18 '20 at 16:26
0

TLS Cipher suites define several parameters including key exchange, encryption and hashing and must be agreed between clients and server.

The use of RSA or ECC certificates does require different key exchange parameters (specifically *_RSA vs *_ECDSA). Whilst just about everything else can be the same in a TLS connection, the actual cipher suite definition must be different when connecting with an RSA vs EC certificate.

https://tools.ietf.org/html/rfc8422#section-2

One thing to note is that the naming scheme of TLS 1.3 cipher suites has changed vs TLS 1.2, which means the above may not be obvious.

TLS 1.3 does indeed support _RSA key exchange (and certificates).

https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

5
  • TLS 1.3 supports RSA - I was able to test it. But I see same Cipher suite for both RSA and ECC certs. How do I see the difference between them? I can modify the OpenSSL source and log if required. – simplfuzz May 18 '20 at 10:50
  • If you open a connection with openssl s_client -connect ... in either case you might see more debugging information. Otherwise, from memory, a wireshark trace of the comms should(1) show enough information about client and server negotiating cipher suites that you can see the difference. 1: I cannot be sure if this is the case with TLS 1.3, you'll need to try. – Pedro May 18 '20 at 11:21
  • 2
    No, in 1.3 keyexchange is no longer in the ciphersuite at all; see my link to 8446 B.4. 8422 is for 1.2 and below only, as its title says.1.3 keyexchange is now negotiated separately using the keyshare, pskmode, and (two) sigalgs extensions. And it does support either ECDSA or RSA auth (cert) for all ciphersuites. – dave_thompson_085 May 18 '20 at 16:21
  • Thanks @dave_thompson_085 – Pedro May 19 '20 at 8:01
  • I don't know that it's completely clear from Dave's comment but it's important to note that while RSA certs are indeed supported, RSA key exchange is not. The relevant portion from the TLS 1.3 RFC: "Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy." – Xander Jun 17 '20 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.