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

amigal
  • 193
  • 3
  • 9
  • I see a different cipher and according to [SSLLabs](https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com) 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

3 Answers3

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)
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 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.)

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 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
  • @Tom Leek - can you please elaborate. Whats the connection between the type of the public key and the method to sign the certificate? – amigal Jul 28 '15 at 20:04
  • 1
    @amigal, [This is the very first mail of this thread](https://www.ietf.org/mail-archive/web/tls/current/msg16698.html). [TLS v1.2 spec also allows clients to accept non-ciphersuite conformant signatures.](https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1) 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.

amigal
  • 193
  • 3
  • 9