1

I'm trying to figure out what is RSA and ECC used for in TLS 1.2 cipher suites.

Let's take TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 for example, communication between server and client would look like this (revised according to answer below) -

C        S 
|<<------| 1.   [PlainText] signed certificate
|------>>| 1.1. [RSA] Authentication: encrypted message using the public key in certificate
|<<------| 1.2. [RSA] Authentication: session key to be used as "master" for DHE
|        |
|<<---->>| 2.   [ECC] Key exchange: using DHE protocol
|        |
|<<---->>| 3.   [ChaCha20+Poly1305] Encrypted data

I guess something in this diagram is wrong, where is RSA being used?


According to other similar questions and the answer below, RSA is used for the authentication of the server.

If I understand correctly, during this auth process a session ID is created by the server (or client?) and will be used later as a master secret for DHE. Correct?

So, what is ECC being used for? To encrypt the key exchange process?

marked as duplicate by Steffen Ullrich, RoraΖ, StackzOfZtuff, schroeder, CodesInChaos Jul 1 '15 at 20:15

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1

You are combining a few components. TLS/SSL is rather complex because there are so many individual pieces which fit together.

The public key is part of the cert and the key exchange and server authentication are two independent steps which (can) use different algorithms.

The server first needs to be authenticated because DH and variants are vulnerable to MITM attacks. You can't securely exchange keys until you know you are talking to the right entity otherwise all you did is "securely" exchange keys with an attacker.

So the server authenticates itself by signing a message using the server's private key. The message, signature, and cert are sent together to the client. The client verifies the signature to authenticate the server is who it says it is. If I am going to https://example.com the browser will expect a cert with a hostname of example.com but a cert is public information. Only the server with the private key can generate a valid signature

The RSA in your example means the algorithm in the digital signature verification is RSA. The algorithm used will be determined by what type of public key the cert contains. If you have a ECC (ECDSA) keypair the authentication is going to be using ECDSA. If it is an RSA keypair the authentication will be using RSA. DSA is also a valid option but I am unsure if CA are still issuing DSA certs.

At the same time the browser will verify the site cert was signed by a cert it trusts. It works backwards as far as it needs until it either reaches a root cert it already trusts (because it is built into the OS) or it runs out of chain and reports the "cert is not trusted".

Once that is all that is complete the client knows it can't be MITM spoofed and is actually talking to the server in question so it can use a key exchange protocol such as RSA, DH, DHE, ECDH, or ECDHE to securely exchange keys with the server. Yes RSA can be used for exchanging keys as well as in digital signatures.

DH_DSS = Key exchange using DH. Authentication using DSA.
DH_RSA = Key exchange using DH. Authentication using RSA.
ECDHE_RSA = Key Exchange using ECDHE Authentication using RSA
ECDHE_ECDSA = Key Exchange using ECDHE Authentication using ECDSA
RSA = Key Exchange and Authentication are both done using RSA
  • I've updated the diagram to my best understanding of your answer, is it correct? – Kof Jul 2 '15 at 4:52
  • It is closer but still has some inaccuracies (or it could just be the wording not being precise). To respect the mods decision to close I would take a look at this tools.ietf.org/html/rfc4492#section-2 and if you still have further questions post a new question on the specific components you need clarification on. – Gerald Davis Jul 2 '15 at 13:34

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