Dat is op zich correct, maar niet specifiek voor Forward Secrecy.

Ook bij de "oude" methode, meestal RSA, wordt voor elke sessie een unieke encryptiesleutel gegenereerd en na afloop verwijderd (op de server en client). Het werkt, enigszins vereenvoudigd, als volgt.

1) RSA Key Exchange
- De server stuurt het certificaat met daarin de public key naar de client (webbrowser);
- De webbrowser genereert een groot random getal. Simpel gesteld wordt dat de symmetische
  encryptiesleutel waarmee al het uitgewisselde http verkeer (de "sessie") zal worden versleuteld;
- De webbrowser versleutelt dat getal met de public key uit het server certificaat en stuurt het naar de server;
- Omdat alleen de server over de private key beschikt (behorende bij de public key in het certificaat), kan
  uitsluitend de server dat grote getal ontcijferen (m.b.v. die private key);
- Daarmee kennen zowel server als client de te gebruiken symmetrische encryptiesleutel. Natuurlijk kan er
  alleen informatie worden uitgewisseld als beide partijen dezelfde sleutel kennen. Een nep-server kan ook
  zelf een random getal bedenken, maar alles wat daarmee versleuteld wordt kan de client niet ontcijferen
  en vice versa. Impliciet wordt hiermee authenticatie van de server afgedwongen.

Hierboven vinden twee zaken gelijktijdig plaats:
1) De server authenticeert zich door te bewijzen dat hij het random getal kan decrypten;
2) Er wordt een symmetrische encryptiesleutel uitgewisseld (versleuteld met de public key van de server)
    waarmee uitendelijk al het netwerkverkeer tijdens de sessie versleuteld wordt.

Nb. een van de redenen dat het feitelijke http verkeer met symmetrische encryptie (zoals RC4, 3DES, AES, Camellia etc.) wordt beveiligd (lees: in https wordt omgezet), is dat dit veel sneller is dan asymmetrische encryptie (gedoe met private en public keys kost veel CPU performance).

2) Diffie-Hellman (DH) Key Agreement
- Het bovenstaande (RSA) gebeurt ook, alleen wordt het random getal niet gebruikt voor de versleuteling
  van het netwerkverkeer, maar uitsluitend voor authenticatie van de server. Dat kan nl. niet met DH. Effectief
  pakt de server het random getal uit met zijn private key en stuurt het onversleuteld terug naar de client.
  Vervolgens vergelijkt de client het teruggestuurde getal met het eerder zelf gegenereerde getal: als deze
  overeenkomen, moet het om de bedoelde server gaan.
- Daarnaast komen beide partiijen (webbrowser en server), met een wiskundige truc, een identieke
  symmetrische sleutel overeen, zonder dat die sleutel zelf wordt uitgewisseld! Wel worden er enkele
  getallen uitgewisseld, maar daar kan een aanvaller (met toegang tot de verbinding, een MitM) niet
  de uiteindelijke symmetrische sleutel afleiden. Een mooie truc dus!

Dit protocol wordt vaak, m.i. onterecht, aangeduid als de Diffie-Hellman Key Exchange (zie bijv. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange. Maar dat klopt natuurlijk niet, de essentie is juist dat die key (symmetrische sleutel) niet wordt uitgewisseld. Vandaar Key Agreement.

Voor degenen die willen weten hoe DH werkt: in 2006 heeft Saqib Ali daar een aardig plaatje over gepubliceerd (met kleine getallen, om het begrijpelijk te maken - dergelijke kleine getallen worden in de praktijk natuurlijk niet gebruikt). Helaas bestaat zijn site niet meer, maar het is nog wel te vinden op "The Internet Archive": https://web.archive.org/web/20090208164631/http://www.xml-dev.com/blog/?action=viewtopic&id=196.

Key Agreement/Exchange: voordeel DH / (P)FS boven RSA
Bij RSA wordt de symmetrische sleutel, waarmee effectief http over https wordt versleuteld, daadwerkelijk uitgewisseld. Ook deze key wordt na de sessie weggegooid; het is echt een tijdelijk "ding".

Echter, als een aanvaller de uitgewisselde netwerkpakketjes opslaat, en later de private key van de server in handen krijgt (denk aan een kwaadaardige hacker maar ook aan justitie met een "huiszoekingsbevel"), dan kan de symmetrische sleutel weer uit de uitgewisselde pakketjes worden herleid, en daarmee de hele sessie worden ontcijferd.

Omdat de symmetrische sleutel bij DH geheel niet wordt uitgewisseld, is dat laatste niet mogelijk, dus ook niet als al het netwerkverkeer is opgeslagen en een aanvaller de private key in handen heeft of krijgt.

Nb. als een aanvaller de private key al in handen heeft op het moment dat de sessie gestart wordt, kan hij zich, als MitM (Man-in-the-Middle), richting client (webbrowser) voordoen als de server, en, richting server, als de webbrowser. In die situatie is geen betrouwbare authenticatie van de server mogelijk, en dus kan de aanvaller op dat moment al het netwerkverkeer al ontcijferen. DH ontslaat je dus niet van de plicht om uiterst zorgvuldig met private keys om te gaan!