1

A vulnerability report states the following:

The server is configured to support ciphers known as static key ciphers. These ciphers don't support "Forward Secrecy". In the new specification for HTTP/2, these ciphers have been blacklisted.

From what I could find, the lack of forward secrecy is due to the fact that multiple sessions use the same key.

My question is: How/where are the keys persisted and for how long? Can this compromise sessions which will happen in a relatively far future, say half a year from now?

0
1

From what I could find, the lack of forward secrecy is due to the fact that multiple sessions use the same key.

This is not about using the same key inside multiple sessions.

All ciphers using the RSA key exchange lack Forward Secrecy since an attacker could passively sniff the traffic and later decrypt the sniffed traffic if the attacker gets access to the servers private key. This is not possible with ciphers using Diffie-Hellmann (DHE, ECDHE), i.e. these ciphers provide Forward Secrecy.

Or as written at Wikipedia:

A public-key system has the property of forward secrecy if it generates one random secret key per session to complete a key agreement, without using a deterministic algorithm.

With RSA key exchange there is a deterministic algorithm based on the servers private key, with DH there is no such determinism.

How/where are the keys persisted and for how long?

Forward Secrecy (or lack of) is not about the persistence of the keys but about the ability to recreate the keys in a deterministic way, in case of RSA key exchange based on the private key of the certificate.

Can this compromise sessions which will happen in a relatively far future, say half a year from now?

This is about a "compromise" of a session but that the encryption keys can be recreated if the session was sniffed and later the private key gets known. This can be years after the session got sniffed.

2
  • I found this too while trying to find out how it works, but unfortunately, it does not answer my questions. Perhaps it would be useful to establish what is understood as a 'session' in this context?
    – JohnEye
    Sep 11 '17 at 13:45
  • @JohnEye: I've edited the question to make it more clear. Forward Secrecy is not about sessions in the first place so there is no need to argue what we consider a session. Sep 11 '17 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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