How does perfect forward secrecy (PFS) work

In a non-PFS session the browser decides on the session key (or rather secret from which it is derived) and encrypts it using RSA, with the RSA public key obtained from a certificate that belongs to the server. The certificate is also used to authenticate the server. The server then uses its private key (what you call master key) to decrypt the session key. All connections to the server use different session keys, but if you possess the master key you can figure them all out, the way the server does. In PFS you use algorithms such as Diffie-Hellman, where the master key is not used. In such connection the master key is used to authenticate the parameters for the algorithm. After the parameters are agreed on, the key exchange takes place using those parameters, and a secret of both parties. The parameters are not secret, and the secrets the parties used are discarder after the session key is established (ephemeral). This way if you discover the master key you cant discover the session key. However you can pose as the server if you get the key, and the certificate is not invalidated. To find out more read about Diffie-Hellman.

I really like the answer on Quora given by Robert Love: http://www.quora.com/What-is-perfect-forward-secrecy-PFS-as-used-in-SSL

Let's look at how key exchange works in the common non-ephemeral case. Instead of giving a practical example using, say, Diffie-Hellman, I'll give a generalized example where the math is simple:

Alice (client) wants to talk to Bob (server).

Bob has a private key X and a public key Y. X is secret, Y is public.

Alice generates a large, random integer M.

Alice encrypts M using Y and sends Y(M) to Bob.

Bob decrypts Y(M) using X, yielding M.

Both Alice and Bob now have M and use it as the key to whatever cipher they agreed to use for the SSL session—for example, AES.

Pretty simple, right? The problem, of course, is that if anyone ever finds out X, every single communication is compromised: X lets an attacker decrypt Y(M), yielding M. Let's look at the PFS version of this scenario:

Alice (client) wants to talk to Bob (server).

Bob generates a new set of public and private keys, Y' and X'.

Bob sends Y' to Alice.

Alice generates a large, random integer M.

Alice encrypts M using Y' and sends Y'(M) to Bob.

Bob decrypts Y'(M) using X', yielding M.

Both Alice and Bob now have M and use it as the key to whatever cipher they agreed to use for the SSL session—for example, AES.

(X and Y are still used to validate identity; I'm leaving that out.)

In this second example, X isn't used to create the shared secret, so even if X becomes compromised, M is undiscoverable. But you've just pushed the problem to X', you might say. What if X' becomes known? But that's the genius, I say. Assuming X' is never reused and never stored, the only way to obtain X' is if the adversary has access to the host's memory at the time of the communication. If your adversary has such physical access, then encryption of any sort isn't going to do you any good. Moreover, even if X' were somehow compromised, it would only reveal this particular communication.

That's PFS.