# A simple misunderstanding of SSL/TLS

I just came to learn about Deffie Hellman Key Exchange. And a little bit about RSA. I came to DH from something about SSL. From what I understood before is that SSL uses DH and TLS uses RSA, but after some research, came to know DH and RSA are both secure/insecure, slow/fast in their own ways, and Both SSL and TLS can use both of them. Here I am confused. What uses what? And how can RSA work on DH? Coz the public key in DH is made by an exchange which is kinda symmetric unlike RSA which is Pure asymmetric Public/Private key crypto. Can you "Simply" put me in the right track? Thanks :-)

• Could you post where you get the ideas? RSA mostly used for signature, or key exchange named RSA-KEM. Also, Transport Layer Security (TLS) is the successor protocol to SSL. TLS is an improved version of SSL.  DH is not insecure, prone to mitm-attack which can be prevented with certificates. – kelalaka Sep 5 '19 at 21:57
• @C0DEV3IL: To RSA: Do you mean authenticated DH? – mentallurg Sep 5 '19 at 22:26
• Your questions are answered by googling, reading the wikipedia articles about the terms you don't understand, reading one of the many good answers on crypto.SE and security.SE for "how does SSL/TLS work?". – Z.T. Sep 6 '19 at 0:05

From what I understood before is that SSL uses DH and TLS uses RSA

Well, no.

First of all, there are a sequence of published versions of the SSL protocol:

SSLv2, SSLv3, TLS1.0, TLS1.1, TLS1.2, TLS1.3

(the name changed from SSL to TLS when the IETF started being in charge of it; Mozilla supposedly had an SSLv1 version internally, but they never published it).

Now, SSLv2 and SSLv3 use only RSA to perform key exchange; no other option.

When you get to TLS 1.0, they allowed you to select between RSA or Diffie Hellman (DH) to do key exchange; the general tendency over time has been to rely less on RSA and more on DH, until you get to TLS 1.3 (the most recent version) that entirely drops the use of RSA to do key exchange.

BTW: nowadays you shouldn't be using a version earlier than TLS 1.2, and using TLS 1.3 is generally accepted as best practice.

came to know DH and RSA are both secure/insecure

Well, both can certainly used insecurely; however done correctly, both are secure.

Coz the public key in DH is made by an exchange which is kinda symmetric unlike RSA which is Pure asymmetric Public/Private key crypto.

Well, no, DH is considered asymmetric crypto (well, both sides actually perform the same operation, however that's not what we mean by symmetric). In fact, DH was the first published asymmetric crypto protocol; that is, it was published in the same paper that Diffie and Hellman first publicly introduced the idea of public key crypto.

What it is not is a public key encryption algorithm (however, with a bit of tweaking, it can become one); each side has a private key (which, if leaks, breaks the security of the system) and a public key (which is the key share that is publicly sent over to the other side, and which we assume the attacker can learn).

• Got it nicely. But another thing. If RSA is completely abolished, what encryption is used where we could give the final key as the (Public) key and the internal key(s) as Private Key? Coz there are 2 private keys right? So is an asymmetric cipher even used? Thanks – C0DEV3IL Sep 5 '19 at 22:58
• SSL2 was RSA-encrypt-premaster only, but SSL3 (like TLS1.0-1.2) allowed DHE signed by RSA or DSA (spelled DSS). Although one important implementation, Windows through XP at least and thus Internet Explorer, supported DHE_DSS but not DHE_RSA, during a period when public CAs only issued RSA certs, making DHE problematic for many uses. – dave_thompson_085 Sep 6 '19 at 1:44
• @C0DEV3IL: TLS 1.3 always uses DH (or the elliptic curve version of DH), or Preshared Keys to derive symmetric keys (and again DH/ECDH is asymmetric crypto, it's just not a cipher). Also, RSA isn't completely abolished; it can (and is) still be used to generate signatures; it's just not used anymore as a public key encryption method. – poncho Sep 6 '19 at 15:50

DH in the classic form can be vulnerable to MITM, but the form used in TLS (SSL is deprecated, and hardly used any more, TLS is the more secure successor) is that the server sends its DH-contribution (and parameters used) to the client trying to connect, and these are signed by RSA and the server also presents a valid certifacate with its public key (backed by certificate authorities) so that the client can check the validity of that signature and then sends its contribution (now knowing the parameters and the reliability of the received data). Now both parties can compute a shared masterkey (which is then mutually verified (again to exclude MITM again) and used to derive the symmetric MAC and/or encryption keys).

So DH (often over elliptic curves in the modern suites) is used, but signed/verified by RSA signatures server side.

The most recent form of TLS does not use RSA for key transport anymore (because if the private RSA key is lost, all previous traffic can be decrypted retroactively) and so DH is preferred to create a fresh problem for each connection essentially. RSA is then only used in certificates and signatures for MITM protection and authentication.

• So you are saying the DH (elliptic Curve) is used completely, and RSA just for Certificates and Signatures. Now RSA isn't a HASH right? So are you saying that the RSA signature is actually encrypted? And the other question is, After the keys has been derived, What Cipher is used to actually encrypt normal data afterwords? – C0DEV3IL Sep 5 '19 at 23:01
• TLS1.0-1.2 allows DHE signed by RSA or DSA (but DSA is rarely used) and 'optionally' ECDHE (or X25519) signed by RSA or ECDSA (or EdDSA) (all are used). TLS1.3 allows DHE (but only rfc7919 groups) or ECDHE/X25519 (only a few standardized curves) signed by RSA-PSS or ECDSA/EdDSA.. – dave_thompson_085 Sep 6 '19 at 1:48
• @C0DEV3IL Typically an authenticated cipher is used in TLS1.3 (ChaCha20-Poly1305 or AES-GCM or AES-CCM) and SHA256 or SHA512 as a hash (for key derivation). TLS1.0-1.2 allows AES-CBC-HMAC-SHA256 as well and some other classical combos for the normal data. – Henno Brandsma Sep 6 '19 at 4:34