6

When I look at Google's Public Key in Firefox I get

PKCS #1 SHA-256 With RSA Encryption

Yet according to SSL Labs Google has

EC 256 bits / SHA256withRSA

and supports

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

How can it when the public key it uses is RSA not a Elliptic Curve one? Does Google present both an EC and an RSA public key in their Certificate file some how?

Zimm3r
  • 295
  • 1
  • 8
  • 3
    Different certificates depending on the negotiated cipher suite more likely. – Maarten Bodewes Nov 12 '15 at 01:31
  • 1
    Google has many sites, many machines for each site, and many different certs which also change frequently. At the moment https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com has reports for 4 addresses, 2 showing a cert with RSA-2048 key (fingerprint 957ff6b46639e20a8c99c46f3d1a810ab9669365) and 2 showing a cert showing EC-256 key (6aa1d74e1416d663494b73dfcf05ff472eddae6c) but listing ECDHE_ECDSA ECDHE_RSA and plain-RSA suites which is inconsistent; undoubtedly it got different certs for different connection attempts but can't display all of them. ... – dave_thompson_085 Dec 13 '15 at 02:14
  • 1
    ... But both these certs and all others I've checked from any google property are signed by Google Internet Authority G2 using SHA256withRSA, because the CA key is RSA. So if you got a connection using ECDHE_ECDSA the cert used must have contained an EC key and almost certainly was signed with SHA256withRSA, hence the notation "EC 256 bits / SHA256withRSA". – dave_thompson_085 Dec 13 '15 at 02:17
  • 2
    Timely bump: SSLLabs now shows more than one cert/chain for a website for example wikipedia although www.google.com now seems to be using only RSA cert (and thus not supporting ECDHE_ECDSA) – dave_thompson_085 Feb 05 '17 at 06:03
  • @dave_thompson_085 Maybe the ECDH option is still not shown because the client doesn't support the Curve25519? I don't know when SSLLabs starts showing off other certs, but this could be a reason? Gmail at least seems to use the P256 curve in the certificate at the moment. – Maarten Bodewes Apr 05 '17 at 11:46
  • @MaartenBodewes: mail.google.com does support both ECDHE_RSA using RSA cert and ECDHE_ECDSA using EC P-256 cert, but www.google.com, which in the past also did that, no longer does -- both 2607:f8b0:4005:805:0:0:0:2004 or 216.58.194.196 recently resolved by SSLLabs and 2607:f8b0:400d:c0d::6a or 209.85.232.105 currently resolved by me. (And my test worked for ECDHE_RSA with either x25519 or P256 for ECDHE group depending on client hello, though SSLLabs doesn't show that.) The SSLLabs blog post for the change to show multiple certs is dated 2016-11-12 (aside: not 'show off'). – dave_thompson_085 Apr 07 '17 at 01:52

1 Answers1

2

I found another link, as the purpose of this was to use both RSA and ECDSA for signing, but that, to my understanding, requires different public/private keys and therefore different certificates

See the following link https://security.stackexchange.com/questions/43360/is-possible-that-a-tls-server-send-more-than-one-certificate-to-the-client-for-t

For signature algorithm support, there is a standard TLS extension specified in section 7.4.1.4.1, by which the client can tell to the server, early in the handshake (in the ClientHello, which is the very first message of the procedure), which hash functions and signature algorithms it supports. This allows a server who owns, for instance, both a RSA-signed certificate and an ECDSA-signed certificate, to send one or the other, depending on what the client supports. This is typical of how things go in TLS: the client suggests, the server chooses.

So it seems to support both ECC and RSA you HAVE to get the client supported algorithms early then play a 'trick' by swapping out the cert. It seems there is no way to just have it be based on the support list of ciphers where you can send multiple certs and have one be your RSA one and the other your ECC one.

EDIT

Here is another link https://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls that confirms that the certificate and the key exchange and cert keys have to match up

You may use a key exchange (as part of a cipher suite) only if the server key type and certificate match.

Community
  • 1
Zimm3r
  • 295
  • 1
  • 8
  • As I commented in 43360, the server's key and thus (leaf) cert is controlled by the ciphersuite or vice-versa; sigalgs is mostly relevant to chain certs -- and then only if you have a choice of chains which in practice you don't. 8343 is ursinely correct, but out of date on one point: in the 4 years since 2011, ECC and particularly ECDHE_ECDSA is now widely (though not universally) supported. – dave_thompson_085 Dec 13 '15 at 02:29