27

From my understanding, one of the major reasons we recommend Diffie-Hellman Ephemeral (e.g. DHE or ECDHE) over non-ephemeral DH, for SSL / TLS, is that compromise of the RSA private key (i.e. private certificate) would allow an attacker to decrypt previously captured conversations. In contrast, ephemeral should prevent decryption unless the attacker is in posession of the key at the time of the conversation.

How does this decryption of non-ephemeral Diffie-Hellman key exchange work in this context? Is it simply a case of observing the unencrypted primitives that are exchanged over the wire? If so, what is the point of using DH, if it provides no additional security over encrypting the key with RSA, and RSA already provides authentication of the server?

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 1
    I didn't look deeply into useless suites like fixed DH, but I think fixed-DH simply uses a signed DH key instead of an RSA key and thus has the essentially the same security properties. – CodesInChaos Jun 20 '13 at 19:35
  • I'm not exactly sure what you're asking,I've probably misunderstood the question but as far as the first part goes, if you have all the traffic logged, you have everything. You look for the handshake, decrypt the pre-master with the private key, together with the random bits sent in plaintext with the Hello messages you can derive the master key. Using the master key you can now decrypt the traffic of previously sessions. – Adi Jun 22 '13 at 21:49
  • @Adnan The difference is that DH ephemeral *doesn't* work that way. If you can *observe* the exchange data (e.g. through getting the private key at a later date), you still can't decrypt it. You have to have the key at the time and do a MitM attack, to learn the private exchange value of DHE. – Polynomial Jun 23 '13 at 15:42
  • @Polynomial But as far as I can see, you're asking about non-ephemeral DH. _"How does this decryption of non-ephemeral Diffie-Hellman key exchange work in this context?"_ also the title _"How does non-ephemeral Diffie-Hellman key exchange become compromised in SSL when the RSA private key is leaked?"_ – Adi Jun 23 '13 at 19:40
  • 1
    @Adnan Yes, but I'm asking what the *specific* difference is. Saying "you just capture the data" doesn't tell me the mechanism by which the secret is revealed, nor does it explain why DHE is immune to the same attack. I'm also interested in what benefit the non-ephemeral DH provides over plain RSA, since I don't see any. – Polynomial Jun 24 '13 at 08:40
  • @Polynomial I believe there's a miscommunication here. In any case, my information about this specific bit are coming from [the answers on the grand SSL question](http://security.stackexchange.com/questions/20803/how-does-ssl-work) and a [great article by Vincent Bernat](http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html). The article actually explains _exactly_ how the attack happens and why DHE/EDH is immune to the attack (the paragraph titled "Diffie-Hellman with discrete logarithm") – Adi Jun 24 '13 at 09:30

3 Answers3

25

First let's be sure that we talk about the same thing. In SSL, there are "ephemeral DH cipher suites" (DHE) and "non-ephemeral DH cipher suites" (DH).

With DHE, the server private key (the permanent one, the one which is stored in a file, and whose public key is in the server certificate) is of type RSA (DHE_RSA cipher suites) or DSS (DHE_DSS cipher suites), and is used only for signatures. The server generates a new random DH key pair (the private key will not be stored, which is how perfect forward secrecy is achieved: a private key cannot be stolen afterwards if it has never been stored), and sends the public key to the client, in a message which the server signs with its RSA or DSS private key.

With DH cipher suites, the permanent server private key is a DH private key. The server certificate contains the DH public key. The server cannot see its RSA key be stolen because the server does not have a RSA key. The server only has a DH key. When a cipher suites is called "DH_RSA", it means "the server key is a DH key, and the server certificate was issued (i.e. signed) by a Certification Authority who uses a RSA key".

Stealing the DH private key of one party involved in a DH key exchange allows ulterior reconstruction of the shared secret, just like RSA. In "ephemeral DH", the PFS is obtained through "ephemeral", not through "DH". Technically, it would be possible to have "ephemeral RSA" but it is not done in practice(*) because generating a new RSA key pair is kinda expensive, whereas producing a new DH key pair is cheap.

(*) Ephemeral RSA keys were possible with old versions of SSL as part of the "export" cipher suites, meant to comply with the pre-2000 US export regulations: the server could have a 1024-bit signature RSA key, and generate an ephemeral 512-bit RSA key pair for key exchange, used in encryption mode. I don't recall having ever seen that in the wild, though, and it is a moot point since US export regulations on key sizes were lifted.

Non-ephemeral DH cipher suites exist in order to allow servers with DH certificates to operate. DH keys in certificate exist because in older times, RSA was patented but DH was not, so standardization bodies, in particular NIST, were pushing DH as the must-implement standard.

Reality caught up with that, though. I have never seen a SSL server using a DH certificate. Everybody uses RSA. The RSA patent expired a decade ago anyway.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 1
    That makes SO MUCH more sense now. I had never considered the idea that the DH key pairs could be generated and thrown away per session. Thanks! :) – Polynomial Jun 28 '13 at 16:30
  • SSLv3 TLSv1.0 and 1.1 define DH_{RSA,DSS} as cert contains DH key and is signed (by CA) using RSA or DSA respectively, but **TLSv1.2 drops the ciphersuite-based restriction on cert signature** and adds an extension (SigAlgs) which restricts _all_ signatures; see 5246 7.4.2 just after the itemized list. And similarly for fixed-ECDH. – dave_thompson_085 Nov 07 '17 at 22:36
  • @TomLeek One correction maybe, I read the server certificate will not contain the DH public key. It is shared in a different **Server Key Exchange** message. Could you please confirm this? – Anonymous Platypus Jul 16 '18 at 11:57
  • @AnonymousPlatypus: no, **the bear was right** (as usual). ServerKX contains the ephemeral DH key for (very common) _ephemeral_ DHE_$auth (note the E) or 'anonymous' (DH_anon) keyexchange, but is not used at all for (very rare) 'static' DH_$obsauth (no E) which has the static/fixed key in the cert. See rfc5246 et pred 7.4.3 and 7.4.2. And similarly for ECDHE and ECDH_anon versus ECDH, see rfc4492. – dave_thompson_085 Jul 21 '18 at 14:37
4

For SSL/TLS, we need 2 things:

1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.

A few ways of doing both:

Most common: TLS_RSA_WITH_AES_...

RSA is used for both 1 (authentication) and 2 (computing symmetric key).

Preferred: TLS_DHE_RSA_WITH_AES_... or TLS_ECDHE_RSA_WITH_AES_...

RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).

Preferred, because you get Perfect Forward Security (PFS)

Not common: DH_RSA_... (this is the non-ephemeral DH in OP's question)

DH is used for both 1 (Authentication) and 2 (computing symmetric key).

The case you are referring to is the 3rd ("Not common") and as you can see, RSA is used neither for 1 (Authentication) nor for 2 (computing symmetric key) and so there is no question of RSA private key being leaked. The RSA in DH_RSA could be misleading but as Tom Leek mentioned, the Administrator of the server will provide credentials and their DH public key to a CA (Certificate Authority) who will then sign the DH public key with the CA's RSA private key.

Babu Srinivasan
  • 281
  • 1
  • 3
  • Maxim, by authentication, I mean that the client authenticates the server. Note that the server only presents a certificate, not proof that it has the corresponding private key. The client authenticates the server indirectly --- it generates a random pre-master-secret, encrypts it with server's RSA public key and sends it to server. Both the client and server can compute the master secret using the pre-master secret. Only the legitimate server will have the RSA private key to decrypt the encrypted pre-master secret and compute the same master secret. Refer to Section 7.4.7.1 of RFC 5246 – Babu Srinivasan Apr 14 '20 at 22:56
  • Maxim, the client encrypts the pre-master secret and sends it to the server, not the other way around. – Babu Srinivasan Apr 14 '20 at 23:01
  • You wrote that RSA is used for “1 (authentication)”. What do you mean here by “authentication” in terms of using the RSA key data from the server’s certificate? There is only one operation where this key is used, not two as you wrote. In “TLS_RSA_WITH_AES_...” it is only used for “key transport” (the client encrypts, and the server decrypts the “premaster secret”), while in “TLS_(EC)DHE_RSA_WITH_AES_...” it is only used to sign by the server (and verify by the client) the ephemeral key, as you correctly pointed out. – Maxim Masiutin Apr 15 '20 at 17:33
  • Thank you for the explanation. I've got what you mean. By authentication you've meant that by verifying server’s certificate, the client uses the server’s public key from that certificate to authenticate the server. The client later uses the same public key for key transport or key agreement (in old non-ephemeral mode) or to verify ephemeral key sent by the server. The RFCs on various version of TLS in this context contain phrases like “If RSA is being used for key agreement and authentication”…. – Maxim Masiutin Apr 15 '20 at 17:45
  • Of course the client encrypts the pre-master secret and sends it to the server, not the other way around, thank you for spotting that wrong order of words in the comment. – Maxim Masiutin Apr 15 '20 at 17:47
  • 1
    Maxim, there is only one step and not 2 steps. This is why I said "The client authenticates the server indirectly". A bogus server will not be able to decrypt the encrypted pre-master secret and so authentication fails. Only the legitimate server has the RSA private key, the fact that it can decrypt and get the pre-master secret and compute same symmetric keys to encrypt/decrypt traffic is proof that the server is who it claimed to be in the certificate. As only one party (the client) generates the pre-master secret, this is called key-transport and not key exchange. This is TLS_RSA_WITH_AES. – Babu Srinivasan Apr 15 '20 at 19:34
  • 1
    Maxim, in TLS_(EC)DHE_RSA_WITH_AES (ephemeral diffie hellman), the server, in addition to presenting certificate that contains its RSA public key, it also signs its ephemeral DH parameters with its RSA private key and sends it to client. Client uses server's RSA public key to verify the signature on the DH parameters. If signature check succeeds, authentication succeeds and client sends its ephemeral DH parameters to server. Both parties use the DH parameters to compute the same pre-master secret. As both parties contribute material to compute the pre-master secret, this is called key exchange – Babu Srinivasan Apr 15 '20 at 19:34
0

You've asked about the use of non-ephemeral (static) Diffie-Hellman key exchange and its advantages or disadvantages over encrypting the key session key (premaster secret) with RSA.

In TLS_DH_RSA_WITH_... the signature algorithm (RSA/DSS) indicates the signature algorithm the CA used to sign the certificate and there is no signature as part of the handshake; if the server arrives at the same session key, then it must have the matching DH private key. (Mike Ounsworth)

Thus the "RSA" or "DSS" part in the "TLS_DH_" cipher suite is misleading. It only denotes an algorithm used by the CA to sign the DH parameters (public key), not the actual signature algorithm used during TLS handshake.

In “TLS_DH_” cipher suites, there are two ways for the client to provide its public DH parameters (public key) to the server:

  1. via the client certificate;
  2. via the ClientKeyExchange message of ClientDiffieHellmanPublic type.

If the client has sent a certificate which contains a suitable Diffie-Hellman key (for fixed_dh client authentication), then Yc is implicit and does not need to be sent again. In this case, the client key exchange message will be sent, but it MUST be empty. (RFC 5246, 7.4.7.2)

When using static Diffie-Hellman with a client certificate, you get mutual authentication in one shot, because a client certificate and a server certificate are used to generate the session keys.

DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). [...] The server [...] request a Diffie-Hellman certificate. Any Diffie-Hellman certificate provided by the client must use the parameters (group and generator) described by the server. (Section A.5 of RFC 5246)

Note that certificates with DH parameters are rather rare anyway.

In theory, if you compare speed and security of DH vs RSA, there are no major differences (nevertheless, there are some details).

In practice, since public CAs no longer issue certificates with the DH parameters, you cannot use "TLS_DH_" cipher suites, so RSA is the only choice between the two non-PerfectForwardSecrecy algorithms that you have mentioned.

Community
  • 1
Maxim Masiutin
  • 182
  • 1
  • 7