Perfect Forward Secrecy

• Introduction To Perfect Forward Secrecy

The idea of ‘Perfect Forward Secrecy’, or sometimes simply ‘Forward Secrecy’, is that something that in encrypted and so considered ‘secret’ now, should remain encrypted and so not easier discovered in the future. If there is a means whereby the ‘secret’ can be revealed in the future, then there is no ‘forward secrecy’, meaning that while the information may be protected now, it may not be at some future point in time.
Secure online web communication is based on SSL or its more recent derivative, TLS. These are based on a mixture of Public/Private key asymmetric cryptography and symmetric key encryption. Of course with the disclosure of the POODLE SSL 3.0 vulnerability, SSL is now effectively dead
If the private key is ever disclosed, even in the future, it is possible to go back and decrypt entire key exchange conversation and from that obtain the encryption key used for the symmetric encryption used for the remainder of the ‘secure’ session.
This holds true of every SSL/TLS session using that private key. Even though each secure session will have used a separate and quite different symmetric encryption key, they will all have agreed and set that unique key using the single private key and so possession of that single private key allows discovery of all the separate symmetric encryption keys and with them the decryption of every secure communication exchange with that server.
Perfect Forward Security is designed to overcome this inherent weakness and is so-called as it protects a secure message exchange from future disclosure by breaking of the encryption due to loss or disclosure of the private key used in the key exchange.It achieves this by extending the key exchange mechanism and using an intermediate temporary encryption to protect the exchange of the symmetric encryption key. This means a future loss or disclosure of the private key can no longer be used to decrypt the secure message

Implementation of PFS

SSL and TLS are essentially frameworks for the establishing of a secure communication channel. They do not mandate the actual encryption cipher that must be used nor the means of key exchange. These are mutually agreed between the client and the server during the initiation of each secure connection.

‘server gating’
This is how, for instance, ‘server gating’ operates where a server can mandate that only certain cipher suites may be used. The connection negotiation therefore includes an exchange of information about which cipher suites the client can support and the server then selects a preferred scheme to be used for the session. The server may also decline all offered cipher suites and in effect say; “I’m sorry, but you are not able to offer a suitably secure cipher suite for me to talk to you” – sever gating in practice.
Therefore, to implement PFS it is necessary to make suitable cipher suites available on the server receiving the connections and for the client – typically a browser – to support the matching cipher suites.

PFS-compliant key exchange mechanisms that are available include:

ECDHE_RSA - Ephemeral Elliptic Curve Diffie-Hellman with RSA signatures
DHE_RSA - Ephemeral Diffie-Hellman with RSA signatures
https://www.ciso-central.org/transport-layer-security/perfect-forward-secrecy

• When you use the RSA key exchange mechanism, it creates a link between the server’s key pair and the session key created for each unique secure session. Thus, if an attacker is ever able to get hold of the server’s private key, they can decrypt your SSL session and any saved SSL sessions.

In contrast, when you enable Perfect Forward Secrecy (PFS), there is no link between your server’s private key and each session key. If an attacker ever gets access to your server’s private key, the attacker cannot use the private key to decrypt any of your archived sessions, which is why it is called “Perfect Forward Secrecy”.
Deploying Perfect Forward Secrecy
Instead of using the RSA method for exchanging session keys, you should use the Elliptic Curve Diffie-Hellman (ECDHE) key exchange. Note that you can still use the RSA public-key cryptosystem as the encryption algorithm, just not as the key exchange algorithm. ECDHE is much faster than ordinary DH (Diffie-Hellman), but both create session keys that only the entities involved in the SSL connection can access. Because the session keys are not linked to the server’s key pair, the server’s private key alone cannot be used to decrypt any SSL session.
Configuring Apache for Forward Secrecy
Configuring Nginx for Forward Secrecy
https://www.digicert.com/ssl-support/ssl-enabling-perfect-forward-secrecy.htm

• Deploying Perfect Forward Secrecy

Instead of using the RSA method for exchanging session keys, you should use the Elliptic Curve Diffie-Hellman (ECDHE) key exchange. Note that you can still use the RSA public-key cryptosystem as the encryption algorithm, just not as the key exchange algorithm. ECDHE is much faster than ordinary DH (Diffie-Hellman), but both create session keys that only the entities involved in the SSL connection can access. Because the session keys are not linked to the server’s key pair, the server’s private key alone cannot be used to decrypt any SSL session.

Configuring Apache for Forward Secrecy
Before you configure your Apache server for Forward Secrecy, your web server and SSL/TLS library should support Elliptic Curve cryptography (ECC).
Minimum Required Versions
OpenSSL 1.0.1c+
Apache 2.4x

Configuring Nginx for Forward Secrecy
Before you configure your Nginx server for Forward Secrecy, your web server and SSL/TLS library should support Elliptic Curve cryptography (ECC).
Minimum Required Versions
OpenSSL 1.0.1c+
Nginx 1.0.6+ and 1.1.0+

https://www.digicert.com/ssl-support/ssl-enabling-perfect-forward-secrecy.htm#apache_forward_secrecy

• DROWN is a cross-protocol attack that exploits vulnerabilities in the SSLv2 implementation against transport layer security (TLS), the attacks doesn’t work against the SSLv2 connections.

DROWN exploits a bug in SSLv2 protocol implementation to attack the security of connections made under a different protocol, in this case, TLS.
Users need to update their OpenSSL to the newer versions 1.0.2g or 1.0.1s. In order to avoid the attack, it is possible to disable the SSLv2, as well as make sure that the private key isn’t shared across any other servers.
https://securityaffairs.co/wordpress/44945/hacking/drown-attack.html

• Hacker Lexicon: What Is Perfect Forward Secrecy?

To solve that problem of future security mistakes threatening past secrets, cryptographers have come up with a security feature called “perfect forward secrecy.
For perfect forward secrecy to offer its intended protection in messaging apps, the user needs to periodically delete their decrypted messages or move them to a more secure device. Signal recently added a feature to allow self-destructing messages, which takes care of that for you.
Every modern browser is capable of initiating perfect forward secrecy with a compatible HTTPS-encrypted site. 

https://www.wired.com/2016/11/what-is-perfect-forward-secrecy/

• What does this have to do with Heartbleed?

The Heartbleed bug allows an attacker to extract data from the memory of a vulnerable server. This includes things like usernames, passwords, email addresses, session data and worst of all, the server's private key. Once the private key has been compromised, there are 2 big problems. First up, an attacker can impersonate the server by presenting the certificate that it now has the private key for. This problem can be dealt with by revoking the certificate in question so that browsers know not to trust it. Secondly, they can intercept and decrypt traffic. If an attacker has been recording encrypted traffic and storing it, once they gain access to the private key, they can go back and decrypt all of the data that they have intercepted in the past. So, let's say someone like the NSA or GCHQ has been recording the traffic to and from my blog for the last year, Heartbleed comes along and gives them access to my private key, it's game over.  All that historic data is now vulnerable. This is what Perfect Forward Secrecy prevents. Because the data used to generate each session key is never actually sent over the transport layer, even with access to the private key, there isn't actually any useful information for an attacker to decrypt. They will still have to break each individual session key for each individual session, which, as it stands right now, is an insurmountable task.

How does Perfect Forward Secrecy help?

To enable PFS, the client and the server have to be capable of using a cipher suite that utilises the Diffie-Hellman key exchange. Importantly, the key exchange has to be ephemeral. This means that the client and the server will generate a new set of Diffie-Hellman parameters for each session. These parameters can never be re-used and should never be stored, the ephemeral part, and that's what offers the protection going forwards. Because of the magic behind Diffie-Hellman, the exchange of key material can take place in clear text without compromising the generation of a shared secret. The math is a little too heavy to detail in this blog post but there is a great example here on Wikipedia. Because the shared secret, the session key, is derived from complex mathematical operations carried out on the numbers exchanged between the client and the server, that are too difficult for an attacker to brute force, the attacker can at no point record data that is used to derive the session key. Even if the private key of the server is compromised, it doesn't aid the attacker in decrypting any data because the associated public key was never used to protect anything. What's even better is that with Perfect Forward Secrecy, the server generates a new set of Diffie-Hellman parameters for each session and both parties create a new shared secret that is unique and unknown to an attacker. Even if the attacker managed to compromise this shared secret somehow, it would only compromise that particular session. No previous or future sessions would be compromised

https://scotthelme.co.uk/perfect-forward-secrecy/

• What is keyless SSL?

Keyless SSL is a service for companies that use a cloud vendor for SSL encryption.

Usually this would mean that the cloud vendor has to know the company's private key, but keyless SSL is a way to circumvent that.

For regulatory reasons many organizations cannot share their private keys

SSL, more accurately known as TLS, is a protocol for authenticating and encrypting communications over a network.

SSL/TLS requires the use of what's called a public key and a private key, and in the case of a company using the protocol to secure traffic to and from their website (see HTTPS), the private key typically remains in the company's possession.

But when a company moves to the cloud and a vendor provides TLS encryption, the vendor has the private key instead.

By moving the part of the handshake involving the private key off of the vendor's server, the private key can remain securely in the company's possession. Instead of using the private key directly to generate session keys, the cloud vendor gets the session keys from the company over a secure channel and uses those keys to maintain encryption. Thus, a private key is still used, but it is not shared with anyone outside the company.

For instance, suppose that Acme Co. implements SSL. Acme Co. will securely store their private key on a server that they own and control. If Acme Co. moves to the cloud and uses a cloud service provider for web hosting, that vendor will then have the private key. However, if Acme Co. moves to the cloud with a vendor that implements keyless SSL instead, the private key can stay on the server that Acme Co. owns and controls, as in the non-cloud SSL implementation.

How does keyless SSL work?

Keyless SSL is based on the fact that there is only one time when the private key is used during the TLS handshake, which occurs at the beginning of a TLS communication session. Keyless SSL works by splitting the steps of the TLS handshake up. A cloud vendor offering keyless SSL moves the private key part of the process to another server, usually a server that the customer keeps on premises.

When the private key becomes necessary during the handshake for decrypting or encrypting data, the vendor's server forwards the necessary data to the customer's private key server. The private key encrypts or decrypts the data on the customer's server and sends the data back to the vendor's server, and the TLS handshake continues like usual.

Keyless SSL is only "keyless" from the cloud vendor's point of view: they never see their customer's private key, but the customer still has and uses it. Meanwhile, the public key is still used on the client side like normal.

https://www.cloudflare.com/learning/ssl/keyless-ssl/