0

When capturing my SSL session (using Chrome) I have noticed that the server chose TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) as the cipher-suite and the certificate signedcertificate signature was sha256WithRSAEncryption.

How come the certificate uses RSA while the Cipher-suite is ECDSA?

I found the answer:

In TLSv1.2, and only in TLSv1.2 - if the client hello include an extension called "signature_algortithm", the server may sign the certificate with any of the methods mentioned in the extension, regardless the cipher-suite it choose to work with.

you can see the extension structure here:

signature_algorithm structure

regards, Amigal

  • I see a different cipher and according to SSLLabs none of the IP's for this host supports any ECDSA ciphers. – Steffen Ullrich Jul 28 '15 at 19:19
  • I made a mistake, sorry about it. its the session to google server called ssl.gstatic.com – amigal Jul 28 '15 at 19:36
2

its the session to google server called ssl.gstatic.com

In short: the ECDSA in the cipher suite refers to the key of the sites certificate. The RSA in the signature refers to the key of the certificates issuer. In detail:

To check what kind of certificate you get with this cipher:

openssl s_client -connect ssl.gstatic.com:443 \
   -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256' -tls1_2 -servername ssl.gstatic.com \
  | openssl x509 -text

This gives a certificate with an EC key, as expected:

Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2
...
Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.google.com
Subject Public Key Info:
   Public Key Algorithm: id-ecPublicKey
      Public-Key: (256 bit)

But even if the certificate itself uses an EC key it is signed with an RSA key:

Signature Algorithm: sha256WithRSAEncryption

This is because the signature is created by the issuer and is thus using the key of the issuers certificate. And the issuer is using an RSA key:

Subject: C=US, O=Google Inc, CN=Google Internet Authority G2
Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)
  • just to be sure - the ECDSA/RSA (the second parameter of the cipher-suite) points on the type of the public key? – amigal Jul 28 '15 at 20:21
  • Yes, it tells you the algorithms used in the SSL handshake to verify that the server owns the private key to the public key inside the servers certificate. Since this is an EC key in this case ECDSA is used for verification. – Steffen Ullrich Jul 28 '15 at 20:23
1

I cannot reproduce this instance from my machine.

Assuming that the server indeed negotiated TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and still uses a certificate with a RSA public key, then this would be in violation of the standard, and yet it could still work with some client implementation: the SSL client perfectly knows the type of server public key (it is written in the server certificate, that the client just validated) and it can be expected that some clients are lenient (or lazy) enough to simply use that information without taking into account the redundant information in the cipher suite.

(But, I repeat, I cannot confirm this situation since I observe something different from my own machine.)

  • Thanks for the answer. I have just edited my question. it is a session to ssl.gstatic.com (google server) – amigal Jul 28 '15 at 19:39
  • From here, ssl.gstatic.com uses a certificate that contains an EC public key, so everything appears to be in order. – Tom Leek Jul 28 '15 at 19:43
  • Maybe I'm wrong, but IIRC there was a discussion on making TLS_ECDHE_ECDSA_... the cipher suite for TLS v1.3 on the tls mailing list. From there I got the impression that it is totally valid to negotiate RSA signatures (/certificates) although using an ECDSA cipher suite. – SEJPM Jul 28 '15 at 19:47
  • @SEJPM - can you please add a link? – amigal Jul 28 '15 at 20:02
  • 1
    @amigal, This is the very first mail of this thread. TLS v1.2 spec also allows clients to accept non-ciphersuite conformant signatures. However the end-entities certificate must match (if you negotiate ECDSA you must also provide an ECDSA cert for yourself) but other certificates may have different signature algorithms. For TLS v1.3 things may change. – SEJPM Jul 28 '15 at 20:21
0

In TLSv1.2, and only in TLSv1.2 - if the client hello include an extension called "signature_algortithm", the server may sign the certificate with any of the methods mentioned in the extension, regardless the cipher-suite it choose to work with.

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.