Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Apr 23 '12 at 12:09

This question came from our site for professional and enthusiast programmers.

The symmetric key is never 'sent to the server encrypted with the server's public key' in SSL. What are you talking about? –  EJP Apr 22 '12 at 23:25
(EC)DHE offers Perfect forward privacy, the older suites don't. –  CodesInChaos Apr 23 '12 at 12:49
@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
@CodeInChaos. It doesn't, it exchanges a pre master secret, then used to compute the master secret, then used for the key calculation. (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 Why not just offer clarification? It is, after all, a help forum. Nobody cares how many years you spent on Usenet if you aren't willing to offer your knowledge HERE. This isn't 'other parts of the internet'. RTFM isn't an acceptable answer here. –  KyleM Apr 25 '13 at 16:20

3 Answers 3

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.

share|improve this answer
So the server's public key is never used? –  user1166690 Apr 23 '12 at 4: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 8:40
@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
@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). 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
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

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.

share|improve this answer

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.

share|improve this answer
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. –  EJP Apr 22 '12 at 23:23
@Matt Sieker : Like EJP siad not as answer(pre- or post-edit). –  Ashwin Apr 23 '12 at 9:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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