2

I have heard that with forward secrecy that the ECDSA ciphers generate different keys for "each session" because they are not dependent on the private key of the server. My question is how is "each session" defined? Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?

user53029
  • 2,657
  • 5
  • 24
  • 35

2 Answers2

2

Forward Secrecy

The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.

Perfect Forward Secrecy (PFS)

PFS holds true above, but satisfies the two properties below:

  • Generates random public keys per session for the purposes of key agreement
  • Does not use any sort of deterministic algorithm in doing so

Addressing your questions in SSL/TLS

How is "each session" defined?

Ephemeral Diffie Hellman is used for PFS. Using Ephemeral Diffie Hellman (DHE/ECDHE) forces each session to renegotiate its DH parameter every time a single SSL session closes. So "each session" quite literally means as soon as the session ends the keys are destroyed. No session IDs are stored by the server, so new keys are forced each time.

Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?

Doesn't matter if its the same server, or a server side re-negotiation the server shouldn't have cached session keys. So new DH parameters are needed with *DHE cipher suites. Now this is how the theory works. Configuration is kind of a different story. Some servers might have to disable session resumption to ensure this occurs.

RFC5246: TLS 1.2 Standard

Implementations SHOULD generate a new X for each handshake when using DHE cipher suites.

A related question and answer.

Community
  • 1
RoraΖ
  • 12,317
  • 4
  • 51
  • 83
  • Am I correct that RSA can create only the same symmetrical key each session because of the static public and private keys? – ipeacocks Feb 20 '17 at 23:07
  • @ipeacocks RSA doesn't generate symmetric keys. Symmetric keys are generated separately and then encrypted with RSA. Since the keys are unique the RSA encryptions are as well. – RoraΖ Feb 21 '17 at 00:48
  • @RoraZ but technically (by design) RSA can generate symmetric keys and sign them? Thanks to Diffie-Hellman exchange keys are counted on hosts. Per my understanding DH process is enough for symmetric key generation and RSA only signs each stage (for understanding who is who) of its generation. Am I correct? – ipeacocks Feb 21 '17 at 06:45
  • 1
    @ipeacocks RSA does not generate symmetric keys. It generates asymmetric keys where the encryption key is public and the decryption key is private. It is not symmetric encryption/decryption. DH negotiates asymmetric keys that are unique to each session, and is used as the pre-master secret in TLS. This along with several other pieces of information is used to generate the master secret which then produces symmetric keys. All of this is authenticated with RSA. [This answer](http://security.stackexchange.com/a/41226/52676) might help clarify things. – RoraΖ Feb 21 '17 at 13:21
1

Each session means each SSL session. An SSL session can be reused over multiple TCP connections (that is SSL connections) if both client and server implement session reuse and each of the SSL connections gets closed in a clean way.

A SSL connection might also consist of multiple SSL sessions if you do multiple full SSL handshakes within the same connection.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • What about an existing SSL connection where the server request renegotiation where each party stops exchanging data in order to renegotiate how the communication is secured? – user53029 Aug 20 '14 at 13:08
  • Renegotiations are secured by the already established session. – Steffen Ullrich Aug 20 '14 at 13:41
  • @SteffenUllrich For PFS new DH parameters should be generated for each handshake using DHE cipher suites. Unless I'm missing understanding how PFS is supposed to work. – RoraΖ Aug 20 '14 at 14:34
  • Yes, with each full handshake a new session with a new session key is created. But a full handshake is not done when you resume a session. – Steffen Ullrich Aug 20 '14 at 16:51
  • @SteffenUllrich true, but if the server is not keeping session IDs (as should be done with PFS) then it will force a full handshake. – RoraΖ Aug 25 '14 at 12:49
  • The server can keep session IDs with PFS too. But, it should not write them to disk like apache can do to share them between multiple machines, because it is really hard to remove them forever once they are on disk. – Steffen Ullrich Aug 25 '14 at 13:00