2

During ssl key exchange, I have read that sending the symmetric key to the server encrypted with the server's public key is an old technique. Now for key echange Diffie hellman and other techniques are used.
My question is why is key echange using the seerver's public key outdated? What are it's shortcomings?

user1166690
  • 177
  • 2
  • 4
  • 1
    The symmetric key is never 'sent to the server encrypted with the server's public key' in SSL. What are you talking about? – user207421 Apr 22 '12 at 23:25
  • 1
    (EC)DHE offers Perfect forward privacy, the older suites don't. – CodesInChaos Apr 23 '12 at 12:49
  • 1
    @EJP It doesn't? I thought the plain RSA suites work pretty much like that. There are a few extra steps complicating the issue, but I believe the essence of this key-exchange is encrypting a symmetric secret with the servers public key. – CodesInChaos Apr 23 '12 at 12:53
  • 2
    @CodeInChaos. It doesn't, it exchanges a pre master secret, then used to [compute the master secret](http://tools.ietf.org/html/rfc4346#section-8.1), then used for the [key calculation](http://tools.ietf.org/html/rfc4346#section-6.3). (Saying it's exchanging the secret key directly is an approximation, which I guess is fair when this degree of details is not required.) – Bruno Apr 23 '12 at 13:11
  • @EJP:I already asked in comments for this but I have been able to dechypher an encrypted stream using the server's private key and wireshark. But I couldn't do it for DH. I assumed that with RSA suites the server's key is used to encrypt the shared key. And that is why I managed to decrypt the traffic. So you are saying that it is the way that RSA exchanges secrets makes it possible to calculate the shared key even if not transmitted? – Jim Apr 23 '12 at 17:13
  • @Jim Instead of this 'so are you saying' game, I will restate. The session key is not generated by the client; not encrypted; not transmitted; and not decrypted. What is generated is the pre-master secret, which leads to a master secret for the session, which leads to all the session keys. Given the private key, Wireshark can follow the extensive process that results in a session key. But that consists of far more than merely generating it at the client and encrypting it with the server's private key. The first sentence of the question refers to nothing in the real world. – user207421 Mar 20 '17 at 19:20

3 Answers3

8

The distinction is not so much a matter between Diffie-Hellman and RSA key exchange generally, rather it's about being able to use Ephemeral Diffie-Hellman, which use ephemeral (i.e. new) parameter every time. (It's also possible to use fixed DH parameters, but I'm not sure I've ever seen it.)

Essentially, if you record the encrypted traffic and later on get hold of the server's private key, an RSA cipher suite, you can later on decipher the entire traffic straight away (e.g. using Wireshark's SSL tools).

In contrast, using EDH, new random DH keys are (or should be) generated every time on each side. Those parameters are not recorded and not visible on the wire, which provides Perfect Forward Secrecy (PFS). This is why deciphering EDH cipher suites are not supported in Wireshark. Reasonably recent versions of Wireshark can decipher traffic that uses EDH cipher suites, but you need to get hold of the pre-master secret (every time). (See "Using the (Pre)-Master-Secret" section of the Wireshark SSL wiki page and this question here.)

(Whether it's actually perfect is not clear, but it adds another random space that an attacker may have to brute force.)

You can find more details in this RSA Security Inc. document or at the end of this section of the TLS specification.

Community
  • 1
Bruno
  • 10,875
  • 1
  • 39
  • 61
  • So the server's public key is never used? – user1166690 Apr 23 '12 at 04:30
  • @Bruno : According to the link you gave, Ephemeral Diffie-Hellman does not provide authentication. So for authentication you need server's certificate, which is signed by the ca's private key. You will have to verify it using the the ca's public key. So there is no role of server's public key in this right? – Ashwin Apr 23 '12 at 08:40
  • @Ashwin, read "*F.1.1.3. Diffie-Hellman Key Exchange with Authentication*" again. You get authentication because the server signs its parameters with its key. The server's public key is then used by the client for verifying that signature, which provides authentication. – Bruno Apr 23 '12 at 09:27
  • @Bruno : okay.. got it! So the server's public key is used only to authenticate, not to encrypt the symmetric key. – Ashwin Apr 23 '12 at 10:04
  • 1
    @Ashwin, as EJP was saying, the symmetric key is never exchanged anyway. With RSA key exchange, the client uses the server's public key to encrypt the pre master secret; with the EDH key exchange, the client uses the server's public key to verify the DH parameters signed by the server (in server key exchange). – Bruno Apr 23 '12 at 10:12
  • @Bruno : So in RSA keyexchchange, if the attacker figures out the pre master secret, will he be able to figure out the master secret also. – Ashwin Apr 23 '12 at 11:02
  • 2
    @Ashwin, you always want the pre master secret to be secret. With RSA key exchange, an attacker in possession of the client key exchange message and the server's private key will be able to get it (and thus to get the values of the shared key); with EDH, that's not enough. – Bruno Apr 23 '12 at 11:08
  • @Bruno : if using a premaster secret a master secret can be derived, then why use a pre-master secret. Why not directly encrypt the master secret – Ashwin Apr 23 '12 at 11:11
  • @Bruno:I have been able to dechypher an encrypted stream using the server's private key and wireshark. But I couldn't do it for DH. I assumed that with RSA suites the server's key is used to encrypt the shared key. And that is why I managed to decrypt the traffic. So you are saying that it is the way that RSA exchanges secrets makes it possible to calculate the shared key even if not transmitted? – Jim Apr 23 '12 at 17:12
  • 2
    @Jim Yes, the shared keys are derived from the pre master secret and random numbers visible in the hello messages. The goal is to get the pre master secret, which will give you everything. When RSA key exchange is used, by having simply the traffic and the server's private key, you can get the pre master secret and get the rest (see [this example](http://stackoverflow.com/a/10247166/372643)). In contrast, even with the server's private key, you can't find the common pre master secret at the end of the DH exchange by just looking at the traffic. – Bruno Apr 23 '12 at 17:34
  • @Bruno:So is RSA cipher suites considered less secure than DH? I don't recall a recommendation to opt to use DH instead of RSA. Is there such a recommendation? – Jim Apr 23 '12 at 17:52
  • @Bruno: I mean since a stream with RSA can be decrypted if private key has been stolen while a stream with DH can not, doesn't that have an implication on which cipher suite is best? – Jim Apr 23 '12 at 18:18
  • @Jim, as far as I know RSA key exchange hasn't been deprecated as far as IETF is concerned, but [this NIST document](http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf) says: "*For maximum security, RSA or DSA authentication with ephemeral Diffie-Hellman key agreement is recommended*". – Bruno Apr 23 '12 at 18:44
  • 1
    Ephemeral Diffie-Hellman doesn't have to use new DH parameters (i.e. discrete logic group) every time, it merely has to use a new key pair. i.e. in the RFC 4346 section you reference, emphemeral DH requires a new X, but the parameters g and p can safely be reused. – armb Apr 25 '13 at 13:21
  • @armb yes, I meant DH parameters in the sense used in [the specification](http://tools.ietf.org/html/rfc4346#section-7.4.3) (i.e. `ServerDHParams`). Indeed, not everything needs to change, just `X` and therefore `dh_Ys`. – Bruno Apr 25 '13 at 15:57
1

I think you misunderstood what you read, or you got some bad information. Your premise is not accurate.

You said "sending the symmetric key to the server encrypted with the server's public key" is outdated. That is not accurate. There's nothing wrong with this way of doing key exchange. In fact, most SSL sessions that are negotiated today use exactly this technique. There's nothing outdated or problematic with it.

You also said "Now for key exchange Diffie Hellman and other techniques are used." If you meant that Diffie-Hellman has replaced the traditional method of encrypting the symmetric key under the server's public key, then this is not accurate either. Diffie-Hellman has not replaced those methods. The Diffie-Hellman approach is fine and valid too, but it is not accurate to say that Diffie-Hellman is somehow newer (in fact, it is older) or that it has replaced other methods.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • The session key is neither encrypted nor transmitted. – user207421 Mar 20 '17 at 19:22
  • @EJP, [citation needed]. In other words: I don't know what you're trying to say, or what justification you have. In RSA ciphersuites, the session key *is* encrypted and then transmitted to the server. (That's not true for Diffie-Hellman, but I never claimed it was.) – D.W. Mar 20 '17 at 21:14
  • My citation is RFC 2246 #8.1. What's yours? – user207421 Oct 26 '17 at 10:19
-1

I would imagine at the core of it, if it is not put on the wire, it cannot be sniffed, and is harder to break. I can imagine a scenario like this: An attacker somehow gets in the middle of the communication between the server and clients, and logs all data. After awhile, the attacker is able to compromise the server's certificate, obtaining its private key. With that, all captured SSL sessions can be compromised, since the shared secret can then be decrypted.

Diffie-Hellman prevents this, with each party having a secret, and another bit of data relating to that secret that is considered public. Once one party has received the public piece of the other party, a bit of fancy math is done that generates a number that is related to both secrets, but is not obtainable from the public information. So, in short, the DH key exchange can be sniffed, but the shared secret cannot be obtained.

In the above scenario, unless the attacker compromises the server itself, and installs a modified version of the SSL suite that logs the shared secrets (a much trickier task. Getting the full certificate may just involve social engineering, or compromising another box), the captured SSL sessions are still safe, since the shared secret is never put on the wire on any form.

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
Matt Sieker
  • 107
  • 1
  • Not an answer (pre- or post-edit). You're still misreading the question. The question is why there are *multiple* key exchange techniques in the protocol. – user207421 Apr 22 '12 at 23:23
  • @Matt Sieker : Like EJP siad not as answer(pre- or post-edit). – Ashwin Apr 23 '12 at 09:08