0

Recently, I have been looking at PKI and certificates, and TLS 1.2 as part of my study of cryptography. I have the understanding that the public key included in the certificate of a website is the key that is used to establish a session key between two parties.

But on certain websites, when I opened Google Chrome security overview by clicking on the green https padlock, Chrome informed me that the key exchange was done by ECDHE with P-256 (Elliptic Curve Diffie-Hellman, curve P-256). But, upon opening the full certificate details for the website, the public key in the certificate was an RSA 2048 bit public key. But, this confused me, as I thought it should be an ECDHE key and I am not sure whether the key exchange is done by ECDHE, as Chrome says, or RSA, which is the public key in the certificate, which I thought was used in the key establishment.

Any help would be appreciated.

Bruno Rohée
  • 5,221
  • 28
  • 39
Sam Gregg
  • 21
  • 1
  • 4

2 Answers2

3

You are mixing up key exchange and authentication. Key exchange is done so that both parties agree on the same encryption keys. Authentication of the server is done to make sure that the client is talking to the correct server and not to some man in the middle. The RSA/ECC key in the certificate is used for authentication. In case of RSA key exchange the RSA key in the certificate is also used of the key exchange but with DHE and ECDHE key exchanges the certificate key is not used. This means you can combine ECDHE key exchange with both RSA and ECC certificates.

For the deeper details see How does SSL/TLS work?

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Oh thanks, just the book I am working from shows the public key in the certificate being used to compute the session key, that was why I was getting confused. – Sam Gregg Feb 04 '17 at 18:43
  • @SamGregg: that's RSA key exchange then not ECDHE. See edited response. – Steffen Ullrich Feb 04 '17 at 18:44
  • The book shows a DHKE key exchange with certificates (Understanding Cryptography) – Sam Gregg Feb 04 '17 at 18:46
  • @SamGregg: it is hard to tell what you are referring to but I guess that you refer to the very uncommon case of using DH with group parameters defined in the certificate. See http://security.stackexchange.com/a/14190/37315. I would actually recommend that if you are asking about TLS (i.e. what you see in google chrome) that you don't take a book as reference which does not specifically address how things are done in TLS. – Steffen Ullrich Feb 04 '17 at 19:54
  • Yes that is the case, probably used because the book is an introduction and not devoted to key establishment. – Sam Gregg Feb 04 '17 at 19:58
0

Traditionally in SSL/TLS the client choses a master secret and encrypts it with the RSA key from the server's certificate. This is the approach used by the traditional RSA ciphersuites.

However the problem with this approach is that it if the server's long term private key is ever compromised then at attacker can passively decrypt the traffic. In particular they can go back to sessions that they recorded in the past and decrypt them retroactively.

So nowadays it is increasingly common to use "ECDHE-RSA" ciphersuites. In these the key exchange is performed by ephemeral elliptic curve Diffie-Hellman. The ephemeral bit means that the ECDH keys are only used for that one session. The RSA key from the certificate is used to sign the exchange to block man-in the middle attacks.

This means that someone who steals the server's long term private key is limited to active attacks on future sessions, they can't decrypt passively.

Bruno Rohée
  • 5,221
  • 28
  • 39
Peter Green
  • 4,918
  • 1
  • 21
  • 26
  • Actually DHE and then ECDHE became common 6 years ago, soon after Snowden. Today _TLS1.3_ is becoming common, and it no longer has keyexchange in the ciphersuite at all, and _only_ has DHE (limited to rfc7719 groups and now fairly rare) or ECDHE keyexchange except for manually configured PSK (rare) or PSK that replaces session resumption. – dave_thompson_085 Aug 22 '19 at 03:49