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?

Improve this question
6
  • 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, 2012 at 23:25
  • 1
    (EC)DHE offers Perfect forward privacy, the older suites don't.
    – CodesInChaos
    Apr 23, 2012 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, 2012 at 12:53
  • 2
    @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, 2012 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, 2012 at 17:13

3 Answers 3

Reset to default
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.

Improve this answer
15
  • So the server's public key is never used?
    – user1166690
    Apr 23, 2012 at 4:30
  • 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, 2012 at 10:12
  • 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, 2012 at 11:08
  • 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). 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, 2012 at 17:34
  • 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, 2013 at 13:21
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.

Improve this answer
3
  • The session key is neither encrypted nor transmitted.
    – user207421
    Mar 20, 2017 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, 2017 at 21:14
  • My citation is RFC 2246 #8.1. What's yours?
    – user207421
    Oct 26, 2017 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.

Improve this answer
2
  • 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, 2012 at 23:23
  • @Matt Sieker : Like EJP siad not as answer(pre- or post-edit).
    – Ashwin
    Apr 23, 2012 at 9:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .